Artifact:  Test Case

Test Case	The definition (usually formal) of a specific 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.
UML Representation:	There is no UML representation for this artifact.
Role:	Test Analyst
Optionality/ Occurrence:	One or more artifacts. Considered optional in some domains and test cultures, and mandatory in others. Where used, many Test Cases will exist.
Enclosed in:	Optionally the Test Case can be enclosed partially or completely within the Test-Ideas List or Test Script.
Templates:	Others
Examples:
Reports:
More Information:	Guidelines:Test Case Guidelines:Unit Test Checkpoints:Test Case
Purpose Brief Outline Properties Timing Responsibility Tailoring

Input to Activities: Implement Test Analyze Test Failure Determine Test Results Implement Component Perform Unit Tests Implement Test Components and Subsystems Design Test Classes and Packages Develop Test Guidelines Define Testability Elements Structure the Test Implementation Define Test Details

Output from Activities: Define Test Details

Purpose

The purpose of the Test Case is to formally identify and communicate the detailed specific conditions which will be validated to enable an evaluation of some particular aspects of the Target Test Items. Test Cases may be motivated by many things but will usually include a subset of both the Requirements (Use Cases, performance characteristics, etc.) and the risks the project is concerned with.

The Test Case is primarily used:

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

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.
   
   1. Preconditions
      For each execution condition, describe the required state that the system should be in before the test can commence.
      
   2. 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.
      
   3. Observation Points
      During the test execution, enumerate what specific observations should be made.
      
   4. Control Points
      During the test execution, identify any points where the flow of control may alter or vary.
      
   5. Expected Results
      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 failures).
      
   6. Postconditions
      For each execution condition, describe the required state that the system should be returned to, allowing subsequent tests to be performed.
      
      

Properties

There are no UML representations for these properties.

Timing

The first candidate Test Cases may be identified as early as the Inception phase, and are subsequently identified on an iteration-by-iteration basis throughout the remainder of the project lifecycle. It is typical for Test Cases to be defined in detail as the implementation work is scheduled for them, usually beginning with the first iteration in the Elaboration phase.

Responsibility

The Test Analyst role is primarily responsible for this artifact. Those responsibilities include:

• Identifying and defining each Test Case, and approving all subsequent changes to it.
• Ensuring that changes are communicated to affected downstream roles.
• Ensuring that sufficient Test Cases have been identified to provide satisfactory evaluation of the Target Test Items.
• Ensuring that sufficient detail has been provided to implement and conduct the test.
• Managing and maintaining appropriate traceability relationships.
• Managing the appropriate scope of the Test Cases in a given iteration.

Tailoring

In certain domains and testing cultures, Test Cases are considered optional artifacts, 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 Concepts: 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.

Copyright  © 1987 - 2001 Rational Software Corporation

Rational Unified Process