Difference Between Test Plan And Test Strategy

• 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 the project manager or business analyst. It is kind of static document which sets the standards for testing so not updated often.
• 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 is introduced then it has to be updated accordingly.

Now, let’s make a list of points which are included in both respects.

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 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 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 the risk occurs) can be included in the document for future help.

Test plan contains:

• Test Plan ID: This is a unique ID which 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. For e.g. in device testing, usually, a virtual set up is made to test emergency calling.
• 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 which define when to start or stop the testing. Standards will be defined under 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 test plan with 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 how things work.

Basically, 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 plan has all the details 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 test plan and if standards are modified frequently then it becomes difficult to stick to a particular plan and changing plan frequently will affect the quality of the testing. Sometimes when small requirements are changed, we only need to update the test plan but test strategy remains the same.