A kind of tips and tricks that will make this daunting process easier. Now there’s a lot of misconceptions about how to create test plan. It is a huge theoretical document and to actually write it you will have to go through a certain level of a professional qualification.
How to write a test plan?
Actually, we can begin with the most important known eleven point checklist. Because at the end of the day when you plan well you execute better. Keep in mind that planning does not have a standard structure. It does not have XYZ ingredients mandatorily for it to be effective. Moreover, test plan is a document that is most of the times created by one representative from the QA team usually the Test Lead or the Test Manager, whoever is in-charge for the overall delivery of the QA. However it’s not just a one person effort it is never going to be something that is one-time event – planning is a continuous activity.
A lot of times people will think that it is just like a calendar which will tell you day 1 person 1 starts. It’s more like a your instruction, booklet on how you conduct your day-to-day activities. When to do them, what to do exactly, how to do and what to expect, all of these are very well documented in a well-written test plan.
What are the contents of a test plan?
- Scope – Test scenarios / test objectives that will be validated
- Out of scope
- Test scenario preparation
- Documentation – test cases / test data
- Test cycle – how many cycles
- Start and end date for cycle
- Roles and responsibilities:
- Team members are listed
- Who is to do what
- What documents(test artefacts) are going to produce at what time frames
- What can be expected from each documents
- Defect management
- Risks and risk management – risks are listed
- Exit criteria
Now very important first thing is the scope. Scope is very important because unless you know the boundaries it’s difficult to understand what extent of work are we dealing with.
Out of scope
Then it is very important for QA teams to mention out of scope. Although, the reason why we have to be very clear with the test plan is not only because we are giving instructions to our own QA team. But at the same time we are sharing the test plan document with the development, business analyst, the client and with the project manager.
So a test plan document is like a handshake that you provide with all of these team members. Whatever you provide in here is a way of communication, is a way of establishing the clarity with the rest of the project team members. So when we are including the scope it is also good idea to include what is not in scope.
Let’s say you are not going to deal with performance testing. You’ll go ahead and mention that “performance testing is not a part of this release”, we are not going to test it. For instance, if there are 10 features and you don’t have the data to test one of them, you’ll go ahead and mention that “because of the unavailability of the data this is something you’re not going to test”. So for this release requirement XYZ is out of scope. When it comes to test planning, this is one of the areas where you might want to provide excessive data instead of in excessive information as opposed to less. So here less is not more, more is also less in some circumstances so be sure to include everything.
Assumptions is another way to say all the prerequisites that we would need from our end as a QA team. The team has to be informed before it go ahead and perform the testing.
Schedules are more about how much time we are going to take and milestone list. For instance, exactly what time a particular phase in testing is starting, what time a particular phase is ending and when is the next phase.
Roles and responsibilities
This is the place to list the team members and what is their job. However, you have to know that the test plan is not a calendar that will remind you to do something on a certain date. It is more like a live document that you use on a daily basis. Firstly, It will basically tell you how to conduct your work on a daily basis. Secondly, it will tell you the list of deliverables – what do you expect, what kind of output do you expect, at what intervals, environments, what service exists and who is going to maintain what, where is the communication list for that.
If you are going to use a tool you will have to define rules about it. Like how you are going to use them and in what circumstances, who should have access to them, who should not, if you need access who should you contact, all of that information. Like Snapics, you should add it in the section which describes the visual testing.
Should be incorporated in your test plan coming to defect management. Defect management also is an integral part of your test plan. There should be a defect tracking and reporting flow chart. Everyone has to use it, whether you are a new tester or whether you’ve been in the team for 10 years. It’s a good idea to lay out some ground rules so that there is no differentiation in the behavior or the way work is conducted by different people who have different experiences.
To do that it’s a good idea to sit down and write your test plan document as comprehensively as possible. You can write the defect tracking and reporting processes listed out. It will also give you an idea of the defect severity. Lay out your ground rules for when you find a bug, how do you assign a particular severity level to your bug. Some teams use low, minor, high, critical, blocker, whatever it is, that your team is going to follow, lay out the rules.
Risks and risk management
Risk management in the test planning phase is all about making aware of what kind of problems are going to come up and listing those problems out. For instance:
- schedule is a risk
- not having enough resources is a risk
- defect found too late
Any problem that you’re anticipating with your testing project to go wrong, just go ahead and list them in the risks.
Then do an impact analysis and rate the problems as high, medium, low. Firstly, deal with all the high risks. Also, you have to create the mitigation plan where you will come up with possible solutions on how to avoid particular problem or how you can recover from that problem if it really occurs. The mitigation plan is where you will provide that information again.
As additional you can include natural disasters and all you don’t have to do it at that level. But try to think for them beforehand. Usual kind of risks that QA teams encounter are scope changes, development team not being ready, using a tool that is incompatible with the sort of testing.
Finally there is also exit criteria. When to stop testing is an important question and we have to ask ourselves that very often. Whatever it is the criteria that you set for your team, go ahead and incorporate that in your test plan. You have to decide when you need to stop testing. Example exit criteria – “this team has listed that if 100 test cases are executed and if 95 percent pass rate of test scripts is there, when there are no critical or high severity defects you can stop testing”. Basically you can come with your own set of rules on when you want to stop testing. Again, test plan really talks about:
- what to test
- when to test
- how to test
- which environment to test
- what tools to use
- what data to use
- who are the people
- what are they supposed to do
Now test plan is a topic that we deal with as two different segments:
- Test plan phase in the software testing lifecycle where the entire testing activity is planned beforehand
- Test as a dynamic activity and how it is in a continuous process. How it goes through phases of the software testing life cycle.
You can create test plan covering all the projects in the company, but you can create it as exclusively about one work project.
Having said that test planning, even though it is driven by one person it’s not going to be extremely successful if one person does it. For example, if the team lead is solely responsible for the creation. It’s a combined effort but the team has more like a contributory role than the role of leading the entire process.
Keep in mind that test plan is not the test strategy. The strategy is really about what you’re going to test and how you’re going to test it. This is very particular to the application under test. Very specific to the product that you’re testing.
Concrete test plan that has all of these contents will be sufficient. Moreover with the planning activity one thing that really works out is to sit down and strategize how you want to perform your testing beforehand. Once you do that get a common consensus from your team and once they all agree that is a good starting point for you to sit down and start documenting your test plan.
As we have already said about the test plan there is no standard structure and template. Whatever content that you have, if you can find a good way to represent it, you can re-use it as your template. Don’t write difficult templates, because difficult templates actually don’t serve any purpose other than complicating your daily live as testers. As long as your test plan is addressing every aspect of your testing activity just use it for the rest of the testing engagement.
Keep your plan always up to date. Above all, a very well-planned testing engagement has a very high success rate. It really worth to invest time in creating a good test plan.