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. For more information about identity search and selection, see Query by assignment or workflow changes.

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.

Test cases by themselves aren't executable. When you add a test case to a test suite, you generate test points. A test point is a unique combination of a test case, test suite, configuration, and tester.

For example, a test case called Test sign in functionality with two configurations (Microsoft Edge and Chrome) generates two test points. You can run each test point independently, and each execution produces a test result. You can view all executions for a test point in the execution history. The Execute tab shows the latest result for each test point.

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.