Page 184 -

Test cases are usually strung together in one long interaction with the software. This
means that the results in Table 8-4 should really be verified using five different test cases,
one per bullet point in requirement FR-4. For example, since test case TC-47 verifies the
second bullet point in FR-4, TC-48 could verify the third bullet point and have in its pre-
condition that TC-47 has been run. The precondition for TC-47, in turn, would require
that TC-46 be run.
To ensure that the test cases all start out with the same document open, each test case
depends on a base state, or a condition of the software that can be reproduced at any time.
A base state is an anchor point that is easy to navigate to. Test case TC-47 contains two
references to a base state labeled BS-12. The first reference is in the Precondition section:
the test case requires that the software be in its base state. The second reference is at the
end of the Expected Results section: the tester must return the software to the base state
after the test case, in order to reset it for the next one. This ensures that whether the test
passes or fails, it will not have any side effects on any tests that are executed after it.
Table 8-5 shows the definition of this base state. It is in the same form as a test case (note
that since it is not exercising a particular requirement, the “Requirement” section con-
tains the text “N/A”).
TABLE 8-5. Base state BS-12

Name BS-12: Load test document TESTDOC.DOC
Requirement N/A
Preconditions No user is logged in and no applications are running.
Steps 1. Log in as user “joetester” with password “test1234”.
2. Launch the application.
3. Select the File/Open menu item.
4. Enter “/usr/home/joetester/TESTDOC.DOC”.
5. Click OK.
Expected Results 1. Verify that the Open Window dialog box has been dismissed.
2. Verify that the file TESTDOC.DOC is loaded.
3. Verify that the file TESTDOC.DOC is given focus.
4. Verify that the file TESTDOC.DOC is active.

It is not necessary for every test case to start out in a base state. In fact, it is often useful to
string a set of test cases together so that the precondition of each one depends on the pre-
vious test case passing. However, when there are strings of test cases that go for a long
time without returning to a base state, there is a risk that areas of the application will go
untested in the event of a failure. If a test case fails, the results of the following test cases
simply cannot be trusted until the software is returned to a base state.

Once all of the test cases and base states are defined, they should be combined into a sin-
gle test case document. This document is usually far longer than any other document pro-
duced over the course of the software project. It contains a separate table for each test
case and base state. Each of the test cases and base states should be cross-referenced with

176 CHAPTER EIGHT