Page 183 -

• The test case does not specify how the data is entered into the field. It is possible that a
problem might come up when the user uses the tab key to navigate between fields, but
cannot be reproduced by clicking on them.

TABLE 8-3. This poorly designed test case does not describe the interaction precisely enough
Steps 1. Bring up search-and-replace.
2. Enter a lowercase word from the document in the search term field.
3. Enter a mixed-case word in the replacement field.
4. Verify that case sensitivity is not turned on and execute the search.
Expected results 1. Verify that the lowercase word has been replaced with the mixed-case term in lowercase.

In short, this test case is not repeatable. It may seem intuitive to make the test case more
general, in order to capture a wider range of functionality. However, the test case itself
will be run only once during each test iteration. Instead of trying to make the test case
more general, multiple test cases should be added to the test plan, in order to verify each
specific type of test. For example, there should be separate test cases for clicking in the text
field and tabbing between them. If the tester wants to verify that the find-and-replace
function works with long strings as well as short ones, or for numbers and symbols as well
as alphabetical characters, all of those things should be separate test cases. (The test case
name should be used to differentiate between these tests.)

Another important characteristic is that each test case describes one—and only one—test.
The reason for this is that the test case should isolate the specific behavior that is being
tested, to ensure that any defect that is found is a problem with that feature only. One of
the complexities of software is that there are usually an infinite number of possible feature
combinations, and the only way to make sure that those combinations are not interacting
improperly is to isolate each specific behavior. That makes it much easier to determine the
root cause of any defect found.
For example, Table 8-4 contains the “Expected Results” section of a poorly designed test
case that exercises all of the bullet points in requirement FR-4. If a defect were found in
bullet point number 4, it would be difficult to determine whether the defect arose because
those specific actions were done in sequence, or if it were simply an isolated defect.

TABLE 8-4. This poorly designed test case has more than one interaction
Expected Results 1. The search and replace window is dismissed.
2. Verify that in line 36 of the document, the text THIS IS THE SEARCH TERM has been replaced by
THIS IS THE REPLACEMENT TERM.
3. Verify that in line 38 of the document, the text this is the search term has been replaced by this
is the replacement term.
4. Verify that in line 43 of the document, the text This is the search term has been replaced by This
is the replacement term.
5. Verify that in line 44 of the document, the text This Is the Search Term has been replaced by
This Is the Replacement Term.
6. Verify that in line 44 of the document, the text thIS is the SEarCh Term has been replaced by
This IS THE Replacement TeRM.

SOFTWARE TESTING 175