20 Feb

Once the test plan for a level of testing has been written, the next stage of test design is to specify a set of test cases or test paths for each item to be tested at that level. A number of test cases will be identified for each item to be tested at each level of testing.

Each test case will specify how the implementation of a particular requirement or design decision is to be tested and the criteria for success of the test. 

The test cases may be documented with the test plan, as a section of a software specification, or in a separate document called a test specification or test description.

  •  An Acceptance Test Specification, specifying the test cases for acceptance testing of the software. This would usually be published as a separate document, but might be published with the acceptance test plan.
  •  A System Test Specification, specifying the test cases for system integration and testing. This would also usually be published as a separate document, but might be published with the system test plan.
  •  Software Integration Test Specifications, specifying the test cases for each stage of integration of tested software components. These may form sections of the Architectural Design Specification.
  •  Unit Test Specifications, specifying the test cases for testing of individual units of software. These may form sections of the Detailed Design Specifications.

System testing and acceptance testing involve an enormous number of individual test cases. In order to keep track of which requirements are tested by which test cases, an index which cross references between requirements and test cases often constructed.

This is usually referred to as a Verification Cross Reference Index (VCRI) and is attached to the test specification. Cross reference indexes may also be used with unit testing and software integration testing.

It is important to design test cases for both positive testing and negative testing. Positive testing checks that the software does what it should. Negative testing checks that the software doesn’t do what it shouldn’t.

The process of designing test cases, including executing them as thought experiments, will often identify bugs before the software has even been built. It is not uncommon to find more bugs when designing tests than when executing tests.