Question Asked By: N Hadimani
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
TEST SPECIFICATIONS: A document specifying the test approach for a software feature or combination or features and the inputs, predicted results and execution conditions for the associated tests.
It is a detailed summary of what scenarios will be tested, how they will be tested, how often they will be tested, and so on and so forth, for a given feature. Trying to include all Editor Features or all Window Management Features into one Test Specification would make it too large to effectively read.
However, a Test Plan is a collection of all test specifications for a given area. The Test Plan contains a high-level overview of what is tested for the given feature area.
Contents of a Test Specification:
- Revision History - This section contain information like Who created the test specification? When was it created? When was the last time it was updated?
- Feature Description – A brief description of what area is being tested.
- What is tested? – An overview of what scenarios are tested.
- What is not tested? - Are there any areas that are not being tested. There can be several reasons like... being covered by different people or any test limitations etc. If so, include this information as well.
- Nightly Test Cases – A list of the test cases and high-level description of what is tested whenever a new build becomes available.
- Breakout of Major Test Areas - It is the most interesting part of the test specification where testers arrange test cases according to what they are testing.
- Specific Functionality Tests – Tests to verify the feature is working according to the design specification. This area also includes verifying error conditions.
- Security tests – Any tests that are related to security.
- Accessibility Tests – Any tests that are related to accessibility.
- Performance Tests - This section includes verifying any performance requirements for your feature.
- Localization / Globalization - tests to ensure you’re meeting your product’s Local and International requirements.
- Nightly - Must run whenever a new build is available.
- Weekly - Other major functionality tests run once every three or four builds.
- Lower priority - Run once every major coding milestone.
