Create test plans and test suites
TFS 2017 | TFS 2015
Create test plans and test suites to track manual testing for sprints or milestones. That way, you can see when the testing for a specific sprint or milestone is complete. For more information about manual testing, see What is Azure Test Plans? and Automated and Manual Testing with Azure Test Plans.
Share work items across your test experience
For example, you're building version 1.* of your product and you might create several test cases for that version. Each of these test cases can be updated, and more added, at any time. For each development cycle and release of your product, you create a test plan and import the existing test cases into that plan. You can also, if you wish, divide the test cases into separate test suites within the plan to enable easier management and monitoring of these separate sets of test cases.
After you create your test plan, you assign test configurations and assign testers to cover the required test matrix. These testers run the tests and gauge the quality of the product. Testers continue testing until the product meets exit criteria. For the next development cycle and release, you can create a new test plan and reuse the same test cases. You repeat this development-test-release cycle by importing the same test cases into each new test plan.
The great thing is that, because test plans refer to test cases, updates to a test case automatically reflect in all the test plans and test suites that use it.
In the next version of the product, you can reuse the existing test cases. However, a better option may be to copy or clone the test cases. A copy creates a new baseline. Changes to these new test cases don't affect your previous test plans.
For more information about the ways you can work with test plans, test suites, and test cases, see the FAQs for manual testing.
You must connect to a project. If you don't have a project yet, create one.
You must be added to a project. To get added, Add users to a project or team.
To view test-related work items, you must have Basic access or higher and permissions to view work items under the corresponding Area Path.
To add test plans and test suites, manual test cases, delete test artifacts, and define test configurations you must have Basic + Test Plans access level or have one of the following Visual Studio subscriptions:
To add or edit test-related artifacts, you must have the following permissions:
- To add or modify test plans, test suites, test cases, or other test-based work item types, you must have Edit work items in this node permission set to Allow under the corresponding Area Path.
- To modify test plan properties such as build and test settings, you must have Manage test plans permission set to Allow under the corresponding Area Path.
- To create and delete test suites, add, and remove test cases from test suites, change test configurations associated with test suites, and modify a test suite hierarchy (move a test suite), you must have Manage test suites permission set to Allow under the corresponding Area Path.
To learn more, see Manual test access and permissions.
Create a test plan
In general, you create test plans to test requirements. Prior to creating a test plan, therefore, you may want to define your backlog of requirements.
From the web portal, open your project and go to Test Plans. If you already have a test plan, choose Test Plans to go to the page that lists all test plans.
In the Test Plans page, choose New Test Plan to create a test plan for your current sprint.
In New Test Plan, enter a name for the test plan. Verify that the area path and iteration are set correctly, then choose Create.
Rename a test plan
To rename a test plan, open it from the shortcut menu and rename it.
Delete a test plan
To delete a test plan, use the shortcut menu for the test plan.
Add a requirement-based test suite
Now add test suites for the backlog items that need manual tests. These tests could be user stories, requirements, or other work items based your project.
Requirement tracking is supported only for test cases linked through a Requirement-based test suite. The association between a requirement work item—User Story (Agile), Product Backlog Item (Scrum), Requirement (CMMI), or Issue (Basic) and manual test execution is only formed when the test case is linked via a Requirement-based test suite.
To add a suite to a test plan, select the + new drop-down list and choose a type of test suite.
You use requirement-based suites to group your test cases together. That way, you can track the testing status of a backlog item. Each test case that you add to a requirement-based test suite is automatically linked to the backlog item.
In Create requirement-based suites, add one or more clauses to filter your work items by the iteration path for the sprint. Run the query to view the matching backlog items.
In the list of work items returned by the query, select the backlog items you want to test in this sprint. Choose Create suites to create a requirement-based suite for each one.
Work with test suites
You can create a static test suite that can contain any type of test suites. Use these test suites like folders. Drag test suites to group them in a static test plan. Drag and drop tests to reorder them.
You can track changes to test plans and test suites. Open the work item for the test plan or test suite, then view the work item history.
For test suites, other actions are tracked in the Test Suite Audit field. For example, adding and removing test cases from a test suite are tracked in this field.
You can export test plans, test suites, and test cases.
Select the details that you want in the report. Then email or print this report for review.
Change the test case fields in the report by adding or removing columns from the list view of the test suite.
You cannot export more than 75 Test Suites in a single operation. The email supports up to 1MB of data.
Find a test case in a test plan
In Test Plans for your test plan, use the filter icon (1) to show the search and filter lists (2) that help you find the tests you want to work with. Or filter the list of tests using Outcome, Tester, and Configuration (3).