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

6. Suggested test data —this item identifies the minimal amount of data and

most useful data sources for executing this test case in the test environment.
For example, if the application under test is a payroll system, then a copy of
the current employee master file would be one of the most useful data source
for testing. The number of employee records needed for testing this test case
would depend on the testing goals. Usually, a representative sample of em-
ployee records will be adequate for testing (see Generic black box testing
techniques in Chapter 7). Sometimes it requires less effort to use a copy of
the whole file rather than to carve out a representative sample.
Suggested test tools —if the tester is knowledgeable about automated test tools,
this is where the tester suggests one or two that have capabilities particularly
appropriate for executing this test case. A recap of all tool suggestions across
all test cases in the test plan becomes the basis of the test manager's rec-
ommendation regarding the automated test tools in the testing environment.
Not all test cases lend themselves to automated test tool usage. The cost of
automated test tools makes them prohibitively expensive for a relatively small
number of executions. Test tools will be examined further in Chapter 11.
Test startup procedure —this documents what hardware, software, and data
must be available to start the test execution. It further identifies how the
required software including the application under test must be launched or
made active in order to allow the first execution step of this test case to be
accomplished.
Test closedown procedure —this documents how to gracefully stop all the
software launched or made active including the application under test. A
graceful software stop allows the software activities to idle down and the
software to terminate normally.
Test reset procedure for rerun —this documents what must be done between
the most recent test execution closedown and the next test startup in order to
allow this test case to be executed again. Most times, this section deals with
restoring data to its previous state prior to adds, changes, and deletes caused
by executing this test case after the startup.

7.

8.

9.

10.

11. Test execution steps —this list of items is repeated for each new

step number. One execution attempt of this test case is achieved by perform-
ing all the steps once in step number order.
(a). Step number —a unique number that sequences the test case steps for-
execution.
(b). Step action —the specifi c, fully described action taken by a tester to evoke
a desired software behavior. Examples of step actions include keystrokes,
mouse movements, button clicks, drop-down list selections, and voice com-
mands.
(c). Expected results —the particular software behavior or response expect-
ed from the step action. Examples of expected results include screen
responses, printer responses, fi le responses, and network responses.

Repeated