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

7.
8.
9.

test environments and their management
testing strategy (chess board)
<Repeated> testing details for each development phase
(a). development phase
(b). how can you tell when you are ready to start testing?
(c). how can you tell when you are fi nished testing?
(d). <Draft> test cases list (ID, title, and brief description)
(e). <Draft> test case writing schedule
(f). <Draft> test case execution schedule
(g). <Draft> test case execution results analysis and reporting schedule
<Draft> overall testing schedule 10.

<Repeated>

This test plan table of contents has one item that begins with <Repeated>. This nota-
tion means that you should expect to repeat this item and all subitems for as many
times as there are development phases.

<Draft>

This test plan table of contents has several items that begin with <Draft>. This nota-
tion means that at the time the test plan is fi rst written, there is insuffi cient informa-
tion from the development activities to fully document the <Draft> items. So the
test manager and test team construct the test plan with the best answers they have at
the time or leave a placeholder in the documentation for later entries. The test plans
must be revisited regularly to update the <Draft> items with new information and
revalidate the whole plan. All of the <Draft> items in the test plan should be fi nal-
ized by the time the Preliminary construction development phase is started, usually
one third the way through the development process.

Here is a brief description of each test plan item:

1. Application(s)/systems(s) to be tested —the application or group of applica-

tions that are included in the current testing effort.
Testing objectives and their rationale —the specifi c objectives that testing
must achieve for the application(s)/system(s) named in item 1. Objectives
must be focused on business needs and perceived business risk. Good object-
ives are measurable and achievable within the development project schedule.
Testing objectives like “we'll test till we're tired” or 'we'll test till it is time
to ship” are unacceptable.
Scope and limitations of the test plan —we need to state what will be tested
and what will not be tested to more accurately forecast testing resource
requirements and to set appropriate development project expectations.

2.

3.