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

(d). Actual results —the particular software behavior or

response actually observed from executing the step action. Examples of
actual results include screen responses, printer responses, fi le responses,
and network responses.

Placeholder

First attempt to execute this test case date: time —this item
documents the date and time when the steps of the test case are fi rst attempted. This
metric helps the test manager measure testing progress toward 100% test cases at-
tempted.

12. Placeholder

Number of attempts to successf ully execute this test case —
this item measures how many attempts become necessary to achieve a successful test
case execution.

13. Placeholder

List of software defects discovered by this test case —the
log of genuine, correctable software defects discovered by this test case. If the
software development process does not change signifi cantly from project to project,
then this log will begin to reveal defect patterns that may forecast the approximated
number of defects to be discovered by the next development project. If the software
development process does change signifi cantly over time, then this log can demon-
strate how much the new development process increases or decreases the software
quality (fewer defects) by development phase. This kind of defect log interpretation
is the subject of an entire section in Chapter 12.

14. Placeholder

Is this test case executed successfully? (yes/no) —this item
is answered only after the fi rst test case attempt. The answer can subsequently be
changed from “no” to “yes” after any number of attempts that achieve successful test
case execution. Usually, some of these attempts occur after software correction in
order to confi rm the correction as well as achieve successful test case execution.

15. Placeholder

5.3.2 Step Action

Step actions are the documented keystrokes, mouse movements, and screen render-
ing for all of the end user steps to complete a business task. Using the data entry
screen testing example, a sequence of step actions would describe the mouse or key-
board commands to move the cursor to the next data fi eld to be tested. The next step
actions would document the specifi c data entered by keyboard or selected by mouse
from a dropdown menu. After a series of these keyboard entries and mouse move-
ments on the screen, the next step actions might describe a “request completed” mes-
sage that appears below the submit button or in a separate window. The overt intent
of the step actions is to cause the system under test to behave as if the end users were
performing routine business activities.
One of the major issues confronting the test case writer is the degree to which
the test case is dependent on visual screen positioning of objects. Screen objects will
change position (even by a pixel or two), change label, change label font, change
color, or change some other property. If screen position validation is not a testing
objective, then the test case author needs to avoid specifying the expected results