 Define
the Strategy
When tackling a large project, it is essential to define the
requirements for a successful process. In your document, you
want the following as a minimum:
- Cover page, titled "<Project Name> Test
Strategy Document", or "<Project Name> Test Plan",
with a date and version number. Usually, your company logo or
department name is at the top. Don't forget to list yourself
as author, as well.
- Table of Contents.
- Introduction, saying what this test project is all
about.
- Scope, defining what will be tested, and what will
not, in general terms.
- Stakeholders, listing all people with an interest
in this project. This is usually shown as a simple matrix with
two columns as follows; note that "Audience" is often
used instead of "Stakeholder".
|
Stakeholder |
Purpose |
|
Project Manager |
To ensure testing plan is deemed sufficient to meet business
requirements. |
|
Application Team Leader |
To commit to resources required from IS Team. |
|
Financial Controller |
To view plan as Project Sponsor of <Project Name> changes. |
|
Testing Team |
To ensure understanding of and commitment to testing process. |
- Version Control, which is a simple matrix as follows,
to keep track of changes to the document:
|
Version |
Date |
Author |
Reviewed by |
Changes |
|
0.1 |
27/5/2000 |
J. Doughy |
F. Flintstone |
inital creation of document |
|
0.2 |
29/7/2000 |
J. Doughy |
F. Flintstone |
added audit requirements |
Most people use the format 0.1, 0.2, etc. for draft versions.
Once it becomes an approved (signed off) document, the number
is changed to 1.0 and subsequent updates are incremented on that
number. Large updates will result in 2.0 and so on.
- Approvals, which is a simple matrix showing who has
approved the document and allowing space for a signature and
date:
M. Maximillian
ABC Project Manager |
|
|
Date |
|
- Hardware Requirements, if any, should be spelled out.
- Software Requirements should be identified, including
the operating system, applications, any test tools, and ancillary
requirements such as Word and Excel.
- Personnel Requirements should also be identified:
who will do the work, and what is their specific role.
- Assumptions should be listed; remember that "ASSUME"
makes an "ASS" out of "YOU" and "ME";
spell out your assumptions. If you are assuming the IT Department
can provide help in backing up and restoring files, say so, and
list the IT Department manager as a stakeholder.
- Initial Preparation Requirements should be clearly
identified. If the database must be in some specific state, identify
this. If a billing run must be done before testing starts, say
so. Be very specific about what needs to be in place before testing
can start.
- Business Rules to be Tested or Functions to be
Tested should be listed. You don't need to go into details
about exactly what or how you will test these things, but you
should tell the reader exactly what will be tested. It is often
useful also to list the things that will not be tested,
but these should have been defined in the Scope.
- Acceptance/Rejection Criteria should be defined so
that everyone clearly understands what will happen if problems
are found.
- Schedule of Events should list when the different
things will occur. It is up to you whether you specify exact
dates ("September 17") or relative dates ("test
day 14"). The former can be used when you know the software
will be delivered on time and you expect things will progress
smoothly; the latter is better when you expect delays. "Test
Days" don't have to be sequential calendar days; for example,
Test Day 1 might be August 12, but Test Day 2 might be August
17.
|
|