Test Strategy and Test Plan
Test Strategy
A Test Strategy document is a high level document and normally developed by project manager. This document defines “Software Testing Approach” to achieve testing objectives.
The Test Strategy is normally derived from the Business Requirement Specification document.
The Test Strategy document is a static document meaning that it is not updated too often. It sets the standards for testing processes and activities and other documents such as the Test Plan draws its contents from those standards set in the Test Strategy Document.
Some companies include the “Test Approach” or “Strategy” inside the Test Plan, which is fine and it is usually the case for small projects. However, for larger projects, there is one Test Strategy document and different number of Test Plans for each phase or level of testing.
Components of the Test Strategy document
- Scope and Objectives
- Business issues
- Roles and responsibilities
- Communication and status reporting
- Test deliverables
- Industry standards to follow
- Test automation and tools
- Testing measurements and metrices
- Risks and mitigation
- Defect reporting and tracking
- Change and configuration management
- Training plan
Test Plan
The Test Plan document on the other hand, is derived from the Product Description, Software Requirement Specification SRS, or Use Case Documents.
The Test Plan document is usually prepared by the Test Lead or Test Manager and the focus of the document is to describe what to test, how to test, when to test and who will do what test.
It is not uncommon to have one Master Test Plan which is a common document for the test phases and each test phase have their own Test Plan documents.
There is much debate, as to whether the Test Plan document should also be a static document like the Test Strategy document mentioned above or should it be updated every often to reflect changes according to the direction of the project and activities.
My own personal view is that when a testing phase starts and the Test Manager is “controlling” the activities, the test plan should be updated to reflect any deviation from the original plan. After all, Planning and Control are continuous activities in the formal test process.
Components of the Test Plan document
- Test Plan id
- Introduction
- Test items
- Features to be tested
- Features not to be tested
- Test techniques
- Testing tasks
- Suspension criteria
- Features pass or fail criteria
- Test environment (Entry criteria, Exit criteria)
- Test deliverables
- Staff and training needs
- Responsibilities
- Schedule
This is a standard approach to prepare test plan and test strategy documents, but things can vary company-to-company.
What is a Test Policy Document?
A Test Policy is a high level document and is at the top of the hierarchy of the Test Documentation structure.
The purpose of the Test Policy document is to represent the testing philosophy of the company as a whole and to provide a direction which the testing department should adhere to and follow. It should apply to both new projects and maintenance work.
Setting an appropriate test policy by senior managers, provides a robust framework within which testing practitioners can then operate. This will help to ensure the maximisation of the strategic value inherent in every project.
Contents of a Test Policy Document
1. Definition of Testing
Organisations need to be clear why they are testing. This will influence the remainder of the policy document and also the detailed testing techniques that are selected by test managers at the programme and project level.
From the understanding of why testing is required it is possible to specify what the purpose of testing is within the organisation. Without this fundamental linkage the test effort is destined to fail.
Example: “ensuring the software fulfills its requirements”
2. Description of the test process
It is vital to establish a solid view towards the test process. We should address questions like, which phases and subtasks will the test process include. Which roles will be involved and the document structure associated with each tasks, as well as what test levels need to be considered.
Example: “all test plans are written in accordance with company policy”
3. Test Evaluation:
How are we going to evaluate the results of testing, what measures will we use to ensure test effectiveness in the project?
Example: “effect on business of finding a fault after its release”
4. Quality Level to be achieved:
Which quality criteria are going to be tested and which quality level is the system required to achieve prior to its release with regards to these criteria?
Example: “no outstanding high severity faults prior to products release”
5. Approach to Test Process Improvement
How often and when are we going to assess the usefulness of the current processes in place and what elements need improving and techniques that shall be used to improve the processes.
Example: “project review meetings to be held after project completion”