The design of tests is subject to the same basic engineering principles as the design of software. Good design consists of a number of stages which progressively elaborate the design of tests from an initial high level strategy to detailed test procedures.

These stages are: test strategy, test planning, test case design, and test procedure design.


The design of tests has to be driven by the specification of the software. At the highest level this means that tests will be designed to verify that the software faithfully implements the
requirements of the Requirements Specification. At lower levels tests will be designed to verify that items of software implement all design decisions made in the Architectural Design Specification and Detailed Design Specifications. As with any design process, each stage of the test design process should be subject to informal and formal review.
The ease with which tests can be designed is highly dependant on the design of the software. It is important to consider testability as a key (but usually undocumented) requirement for any software development.
 

• 1. Test Strategy
  The first stage is the formulation of a test strategy. A test strategy is a statement of the overall approach to testing, identifying what levels of testing are to be applied and the
  methods, techniques and tools to be used. A test strategy should ideally be organization wide, being applicable to all of an organizations software developments.
  Developing a test strategy which efficiently meets the needs of an organization is critical to the success of software development within the organization. The application of a test strategy to a software development project should be detailed in the projects software quality plan.
   
• 2. Test Plans
  The next stage of test design, which is the first stage within a software development project, is the development of a test plan. A test plan states what the items to be tested are, at what level they will be tested, what sequence they are to be tested in, how the test strategy will be applied to the testing of each item, and describes the test environment.
  A test plan may be project wide, or may in fact be a hierarchy of plans relating to the various levels of specification and testing
• An Acceptance Test Plan, describing the plan for acceptance testing of the software.
  This would usually be published as a separate document, but might be published with the system test plan as a single document.
• System Test Plan, describing the plan for system integration and testing. This would also usually be published as a separate document, but might be published with the acceptance test plan.
• Software Integration Test Plan, describing the plan for integration of tested software components. This may form part of the Architectural Design Specification.
• Unit Test Plan(s), describing the plans for testing of individual units of software. These may form part of the Detailed Design Specifications.
  The objective of each test plan is to provide a plan for verification, by testing the software, that the software produced fulfils the requirements or design statements of the appropriate
  software specification. In the case of acceptance testing and system testing, this means the Requirements Specification.
   
• 3. Test Case Design
  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.
   
• 4. Test Procedures
  The final stage of test design is to implement a set of test cases as a test procedure, specifying the exact process to be followed to conduct each of the test cases. This is a fairly straight forward process, which can be likened to designing units of code from higher level functional descriptions.
  For each item to be tested, at each level of testing, a test procedure will specify the process to be followed in conducting the appropriate test cases. A test procedure cannot leave out
  steps or make assumptions. The level of detail must be such that the test procedure is deterministic and repeatable.
  Test procedures should always be separate items, because they contain a great deal of detail which is irrelevant to software specifications.