Difference Between Test Plan And Test Strategy
To find out the “Difference between Test Strategy and Test Plan,“ first, we need to see their definition. Here they are:
- Test Strategy is a high-level document that defines the approach for software testing. It is derived from the Business Requirement document. The project manager or business analyst develop a test strategy. It is a static document that sets the standards for testing, so not updated often.
- The test plan is derived from SRS (Software Requirement Specification), which is prepared by test lead or manager. The main goal of the test plan is to include all the details related to testing, such as what to test when to test, how to test, and who will be the tester. The test plan is often not updated, but if there is some new feature or change introduced, then it has to be updated accordingly.
Now, let’s make a list of points that are included in both respects.
Test Strategy
- 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 that need 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 define 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 the test strategy.
- Training: If there is some complex or new tool that is introduced to 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 the test strategy.
- Risks: Nobody can anticipate all the risks beforehand, but obvious risks can be avoided, and also a solution (if the risk occurs) can be included in the document for future help.
Test plan
- Test Plan ID: This is a unique ID that defines the test plan. It can be a number or name or mix of both, as per the convenience.
- Test environment: This section defines what kind of environment is needed for the testing to carry out. E.g., in device testing, usually, a virtual set up is made to test emergency calls.
- Features to be tested/Not tested: This will have all the details about the features which tester needs to test and what are the feature which is not tested (maybe because it is not yet implemented or not tested for that particular release).
- Entry/Exit criteria: These are the terms that define when to start or stop the testing. Standards will be defined under the test strategy and followed by testers in the test plan.
- Status: Whether a test case is passed or failed or not tested, all these test results are included in the test plan for a proper reason.
- Types of testing: The types of testing required, such as regression, functional, non-functional, stress, etc. are defined and then executed by the respective tester.
- Brief Intro: the Brief introduction is also included sometimes so that if any new member joins the team, he should get an idea of how things work.
The test plan is Test Strategy and test logistics (tools used, environment set up, etc.). The strategy defines what approach should be there for testing, and the plan has all the details on how that approach will be executed in a properly planned way. They both go hand in hand.
Test plan will have all the names of the testers who tested a particular script and also it maintains cycle numbers so that if some feature fails in this cycle, previous cycle can be referred to see if that particular feature was passed or failed, in this way it is easy to get the root of the issue and hence becomes easy to resolve it.
As mentioned above. Test strategy should not be modified very often because it sets some standards for the test plan. If standards are modified frequently, then it becomes difficult to stick to a particular plan, and changing plans frequently will affect the quality of the testing. Sometimes when small requirements are changed, we only need to update the test plan, but the test strategy remains the same.
If you like SoftwareTestingo and would like to contribute something to this community, then you can also write an article using our Contact us page or mail your article to softwaretestingo.com@gmail.com. So that we can review your article, and that also appears on the SoftwareTestingo.com main page and help other Testers.
Please Improve this article if you find anything incorrect by commenting on the comment box, and we are happy to work on the article to maintain accuracy and improvement.
