A Test Strategy document is a high level document where the software testing approaches are defined.
In other word defining how the testing activities will be carried out in order to achieve testing objectives based on SRS document (software requirement specification). It sets the standards for testing processes and activities. It is a static document that means does not change often.
Testing Approaches has two techniques:
- Pro-active: An approach where test design processes are initiated as early as possible proactively in order to find and fix the defects before the build is created.
- Re-active: In this approach testing will not start until designing and coding are not completed.
Mostly considered Test Approaches:
Test approaches are varies with different situations, project consideration, business requirements etc. Therefore, no particular test approach is applicable for a project rather a combination of approaches is advisable based on the circumstances.
- Analytical Approach:
In this approach the SRS document is analyzed. The most critical and important requirements will get tested first and other requirements will be tested latter. Usually, a Risk model is prepared after risk analysis and prioritizes those test cases, so that those critical test cases will be eliminated first. This is also called preventive approach since we are analyzing and prioritizing test cases early on.
- Dynamic Approach:
In this approach test are designed and executed simultaneously. It is a reactive technique of testing approach. As for example: Exploratory testing where testing and test design are being done simultaneously.
- Consultative Approach:
In this test approach, test design and test coverage are derived from the advice of the business people and/or technical experts outside the Testing Team. Testing here may be dictated by the end users of the system. As for example: Expert of Security Testing.
- Process or Standard Compliant Approach:
In this approach Test Assets are developed according to some industrial standard method such as IEEE 829. As an alternative, an Agile Methodology is followed. The actual testing effort might get started early on or later during the SDLC when this approach is selected.
- Regression –adverse Approach:
In this approach designing tests are recommended in such a way that the regression defects get detected at the earliest. Automated functional regression tests are suggested as well as reuse of existing test material.
Test Plan describes actual testing activities such as:
- What to test – Software description, functionality, modules etc
- How to test – Test Steps, Test Cases, Expected Result, Actual Result
- When to test – Test Environment, Test Readiness, Deployment, Test Deliverables
- Who will test – Tester names with components and assignments
This document is prepared from SRS or Use Cases whatever is available.
A Test Plan is a document describing the test scope, approach, resources and schedule of intended activities. Among other test items, it defines:
- The features to be tested and features not to be tested
- Testing type – Unit testing, Integration Testing, System Testing, Functional Testing, Regression Testing, User Acceptance Testing
- Testing methods i.e. manual /automated, white box/black box/gray box
- The task of testing
- Who will do each task
- Degree of tester independence
- The test environment
- The test design technique
- Test entry criteria and exit criteria to be used
- Risk and contingency planning during testing activities
- Bug reporting method and classifications level s as per criticality