Test objects and terms
TFS 2018
Read this article to gain an understanding of the objects and terms used in manual and exploratory testing.
Test-specific work item types
To support manual and automated testing, you add and group three main types of test-specific work item types: Test Plans, Test Suites, and Test Cases. To support sharing of various test steps and test parameters, you define Shared Steps and Shared Parameters. These objects are stored in the work tracking data store as specific types of work items.
The following table describes the work item types used to support the Azure DevOps test experience. Test-specific work items link together using the link types shown in the previous image.
Work item type
Description
Test plans
Are used to group test suites and individual test cases. To define a test plan, see Create test plans and test suites.
Test suite
Group test cases into separate testing scenarios within a single test plan. Grouping test cases makes it easier to see which scenarios are complete. When creating a test suite, you can specify one of three types:
- Static test suites: Used to group test cases under a single test suite.
- Requirement-based suites: Select one or more requirements from a query which are then linked to the test suite.
- Query-based suites: Select one or more test cases which are then linked to the test suite.
Tip
The Test Suite Type read-only field indicates the type of suite selected. To add test suites, see Create test plans and test suites.
Test cases
Define the steps used to test code or an app for deployment. Define test cases to ensure your code works correctly, has no errors, and meets business and customer requirements. You can add individual test cases to a test plan without creating a test suite. More than one test suite or test plan can refer to a test case. You can effectively reuse test cases without needing to copy or clone them for each suite or plan. There are two types of test cases:
- Manual: Test cases that define different steps that you run using Test Runner or other supported client.
- Automated: Test cases that are designed to run within an Azure Pipeline.
Tip
You can create a test case that automatically links to a requirement—User Story (Agile), Product Backlog Item (Scrum), Requirement (CMMI), or Issue (Basic)—when you create a test from the Kanban board. To learn more, see Add, run, and update inline tests.
Shared steps
Use to share steps between multiple test cases. For example, log-in and verify steps for signing into an application are steps that can be shared across a number of test cases. To learn how, see Share steps between test cases.
Shared parameters
Use to specify different parameters for executing test a test step within a test case. To learn how, see Repeat a test with different data.
Common fields to all test-specific work item types
The following fields and tabs appear in most work items. Each tab is used to track specific information, such as 
history, 
links, or 
attachments. These three tabs provide a history of changes, view of linked work items, and ability to view and attach files.
The only required field for all work item types is Title. When the work item is saved, the system assigns it a unique ID. The form highlights required field in yellow. For information about test-related fields, see Query based on build and test integration fields. For all other fields, see Work item field index.
Field
Usage
Enter a description of 255 characters or less. You can always modify the title later.
Assign the work item to the team member responsible for performing the work. Depending on the context you are working in, the drop-down menu lists only team members or contributors to the project.
Note
You can only assign work to a single user. If you need to assign work to more than one user, add a work item for each user and distinguish the work to be done by title and description. The Assigned To field only accepts user accounts that have been added to a project or team.
When the work item is created, the State defaults to the first state in the workflow. As work progresses, update it to reflect the current status.
Use the default first. Update it when you change state as need. Each State is associated with a default reason.
Choose the area path associated with the product or team, or leave blank until assigned during a planning meeting. To change the dropdown list of areas, see Define area paths and assign to a team.
Choose the sprint or iteration in which the work is to be completed, or leave it blank and assign it later during a planning meeting. To change the drop-down list of iterations, see Define iteration paths and configure team iterations.
Provide enough detail to create shared understanding of scope and support estimation efforts. Focus on the user, what they want to accomplish, and why. Don't describe how to develop the product. Do provide sufficient details so that your team can write tasks and test cases to implement the item.
Common controls to all test-specific work item types
Several controls appear in several test-specific work items as described in the following table. If these controls are not of interest, you can hide them from the work item form layout as described in Add and manage fields (Inheritance process).
Control
Description
Deployment
Provides insight into whether a feature or user story has been deployed and to what stage. You gain visual insight into the status of a work item as it is deployed to different release environments as well as quick navigation to each release stage and run. This control is available from Test Plans, Test Suites, and Test Cases.
Development
Records all Git development processes that support completion of the work item. It is typically used to drive Git development from a requirement. This control supports traceability, providing visibility into all the branches, commits, pull requests, and builds related to the work item. This control is available from Test Plans, Test Suites, and Test Cases.
Related Work
Control used in Test Plans, Test Suites, and Test Cases to show or link to other work items such as requirements and bugs, usually through the Related link type.
Test Cases
Control used in Shared Steps and Shared Parameters work items to indicate or link to Test Cases.
Customize test-specific work item types
For the Inherited process, you can customize test plans, test suites, and test cases. For the On-premises XML process, you can customize all test-specific work item types. To learn more, see Customize work tracking objects to support your team's processes.
Permissions required to modify work items
There are a number of permissions that control select features for viewing, modifying, or deleting work items. These include those listed in the following table.
Permission
Level
Task
View test runs
Create test runs
Delete test runs
Project-level
To view, create, or delete test runs, you must be granted the corresponding permission.
Manage test configurations
Manage test environments
Project-level
Manage test configurations or test environments, you must be granted the corresponding permission.
Create tag definition
Project-level
Add new tags to test-based work items.
Delete and restore work items
Project-level
Delete test-specific work items and restore them from the Recycle bin.
Permanently delete work items
Project-level
Permanently delete test-specific work items from the data store.
View work items in this node
Edit work items in this node
Area Path
View or add or modify test plans, test suites, test cases, or other test-based work item types requires the corresponding permission.
Manage test plans
Area Path
Modify test plan properties such as test run and test outcome settings.
Manage test plans
Area Path
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).
To learn more about setting these permissions, see Set permissions and access for testing and Change project-level permissions.
Export, import, and bulk update of test-specific work items
As with other work items, you can bulk edit test-specific work items. To learn more, see the following articles:
Test terms
The following table describes several terms used in manual and exploratory testing.
Term
Definition
Configuration
Specifies the unique environment used to test an application or code. To define a test configuration, you first define the configuration variables, and then define the test configuration. For details, see Test different configurations.
Configuration variable
Specifies a single aspect of a test environment such as an operating system, processing power, web browser, or other variation. For details, see Test different configurations.
Outcome
Outcome of a test point as marked by the tester upon executing the test. Valid options are:
- Active (Unspecified)
- Pass Test
- Fail Test
- Block Test
- Not Applicable
To learn more, see Repeat a test with different data. Note that pipeline test outcomes differ as described in About pipeline tests.
Test points
Test cases by themselves are not executable. When you add a test case to a test suite then test point(s) are generated. A test point is a unique combination of test case, test suite, configuration, and tester. For example, if you have a test case named Test login functionality and you add two configurations for the Edge and Chrome browsers, you have two test points. You can execute or run each of these test points. On execution, test results are generated. Through the test results view, or execution history, you can see all executions of a test point. The latest execution for the test point is what you see in the Execute tab.
Test run settings
Dialog used to associate test plans with a build or release pipelines.
Test outcome settings
Dialog used to choose how test outcomes in multiple suites under the same test plans should be configured.
Traceability
Ability to trace test results with the requirements and bugs that they are linked to.