In this blog we are going to discuss what test strategy is all about, why test strategy is required when we would require a test strategy document and finally about how to write Test strategy document
What is a Test Strategy
A Test strategy is a static document that describes how the testing activity will be done. This is like a handbook to stakeholders which describes the test approach that we undertake, how we manage risk as well as how we do testing and what all levels of testing along with entry and exit criteria of each activity. This will be a generic document that the testing team would refer to prepare their test plan for every project.
Test strategy act as a guidelines/plan at the global Organization/Business Unit level whereas Test plan will be specific to project and always we should ensure that we are not deviating from what we commit in Test strategy
Why Test Strategy is required
It gives an Organization a standard approach about how Quality is ensured in the SDLC. When there is any typical risk involved in a program, how to mitigate those risk and how can those risks be handled. When every project adopt to the same standard, quality improvement will be witnessed across the Organization and hence Test strategy is important
When do we need a Test Strategy
Below could be some of the circumstances which would require Test Strategy.
When an Organization is forming a separate QA wing
When there is a change in QA Organization from normal QA model to TCoE / QCoE where the operating model and structure is changed
When QA leadership changes who comes with different perception
When Organization is adopting different tool approach for Automation / Performance etc
Contents of Test Strategy
Below are the contents of Test Strategy document
1) Brief Introduction about programs covered in this Strategy
2) Testing Scope and Objective
3) Test Planning / Timeline
4) TEM Strategy
5) TDM Strategy
6) Performance Strategy
7) Automation Strategy
8) Release and Configuration Management
9) Test schedule, cycles, and reporting
10) Risk and Mitigation
11) Assumptions
Brief Introduction about programs covered in this Strategy
This section covers the overall scope this Test strategy is going to be covered with. Important engagement and programs which will run based on this Test strategy.
Testing Scope and Objective
This section describes the following
What will be the different levels of testing conducted like Integration, System, E2E, etc
The process of review and approval of each stage
Roles and Responsibility
Defect process and procedure till final Test sign off
Test Planning and Timeline
This section covers in-brief the following
What are the programs going to be executed
What is the timeline that each program is going to constitute
What will be the infrastructure and tooling needs to support this program
Different Environment that will be used
TEM Strategy
Prior section describes the overall requirement and this section describes in detail about the Test Environment Strategy and covers the following
1) How to book Environment for project purpose including booking 3rd party Environment
2) Assess to Environment to users for project requirement
3) Environment integration and stability management
4) Test data refresh co-ordination
5) Post release Environment validation
6) Support and co-ordination requirement
TDM Strategy
Similar to Environment, different project test teams would require different data requirement and some would need to mock up live data. This section in TDM strategy would provide the below information
What are the forms to be filled and agreement to be in place to serve this data need
What type of data to be loaded and when it will be available
Who will be the point of contact for each program
If any 3rd party Vendor support is required, this would describe in detail of that
Performance Strategy
Based on various programs and its schedules listed in the prior section, performance strategy would describe how Performance Testing requirements would be fulfilled and what their tool strategy, license model is and team availability. If the team also does Performance Engineering, it would describe in detail about how it is performed
It cover details about Requirement phase (How NFR requirement will be gathered from stakeholders, Proof of concept procedure, how critical scenarios are defined.), Testing phase (How testable scripts are created, how data setup is done), Analysis and Recommendation (How performance issues are reported, sign off procedure)
Automation Testing Strategy
Similar to Performance Strategy, Automation strategy would describe how requirements are defined, tool strategy, license model, etc and also elaborate how the Automation team conducts feasibility approach till defining framework, developing scripts till execution and Continuous Testing if it is in-scope
Release and Configuration Management
This section describe the following areas of Release and configuration management
Overall release and configuration strategy
QA deployment and release calendar
How different Test assets are loaded and tracked
Co-ordination of QA Deployment
How QA audit is conducted
How production deployment is co-ordinated by the QA team
Change Management for any CR post-release is managed
Test schedule, cycles and reporting
This section details out about each program, its schedules, Test timeline, Test cycles and how reporting will be carried out.
Risk and Mitigation
This section describes overall risk management and risk mitigation process along with how it will be tracked and reported.
It also classifies various risk levels like Project level and program level risk and describes how it will be handled during the execution phase
Assumption and Dependencies
During Test strategy development the timeline of program etc are in a predictive stage as it could be for a period of 1-5 years and hence there is going to be a lot of assumption which should be listed in this section. Also, there are different teams which Testing team has to co-ordinate with like TEM, TDM, vendors, etc which needs to be called out in advance in the assumption and dependencies as any change in Project-level / Program level scope will have an adverse impact and it has to be called out in strategy as assumption and dependencies
How to write Test Strategy document
For now we have covered about what Test strategy is all about, why it is important and looked in detail about the contents of the Test strategy, it is now easier to define how to write better Test strategy document.
Before writing Test strategy we need to collect few information which is listed below:
List of programs that need to be handled in this stream
Programs and its releases objective and basic requirement it is going to meet
Criteria for Environment and Data management requirement
Timeline of each releases and it’s key stakeholders
Third party integration and vendor management details
Information about Test type and release frequency
Tool requirements/procurement process understanding
Basic assumption and dependency with outside QA Organization
This information will be collected by Program Test Manager after discussing with Key stakeholders of the program.
The collected information has to be discussed internally within the QA team Managers and assign responsibility to detail out further requirements to refine the Test Strategy.
If the program is going to be from the QA Transformation perspective, then further information has to be collected on the key QA levers that are going to run the program run differently.
After identifying the key levers, assign the responsibility of each lever to a dedicated person so that Strategy can be further fine-tuned and can be circulated to wider group.
Comments(0)