Test strategy is a high level document which defines the approach for software testing. It is basically derived from the Business Requirement document. Test strategy is developed by project manager or business analyst. It is kind of static document which sets the standards for testing so not updated often.
Test strategies describe how the product risks of the stakeholders are mitigated at the test-level, which types of testing are to be performed, and which entry and exit criteria apply. They are created based on development design documents. System design documents are primarily used, and occasionally conceptual design documents may be referred to. Design documents describe the functionality of the software to be enabled in the upcoming release. For every stage of development design, a corresponding test strategy should be created to test the new feature sets.
Test planning activities guides team to define Test coverage and testing scope. It also aids testers to get a clear picture of the project at any instance. The possibility of missing any test activity is very low when there is a proper test strategy in place. Testing strategy plan must have conversed with the entire team so that the team will be consistent on approach and responsibilities.
Test strategy is a guideline to be followed to achieve the test objective and execution of test types mentioned in the testing plan. It deals with test objective, test environment, test approach, automation tools and strategy, contingency plan, and risk analysis.
Test strategy contains:
- Scope and objective: The objective of the business and how much testing scope is there is defined under test strategy.
- Business Issues: How much is the budget of the project, how much time is required for testing, how much resources are needed etc. are the part of business issues which needs to be considered before the actual testing starts.
- Testing approach: What type of testing is needed (performance, load, stress, functional etc.) and whether the testing is only manual or automation or both are some of the crucial points which defines the testing approach.
- Test deliverables: What are the documents required from the testing team, how they would keep the record of the testing cycles etc. will be included here.
- Defect tracking approach: Which tool will be used for tracking the defects and how will the testing team communicate with the development team and how the flow would go for defects are decided at this point in test strategy.
- Training: If there is some complex or new tool is introduced in the business then it is helpful if the team members are given proper training. What type of training and the responsible person to conduct such training is defined here.
- Automation: If the project or business needs automation testing then the script language, tool used, reporting and code maintained is planned in test strategy.
- Risks: Nobody can anticipate all the risks beforehand but obvious risks can be avoided and also solution (if risk occur) can be included in the document for future help.
Preparing test strategy document
Every organization has their unique priority and set of rules for software designing, so do not copy any organization blindly. Always ensure that their document is compatible and adds value to your software development before following the template.
Step#1: Scope
It defines parameters like
- Who will review the document?
- Who will approve this document?
- Software Testing activities carried out with timelines
Step#2 Test Approach
It defines
- Process of testing
- Testing levels
- Roles and responsibilities of each team member
- Types of Testing ( Load testing, Security testing, Performace testing etc.)
- Testing approach & automation tool if applicable
- Adding new defects, re-testing, Defect triage, Regression Testing and test sign off
Step#3 Test Environment
- Define the number of requirement and setup required for each environment
- Define backup of test data and restore strategy
Step#4 Testing Tools
- Automation and Test management tools needed for test execution
- Figure out a number of open-source as well as commercial tools required, and determine how many users are supported on it and plan accordingly
Step#5 Release Control
- Release management plan with appropriate version history that will make sure test execution for all modification in that release
Step#6 Risk Analysis
- List all risks that you can estimate
- Give a clear plan to mitigate the risks also a contingency plan
Step#7 Review and Approvals
- All these activities are reviewed and signed off by the business team, project management, development team, etc.
- Summary of review changes should be traced at the beginning of the document along with an approved date, name, and comment
