Work Product Descriptor (Artifact): Test Case
This artifact is the specification of a set of test inputs, execution conditions, and expected results that you identify to evaluate a particular aspect of a scenario.
Purpose

Use this artifact for the following purposes:

  • To provide a way to capture test inputs, conditions, and expected results for a system
  • To systematically identify aspects of the software to test
  • To specify whether an expected result has been reached, based on the verification of a system requirement, set of requirements, or scenario
Relationships
RolesResponsible: Modified By:
Description
Main Description

A test case specifies the conditions that must be validated to enable an assessment of aspects of the system under test. A test case is more formal than a test idea; typically, a test case takes the form of a specification. In less formal environments, you can create test cases by identifying a unique ID, name, associated test data, and expected results.

Test cases can be derived from many sources, and typically include a subset of the requirements (such as use cases, performance characteristics, and reliability concerns) and other types of quality attributes. For more information on types of tests and their relationships to quality test attributes, see Concept: Testing Qualitative Requirements.

Brief Outline

1. Test Case Description
A description of the purpose or objective of the test, the scope, and any preconditions of the test

2. Execution Condition
A description of a condition that will be exercised during this test

a. Preconditions
For each execution condition, describe the required state that the system should be in before the test can commence.

b. Test Inputs
For each execution condition, enumerate a list of the specific stimuli to be applied during the test. This is generally referred to as the Inputs to the test, and includes the objects or fields interacted with (and the specific data values entered) when executing this Test Case.

c. Observation Points
During the test execution, enumerate what specific observations should be made.

d. Control Points
During the test execution, identify any points where the flow of control may alter or vary.

e. Expected Results
The resulting state or observable conditions that are expected as a result of the test having been executed. This may cover both positive and negative responses (such as error conditions and failures).

f. Postconditions
For each execution condition, describe the required state that the system should be returned to, allowing subsequent tests to be performed.

Properties
Optional
Planned
Illustrations
Templates
Tailoring
Impact of not having

Without this artifact, it is difficult to validate system functionality. Because this artifact specifies the conditions of acceptance between the stakeholders and the developers, without the artifact, it is difficult to establish exit criteria and to demonstrate that the exit criteria have been met. If the original test cases have not been documented, it is impossible to do regression testing.

Reasons for not needing

It might not be necessary to create this artifact to maintain or make small enhancements to existing systems, which likely have existing test assets that you can use. You also might not need this artifact if you use a package application that has its own set of test cases.

Representation Options

In certain domains and testing cultures, Test Cases are considered optional work products, whereas in others they are highly formalized and mandatory. As such, both the contents and format of Test Cases may require modification to meet the needs of your specific organization or project.

When they are recorded (both formally and informally), two main styles are followed:

The first is a standard text document structure using a format similar to that previously outlined in the Brief Outline. Often, multiple Test Case instances or variations are specified in a single document, grouped by the general purpose or objective of the tests.

The second style uses some form of table or database. Test-Case instances are specified, one per row, with columns provided to facilitate sorting and filtering by different criteria.
Some consideration should also be given to ongoing measurement of the test cases for progress, effectiveness, and so on. Consider requirements-based test coverage, in which each Test Case traces back to at least one test idea and at least one system requirement, which represents a subset of the Product requirements (see Concept: Key Measures of Test).

As mentioned, it is typical for multiple Test Case instances or variations to be specified in a single document, usually grouped by the general purpose or objective of the tests. This may be realized as multiple execution conditions described within the one document, one per unique Test Case instance.

Optionally, the Test Case can be enclosed partially or completely within the Test Ideas List or Test Script.

More Information