Page 182 -

Table 8-2 shows an example of a test case that would exercise one specific behavior in
requirement FR-4 from the discussion of functional requirements in Chapter 6. This
requirement specified how a search-and-replace function must deal with case sensitivity.
One part of that requirement said, “If the original text was all lowercase, then the replace-
ment text must be inserted in all lowercase.”

TABLE 8-2. Example of a test case
Name TC-47: Verify that lowercase data entry results in lowercase insert
Requirement FR-4 (Case sensitivity in search-and-replace), bullet 2
Preconditions The test document TESTDOC.DOC is loaded (base state BS-12).
Steps 1. Click on the “Search and Replace” button.
2. Click in the “Search Term” field.
3. Enter This is the Search Term.
4. Click in the “Replacement Text” field.
5. Enter This IS THE Replacement TeRM.
6. Verify that the “Case Sensitivity” checkbox is unchecked.
7. Click the OK button.
Expected results 1. The search-and-replace window is dismissed.
2. Verify that in line 38 of the document, the text this is the search term has been replaced by this
is the replacement term.
3. Return to base state BS-12.

Note that this test case includes interactions with design elements like text fields, buttons,
and windows. This is one of the main differences between a use case and a test case. A use
case specifically does not talk about design elements, in order to avoid constraining the
designers. Test cases must be very specific about how they plan on doing their interaction
because the design has been decided upon, and the part of the purpose of the test case is to
exercise that design. This means that the test case cannot be completed until the design of
the software is finished.

A project manager should be aware of the characteristics of a good test case. A test case
describes in complete detail everything that the tester must do. It contains the names of
the buttons that the tester must click on, the menu items that should be selected, the exact

data that must be typed in, etc. All of the expected behavior of the software (such as win-
dows dismissed or error messages displayed) must be described. The goal of that is to make
each test case repeatable, so that no two people will test the software differently.
Table 8-3 shows an example of a test case that is widely open to interpretation. It may
seem specific at first glance, but there are some serious problems with it:

• The test case does not specify exactly how the search-and-replace function is accessed.
If there are several ways to bring up this function, and a defect is found that is specific
to only one of them, it may be difficult to repeat precisely.
• The test case is not data-specific. Every tester could enter a different search term and
replacement term. If a defect only occurs for certain terms, it will be difficult to reproduce.

174 CHAPTER EIGHT