The test design component addresses the need to define the number of tests to be performed, the ways that testing will be approached (paths, functions), and the test conditions that need to be exercised. Test design standards need to be defined and followed.An effective test program, incorporating the automation of software testing, involves a mini-development lifecycle of its own, complete with strategy and goal planning, test requirement definition, analysis, design, and coding. Similar to software application development, test requirements must be specified before test design is constructed. Test requirements need to be clearly defined and documented, so that all project personnel will understand the basis of the test effort. Test requirements are defined within requirement statements as an outcome of test requirement analysis.After test requirements have been derived using the described techniques, test procedure design can begin. Test procedure design consists of the definition of logical groups of test procedures and a naming convention for the suite of test procedures. With a test procedure definition in place, each test procedure is then identified as either an automated or a manual test. During the test planning phase, the test team gets an understanding of the number of test techniques being employed and an estimate for the number of test procedures that will be required. The test team also will have an estimate of the number of test procedures that will need to be performed manually, as well as with an automated test tool.Much like a software development effort, the test program must be mapped out and consciously designed to ensure that test activities performed represent the most efficient and effective tests for the system under test. Test program resources are limited, yet ways of testing the system are endless. A test design is developed to portray the test effort, in order to give project and test personnel a mental framework on the boundary and scope of the test program.Following test analysis, the test team develops the test program design models. The first of these design models, the test program model, consists of a graphical illustration that depicts the scope of the test program. This model typically depicts the test techniques required to support the dynamic test effort and also outline static test strategies.Having defined a test program model, the test team constructs a test architecture, which depicts the structure of the test program and defines the way that test procedures will be organized in support of the test effort.The next step in the test procedure design process (see Table 1) is to identify those test procedures that stand out as being more sophisticated, and as a result are required to be defined further as part of detailed test design. These test procedures are flagged and a detailed design document is prepared in support of the more sophisticated test procedures. Following detailed test design, test data requirements are mapped against the defined test procedures. To create a repeatable, reusable process for producing test procedures, the test team needs to create a document that outlines test procedure design standards. Only when these standards are followed can the automated test program achieve real efficiency and success, by being repeatable and maintainable.Table 1 Test Procedure Design Process

The exercise of developing the test procedure definition not only aids in test development, but helps to quantify or bound the test effort. The development of the test procedure definition involves the identification of the suite of test procedures that need to be developed and executed in support of the test effort. The design exercise involves the organization of test procedures into logical groups and the definition of a naming convention for the suite of test procedures.At the system level, it may be worthwhile to develop a detailed test design for sophisticated tests. These tests might involve test procedures that perform complex algorithms, consist of both manual and automated steps, and test programming scripts that are modified for use in multiple test procedures. The first step in the detailed design process is to review the test procedure definition at the system test level. This review is conducted for the purpose of identifying those test procedures that stand out as being more sophisticated and that, as a result, are required to be defined further as part of detailed test design.Detailed test design may take the form of test program pseudo-code, when test programming is required. The detailed design may be represented simply as a sequence of steps that need to be performed in support of a test. When programming variables and multiple data values are involved, the detailed design may reflect the programming construct of a loop supporting an iterative series of tests involving different values, together with a list or table identifying the kinds of data or ranges of data required for the test.Following the performance of detailed test design, test data requirements need to be mapped against the defined test procedures. Once test data requirements are outlined, the test team needs to plan the means for obtaining, generating, or developing the test data.The structure of the test program (test architecture) is commonly portrayed in two ways. One test procedure organization method involves the logical grouping of test procedures with the system application design components, and is referred to as a design-based test architecture. Another method represents a test technique perspective and associates test procedures with the various kinds of test techniques represented within the test program model, and is referred to as a technique-based test architecture.An understanding of test techniques is necessary when developing test design and the test program design models. Personnel performing testing need to be familiar with the test techniques associated with the white box and black box test-approach methods. White box test techniques are aimed at exercising software program internals; black box techniques generally compare the application under test behavior against requirements that address testing via established public interfaces such as the user interface or the published application programming interface (API).