Test objects and terms

Description

Are used to group test suites and individual test cases. To define a test plan, see Create test plans and test suites.

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.

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.

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.

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.

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.

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.

Description

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.

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.

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.

Control used in Shared Steps and Shared Parameters work items to indicate or link to Test Cases.

Permission

Task

View test runs
Create test runs
Delete test runs

To view, create, or delete test runs, you must be granted the corresponding permission.

Manage test configurations
Manage test environments

Manage test configurations or test environments, you must be granted the corresponding permission.

Create tag definition

Add new tags to test-based work items.

Delete and restore work items

Delete test-specific work items and restore them from the Recycle bin.

Permanently delete work items

Permanently delete test-specific work items from the data store.

View work items in this node
Edit work items in this node

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

Modify test plan properties such as test run and test outcome settings.

Manage test plans

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).

Definition

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.

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 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 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.

Dialog used to associate test plans with a build or release pipelines.

Dialog used to choose how test outcomes in multiple suites under the same test plans should be configured.

Ability to trace test results with the requirements and bugs that they are linked to.