How to make a Good ‘Test Plan’ – 10 steps

A good ‘Test Plan’ is often that well bound book on your glossy shelf which you never read. I must have created many test plans in my stint at Newgen Software, Legato and lately at Adobe and probably never consulted them again during the course of the testing. But its a well needed document. I was fortunate to not work in a highly process oriented company but we still need to make a plan, at least in the beginning of the project. Most of times I have seen people scouting for websites and what not to get that golden test plan template which they can just fill in and sort of get away.

I think we all do it in our youth and as I look back it all looks not-worth it :), the template hunting part. So let me take you through a decent or a good-enough test plan format w/o binding it in any template.

1. Think about the project for which you are going to create the test plan and explain it in few lines. Name this section as ‘Backround’ or ‘Context’ and have it as one of the first things. If you are testing a web-portal specializing in travel-experiences like (sneaking some publicity for this site) then mention something like “ghumakkar is a travel blog platform for traveler community and is primarily meant for sharing travel stories and to inspire the world……” and so on.

2. Introduction – talk about the test plan document. why you are writing this. Something like “….the purpose of this document is to identify the test strategy, resource planning, test method, bug handling……this would be a live document and would be referred for any process details like ‘how to log bugs for 3rd party’…..” and so on.

3. Goals – This is an important section and you would need to do some thinking here. The primary goal is to ship a product which works well. These are ‘Testing Goals’. In this section you dont need to mention too much detail and it can be just 3-4 lines
4. Test Strategy – The most important section. Take your heart out and mention as much as you can. To give you an example, you can have a strategy to test the software using

4.1 Automation (old features, legacy testing, regresssions)

4.2 Structured testing (checklists for actions, check-lists for set of actions or workflows)

4.3 Adhoc testing

4.4 Bug Hunts

4.5 White box testing

4.6 Beta Program

and so on. Also mention the overall process. For example you can write something like “We will first do a 3 hours basic testing and if it passes we would two round of full test cycle on WinXP and Win Vista and then we would log bugs. We will look at bug metrics, if it is so and so then we would do this else we would do that. We would wait for bug-fixes for sometime……”

This actually talks about the real thing on how you would do. You can also mention here the various kinds of testing which you would do.

5. Tools and Processes-Mention the s.w which you would use for automation, bug logging, version control, MD5 checking, check-sum matching, installer testing and so on. If you plan to use Excel to capture test cases then mention it. This is also a good time to think about any tools which you need to buy. Under processes, cover things like ‘how to log a bug’ etc. Some organizations have well defined process so refer them here.

6. Resources

6.1 Equipment – If you s/w need any special equipment then mention it. Detail it out so that it clear that what are the h/w you are testing on and what are the h/w you are not testing. Get it prioritized from your product manager or project manager.

6.2 People – How many, for how long.

7. Schedule – This section would talk about ‘Software Testing’ schedule w.r.t. project schedule. So if we are planing to release certain s/w at a said date then why testing would finish. By when you would complete your test rounds. When you would do performance testing and give performance nos. When you would engage in Beta testing.

8. Related Documents – project plans, engineering specs, design specs

9. Revision History – some people prefer this in the beginning, some at the end.

10. Risks and Dependencies – like attrition, changing requirements, late development hence less time for testing

There are various other things which you can add but I guess if you cover these 10 things then you are fairly covered.

Write back for more suggestions and your experiences.

Leave a Reply

Your email address will not be published.