Test Plan

The top level of testing effort. You can see it as a big container. Microsoft believes testing is a shared-resource cross-function effort thus the Test Plan is set up at the Team Project level just like most of QA teams are doing testing for multiple deliver teams in many companies.

• dbo.tbl_Plan

Test Suite

Think about Test Suites as big conceptual areas you want to achieve for your testing effort. Test Suite is a container to aggregate your test cases and it can be created statically (managed manually) or by a query (managed automatically). Test Suites can be multi-level nested and same test cases can appear under different test suites.

• dbo.tbl_Suite
• dbo.tbl_SuiteEntry

Test Case

A Test Case is a type of work item. You can find its data like you would find for any other work item types. However, there are a big difference between Test case and other work item types. Unlike other work items types (i.e., Epic, Feature, PBI, Task), w e do not change the status of Test Cases as we progress our work. The status of a test case is for test case itself, not for its result.

We can view Test Cases as food recipes or movie scripts. We are trying to follow the recipes/scripts to record the results. Different performers might get different results from time to time or under different packages.

• dbo.tbl_WorkItemCoreLatest
• dbo.tbl_WorkItemCoreWere
• dbo.tbl_WorkItemCustomLatest
• dbo.tbl_WorkItemCustomWere

Shared Step

Shared Step is another work item type just like Test Case. Shared Steps can be linked between other work item type.

Manual Test Step

TFS stores all manual test steps in a separate table in xml format

• dbo.WorkItemLongTexts

Test Run

Every time you hit Run, it is a Test Run doesn’t matter how many test suites and test cases you select. Test Run is the basic unit of testing. It records who, when, comment, and outcome of this particular test at the Test Run level.

At the front end GUI, you can search by Test Run ID to traverse all related information including Test Run summary, details, associated test results, test cases, and bugs.

• dbo.tbl_TestRun

Point

In the back end, TFS uses PointID to identify the unique combination of Test Suite and Test Case IDs.

• dbo.tbl_Point

Test Result

All test result data for all test runs. When query the results, Point is for physical location and TestCaseReference is for time. A test case might be added under multiple suites (Point) and run multiple times (TestCaseReference) by same or different people with different outcome.

• TestResult.tbl_TestCaseReference
• TestResult.tbl_TestResult

 

With the understanding of above and the help of Power BI, now we can show the clear picture of our testing effort.

And of course, dissect the results with Power BI