Page 181 -

TABLE 8-1. Test plan outline

Purpose
A description of the purpose of the application under test.
Features to be tested
A list of the features in the software that will be tested. It is a catalog of all of the test cases (including a test case num-
ber and title) that will be conducted, as well as all of the base states.
Features not to be tested
A list of any areas of the software that will be excluded from the test, as well as any test cases that were written but
will not be run.
Approach
A description of the strategies that will be used to perform the test.
Suspension criteria and resumption requirements
Suspension criteria are the conditions that, if satisfied, require that the test be halted. Resumption requirements are
the conditions that are required in order to restart a suspended test.
Environmental Needs
A complete description of the test environment or environments. This should include a description of hardware, net-
working, databases, software, operating systems, and any other attribute of the environment that could affect the test.
Schedule
An estimated schedule for performing the test. This should include milestones with specific dates.
Acceptance criteria
Any objective quality standards that the software must meet, in order to be considered ready for release. This may
includethingslikestakeholdersign-offandconsensus,requirementsthatthesoftwaremusthavebeentestedundercer-
tain environments, minimum defect counts at various priority and severity levels, minimum test coverage numbers, etc.
Roles and responsibilities
A list of the specific roles that will be required for people in the organization, in order to carry out the test. This list
can indicate specific people who will be testing the software and what they are responsible for.

The test plan represents the overall approach to the test. In many ways, the test plan serves
as a summary of the test activities that will be performed. It shows how the tests will be
organized, and outlines all of the testers’ needs that must be met in order to properly carry
out the test. The test plan is especially valuable because it is not a difficult document to
review, so the members of the engineering team and senior managers can inspect it.

The bulk of the test planning effort is focused on creating the test cases. A test case is a
description of a specific interaction that a tester will have, in order to test a single behavior
of the software. Test cases are very similar to use cases, in that they are step-by-step narra-
tives that define a specific interaction between the user and the software. However, unlike

use cases, they contain references to specific features of the user interface. The test case
contains actual data that must be entered into the software and the expected result that
the software must generate. A typical test case includes these sections, usually laid out in a
table:

• A unique name and number
• A requirement that this test case is exercising
• Preconditions that describe the state of the software before the test case (which is often a
previous test case that must always be run before the current test case)

• Steps that describe the specific steps that make up the interaction
• Expected results that describe the expected state of the software after the test case is executed

SOFTWARE TESTING 173