|This artifact defines a set of test inputs, execution conditions, and expected results, identified for the purpose of making an evaluation of some particular aspect of a Target Test Item.
Work Product Kinds: Specification
To enumerate an adequate number of specific tests to ensure evaluation completeness
To identify and reason about required Test Scripts and drivers, both manual and automated
To provide an outline for the implementation of Test Scripts and drivers by providing a description of key points
of observation and control, and any pre and postconditions
A Test Case specifies and communicates the specific conditions which need to be validated to enable an assessment of
some particular aspects of the Target Test Items. A Test Case differs from a test idea, in that the test case is a more
fully-formed specification of the test. Test Cases may be motivated by many things but will usually include a subset of
both the Requirements such as Use Cases, performance characteristics, and the risks the project is concerned with. As a
general rule, test case specifications are most useful where the test implementation itself will be too complex to
understand by itself without the support of a more abstract explanation provided by the test case.
Test Case Description
A description of the purpose or objective of the test, the scope, and any preconditions of the test.
A description of a condition that will be exercised during this test.
For each execution condition, describe the required state that the system should be in before the test can
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.
During the test execution, enumerate what specific observations should be made.
During the test execution, identify any points where the flow of control may alter or vary.
The resulting state or observable conditions that are expected as a result of the test having been
executed. Note that this may cover both positive and negative responses (such as error conditions and
For each execution condition, describe the required state that the system should be returned to, allowing
subsequent tests to be performed.
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 each 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
forth. 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 Technique: Key Measures of Testing).
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.
© Copyright IBM Corp. 1987, 2006. All Rights Reserved.