6.5. Test Design
Test design follows test planning. This is where the quality analyst, the tester, and the programmer sit together to figure out a combination of test approaches needed for a particular class, component, or package. For example, GUI classes require a test design with more black box tests, whereas a component that deals with calculating insurance premiums needs many test harnesses and open white box testing. The various test architectures and testing approaches discussed earlier come together in a package test design. While only one test plan is expected in a project, there will be several test designs. Test designs are typically prepared for a subsystem or a component. The test designs are made up of a group of test cases.
6.5.1. Description of Test Designs
Test designs ensure that a group of cohesive test cases is created for a package or subsystem. Test designs also ensure that the right environment, including software and people, is available for a suite of test cases. For example, a test design for security testing requires a security expert and a tester to be available for testing, whereas a test design for an insurance package calls for a vertical test by an insurance expert. Thus, organizing the immediate needs for testing a subsystem or package, and putting together the right number and type of test cases, is part of test design. Test designs are created within the overall framework of the test plans.
Test-design subject areas are derived from the vertical and horizontal slicing of the system for testing. The vertical slicing provides the subsystems. If these subsystems are smaller in size, then each of the subsystems results in a test design. If the subsystems are larger in size, then we will have two or three test designs handling each of the subsystems. Each test design incorporates a series of test cases handling all aspects of testing the system from the application perspective. Note that as shown in Figure 6.5, test designs are created within the overall framework of the test plan. However, they are not test cases themselves. Instead, the test designs encompass the test cases.
Figure 6.5. Organization of testing
6.5.2. Sources for Test Designs
Test designs can be created based on understanding the system at the subsystem or component level. Documenting use cases in the MOPS also provides an excellent starting point for the test designs. These test designs give a broad coverage of the required functionality rather than the specific lower level tests for each class or component of the system. The test designs resulting from the use case documentations and package diagrams in MOPS ensure that the division of system testing is ideal—the test designs reflect the need to test the system in a modular fashion. The user can also contribute to these test designs and later use them to conduct acceptance tests. The test designer incorporates the requirements, their variations, and their extensions within the test designs.
Test designs also consider the number of classes to be tested and their corresponding complexity. For each class there are a number of test cases that test different functionality of the same classes. Test designs also incorporate extra test cases that deal with testing the entire component—as opposed to individual classes. For example, a set of test cases within a test design may test the date class and another set of test cases may test the account class. However, a good test design ensures that there is a third group of test cases that test the working of the two classes together.
Figure 6.6. Use case versus class testing
6.5.3. Format for Test Designs
A typical test design contains the following:
Name. This identifies the test design, which may be stored as a document. The name should ideally reflect the nature of the test design. It may be the name of a package prefixed by “Test,” as in TestClient.
Module. This indicates details of the subsystem, package, or any other module within the target system that is targeted by the test design. It contains a brief description of the type of package being tested, the preparation required for the package (creating test data or procuring a domain expert's services, for example), and the various categories of test cases needed.
Dependency. This indicates the other test designs on which this design depends. This is helpful when creating test cycles, or may itself be created based on the test cycles. For example, the dependency of the TestClient design is TestSecurity—one should ideally be testing the creation and maintenance of clients after the user codes and passwords for the overall system have been tested.
List of test cases. This is the list of test cases that make up the test design. All test cases belonging to this design are listed together with a brief one-line description. Test cases may have been numbered and may be grouped according to the needs of the design (for example, all interface test cases may be grouped together in a test-design document, separately from all database-access test cases).