QA Test Strategy: [Product and Version]
[Document
Version history in format MM-DD-YYYY]
1.0 PROJECT OVERVIEW
[Brief
description of project]
1.2
PROJECT SCOPE
[More
detailed description of project detailing functionality to be included]
2.0 MATERIALS CONSULTED
[Identify
all documentation used to build the test strategy]
3.0
TESTING
- CRITICAL FOCUS AREAS
[Areas
identified by developers as potential problems above and beyond specific
feature enhancements or new functionality already given priority 1 status by
QA]
- INSTALLATION:
[Installation
paths to be qualified by QA. Not all products require installation testing. However,
those that do often have myriad installation paths. Due to time and resource
constraints, QA must prioritize. Decisions on which installation paths to test
should be made in cooperation with the technical product manager. Paths not
slated for testing should also be identified here.]
- GUI
[Define
what if any specific GUI testing will be done]
- FUNCTIONAL
[Define
the functionality to be tested and how it will be prioritized]
- INTEGRATION
[Define
the potential points of integration with other MediaMap products and how they
will be prioritized and tested]
- SECURITY
[Define
how security issues will be tested and prioritized]
- PERFORMANCE
[Define
what if any performance testing will be done and its priority]
- FAILURE RECOVERY
[Define
what if any failure recovery testing will be done and its priority]
3.1
TECHNIQUE
- [Technique used for testing. Automation
vs. Manual]
3.2
METHODOLOGY
[Define
how testers will go about testing the product. This is where you outline your
core strategy. Include in this section anything from tester assignments to
tables showing the operating systems and browsers the team will qualify. It is
also important to identify any testing limitations and risks]
4.0 TEST
SET-UP
4.1 TEST
PRE-REQUISITES
[Any
non-software or hardware related item QA needs to test the product. For
example, this section should identify contact and test account information for
3rd party vendors]
4.2
HARDWARE
QA has
the following machines available for testing:
Workstations: Servers:
[Include
processor, chip, and memory and disk space]
Other:
[Identify
any other hardware needed such as modems etc.]
4.3
SOFTWARE
[Identify
all those software applications QA will qualify with the product and those QA
will not qualify. For example, this is where you would list the browsers to be
qualified. It is also important to identify what will not be qualified (for
example, not testing with Windows 2000)]
4.4
PERSONNEL
[Identify
which testers are assigned to the project and who will test what. It is also
important to identify who is responsible for the creation of the test strategy,
test plan, test cases, release package, documentation review etc.]
5.0
COMPLETION CRITERIA
[Identify
how you will measure whether the product is ready for release. For example,
what is the acceptable level of defects in terms of severity, priority, and
volume?]
6.0
SCHEDULE
6.1
Project Schedule
- PRD Review completed by [MM-DD-YYYY] -
[STATUS]
- Functional Specification completed
[MM-DD-YYYY] - [STATUS]
- Release Date approved by [MM-DD-YYYY] -
[STATUS]
- Test Strategy completed by [MM-DD-YYYY]
- [STATUS]
- Core Test Plan (functional) completed by
[MM-DD-YYYY] - [STATUS]
- Readiness Meeting - [STATUS]
- QA Process Review Meeting - [STATUS]
- Release Board Meeting - [STATUS]
- Release on [MM-DD-YYYY] - [STATUS]
6.2 Build
Schedule
- Receive first build on [MM-DD-YYYY] -
[STATUS]
- Receive second build on [MM-DD-YYYY] -
[STATUS]
- Receive third build on [MM-DD-YYYY] -
[STATUS]
- Receive fourth build on [MM-DD-YYYY] - [STATUS]
- Receive Code Freeze Build on
[MM-DD-YYYY] - [STATUS]
- Receive Full Regression Build on
[MM-DD-YYYY] - [STATUS]
- Receive Gold Candidate Build on
[MM-DD-YYYY] - [STATUS]
- Final Release on [MM-DD-YYYY] - [STATUS]
7.0 QA
Test Matrix and Test Cases:
