Test Planning - Software Testing: Testing Across the Entire Software Development Life Cycle - page 88

based on absolute screen position. If screen position is part of the software require-
ment or specifi cation, then be alert to how different kinds of screen monitors and
screen display resolution will probably distort that positioning. This issue arises
more when using automated testing tools than when using manual scripting due to
the precision that the tools bring to the expected versus actual result comparisons.

5.3.2.1 Expected versus Actual Results in a “Failed” Execution Step

When the expected results match the actual results, the step is said to have “passed”
the test. When the expected results do not match the actual results, the step is said
to have “failed” the test and further diagnostic analysis is required. There are at
least two possible causes of a “failed” step: the expected results are incorrect or
the actual results are incorrect. Incorrect expected results can come from several
sources starting with the tester's incorrect understanding of what the expected
results should be and continuing to the developer's incorrect understanding of what
the expected results should be to the business expert's incorrect understanding
of what the expected results should be. If the tester, the developer, and the busi-
ness expert all agree on the expected results, then the “failed” step has revealed a
software defect. Who, when, and how the software defect is corrected is one of the
topics in Chapter 12.

5.3.2.2 Validate Test Case Step Actions

Test case validation is a double check of the step actions and expected results with
the software requirements, specifi cations, and business expert. The risk of not
validating test cases is the increased likelihood that the test team will incorrectly
report a number of “failed” step actions as software defects instead of step action
design defects (testing defects). Put yourself in the shoes of a developer who is under
much pressure to deliver a complex application on a tight deadline. Your work has
just been interrupted a third time today to attend a meeting with the test team to
discuss another suspected major software defect … and the last two meetings were
halted 15 min into the discussion when you pointed out that the tester's expected
results did not match the software specifi cations. How many more of these kinds of
meetings will you attend before you tell your development manager that testing is a
waste of time?

5.4 WRITING YOUR TEST PLAN AND TEST CASES
IN THE REAL WORLD

It would be so nice for the test team to be able to walk into a development project
and fi nd all of the information needed on the fi rst day to write all the test documents.
As you have probably guessed, that is not how things happen. There defi nitely is
enough information at the beginning of the development effort to draft the test plan,
but the details suffi cient to write test cases will not surface for a while. When they