background image
<< Chapter 3 - Designing Tests | Examples of a test design >>
<< Chapter 3 - Designing Tests | Examples of a test design >>

Benefits of Good Test Design

Chapter 3 - Designing Tests
You should be able to design your tests based on test inputs such as feature
descriptions and software specifications (for example, requirements) before or during
the implementation of the actual system. This is a key aspect of making testing a
parallel development with system implementation.
A test design can be created without knowledge of the specifics of the implementation
of application under test--for example, without knowledge of the kinds of controls
used in the dialogs or what dialog or window implements a use case. The test case
design should be abstract enough that if the implementation changes, the test design
remains valid.
Someone should then be able to take the test design and a software build of the
system (with documentation) and know how to implement the test.
For example, if you are using an automated testing tool like Robot, y start your tool
and follow the steps documented in the test case design to create an automated test
script. The test script becomes an implementation of the designed test case and
therefore of the test case itself.
Benefits of Good Test Design
A good test design lets you take advantage of the benefits of test automation: reuse. A
good test design helps you to recognize the potential for reuse in the implementation
that you build. Until you know what needs to be done for each test case, you cannot
identify patterns of reuse that will be valuable when you design and build your test
When you look at all of the test designs (one for each test case) before you implement
the test cases, you might find patterns in the test designs that indicate a more efficient
way to implement the test cases. For example, you might see that every test design
begins with a step that says "From the Start menu, start the application." You might
decide that it doesn't make sense to record this step in every test script, because if the
name of the application changes, all of the scripts would need to be changed. Instead,
you might build a subroutine to start the application and have the test scripts call that
subroutine. This would become obvious by looking at the test designs.
Another benefit of a test design is that it helps to establish a baseline for a test case. As
you develop your test cases, you can validate them against the original test design.