Test objects and terms

Description

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 that you link to the test suite.
• Query-based suites: Select one or more test cases that you link 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 by 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 you can share 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. The people picker searches for and lists users across the connected tenant. For more information, see People picker.

When you create the work item, 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 it 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 to complete the work, 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 a 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. 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 is deployed and to what stage. You gain visual insight into the status of a work item as it's deployed to different release environments as well as quick navigation to each release stage and run. You can access this control from Test Plans, Test Suites, and Test Cases.

Records all Git development processes that support completion of the work item. Typically, you use it to drive Git development from a requirement. This control supports traceability by providing visibility into all the branches, commits, pull requests, and builds related to the work item. You can access this control from Test Plans, Test Suites, and Test Cases.

Use this control 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.

Use this control in Shared Steps and Shared Parameters work items to indicate or link to Test Cases.

Definition

Specifies the unique environment used to test an application or code. To define a test configuration, 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.

A categorization applied to test cases marked as Failed to classify the nature of the failure. Default failure types include Regression Issue, New Issue, Known Issue, and Not a Failure. Teams can define custom failure types by using the REST API. For details, see Manage test failure type.

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

For more information, see Repeat a test with different data. Note that pipeline test outcomes differ as described in About pipeline tests.

A single pass through a test case using a specific set of parameter values. When a test case uses parameters or shared parameters, each unique combination of values creates a separate test iteration. For details, see Repeat a test with different data.

Test cases by themselves aren't executable. When you add a test case to a test suite, test points 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 sign in functionality and you add two configurations for the Microsoft 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.

The recorded outcome of a single test case execution within a test run. Each test result captures whether the test passed, failed, or had another outcome, along with diagnostic data and attachments. For details, see Review test runs.

A logical grouping of test results created when one or more test cases are executed. The system creates a test run when you run test cases from a test plan or pipeline. Each test run captures outcomes, duration, environment, and diagnostic data. For details, see Review test runs.

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.

An individual action within a test case, consisting of an Action (what the tester does) and an Expected Result (the anticipated behavior). During execution, each test step is marked as passed or failed. Test steps can reference shared steps and include attachments. For details, see Create test cases.

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

A testing approach in which business stakeholders or end users verify that delivered functionality meets customer requirements. In Azure Test Plans, you can assign testers to test suites, send email invitations, and track progress through charts. Users with Stakeholder access can participate. For details, see User acceptance testing.