These are the most common sections:
State the objectives of this document at a high-level.
State the scope of the testing strategy, what will the testing concentrate around, at high-level; leave details for the Testing Scope.
State the testing activities and what documents result from these activities; for example a testing activity is Test Planning and the document resulting is the Master Test Plan or Test Plan.
Give the timelines around which the project is planned and where testing fits in this schedule.
I find that a diagram has a high-impact on the user (a Georgia rule of thumb is that I use color and diagrams to break the boredom of the text).
Describe the diagram in words.
The Project Charter or Master Test Plan usually state all the items in scope, just copy and paste from these documents. Add anything that’s missing or has changed from the last review.
Then state any items that are Out of Scope.
State all the risk that you envision, the higher the risk – the higher the test priority.
When you start testing you will want to start with the high-priority items, then test medium-priority and if time permits test low-priority functionality.Risk Analysis is very important from this point of view because it drives the whole test strategy. When giving the risk state how to you plan to mitigate (to alleviate, to make less severe) and what is the contingency plan (back-up plan in case this happens).Additionally you may want to say what is the impact of each risk.
7.1 Constraints and Dependencies Constraints are for example:
a. You need the last version of a program but you will use a previous version that has limited capability because the last version is not available.
b. You need an automated tool, but you only dispose of a manual tool. You can do the job but not entirely. Dependencies: for example the time you can test a function is dependent on developers delivering that function. You are available to do the job but you depend on somebody else.
7.2 For a test approach overview, you can draw a nice Visio diagram, stating the test cycles, what you plan to do within each test cycle.
Describe the diagram, basically detailing how you plan to test the application: how many people will be testing, they will participate in review meetings, they will write test cases, and so on.
7.3 You should give details about time and method the code is delivered; if you have an application that uses internal and external code explain who writes the code.
7.4 Also, what is the strategy for dealing with defects: process of submitting defects, defect life cycle, or how will the fixes be delivered once Dev provides them.
7.5 What is the Change Management Process – how are you going to deal with Change Requests, is there a CR template, what is the submission process.
Test Environment refers to hardware, software platforms that need to be set up (prepared) in order for testing to take place. It takes time to set up the environment and the requirements might be different depending on the environments.
What kind of tools will you are using to write and execute test cases, or to report defects. Do you need different tools in order to run your manual and automated test cases? If yes, which ones are these? Do you need to set them up in advance or are they available at the time of testing?
10.Roles and Responsibilities
Basically, this is who’s doing what. For example who is writing test cases, who is the test lead, who is the PM, who is the developer. This has to be specific, with names, if known at the time.
Logistics need to be prepared for the testing activities: how many computers you will need, location of testers and the like.
This refers to how you will manage testing, how you will do reporting – will you report status of test execution every day, will you submit an execution report at the end of the week to management, will you have status meetings to discuss defects?
Good luck with the writing!