Best Practices for Creating A Test Plan
After years of experience in the testing profession I have heard a lot about the ‘best practices’ for software testing. Sometimes people just want to share their best ideas, so you can use them too. Some stories I’ve overheard and noticed:
The planning
To start a project of, it is required of you to make a complete test process planning. In answer to the question: “How long will testing take,” you can never rely on historical data, considering each project is completely different. The standard answer you should give is: “Testing will take about 50% of the time that this project needs to write specifications and develop the software.” Generally people will be shocked and ask you to be more specific. You get to the details with writing a test plan.
The test plan
Creating a test plan is not difficult. You go to google and search for “Master test plan template”. In this template, enter as much as possible of what you already know about the project. It is a best practice to copy and paste most of the project plan, so you fit well in the way of working of the project manager. This gets at least half of the test plan filled. Then, fill as much as possible the rest of the test plan template. With some creative thinking, you will get very far.
Test Coverage
At some point in the test plan you get to the “risks” area. This is a much overvalued approach which is taught almost on every course on testing. Best thing to do is to delete this chapter and indicate that testing will do “a 100% coverage of the functionality”. Put in the place a list of features that you get from the project plan or other project documentation.
Budget & Planning
Then for every function you create an estimate of how long it takes to write test cases and test. Just per functionality just estimate some time you think is needed in hours or days.
Furthermore: How many testers would you need? There must be a global planning or so. On that basis, you can specify how many testers you need during your testing time. So if a project should last 60 days and you have estimated that you need 240 days you will need 4 testers for that project.
Start date of creating test cases and performing the tests can best be estimated by lucky guess. This is because every project will change schedule anyway, so you don’t need to spend too much time on choosing starting dates.
– Then just add a list of test tools that you want to use (MS Excel, MS Word, issue tool) and your plan is ready!
– If you are still left with some chapters in the template, just delete them. The things I subscribed above are all you need.
– Send the plan for approval to the project manager. You are expected to work for about three weeks on creating this test plan.
What did you just read?
Did you recognize parts of the stories above? Could you agree with them or even some parts of them? Please not that those parts will be the areas where you might want to study some more on testing. Maybe a colleague is telling some kind of story as you’ve read in this article. Run away or help him or her, because this kind of stuff is really killing our professionalism.
The message is: Keep critical of your own work and professionalism. Of course, everyone has a bad day or a project that is not going well. The main concern of the tester is to stay sharp and deliver valuable information about the quality to the stakeholders.
Have you got your own story (own experiences and learning) or did you hear about something comparable? Please leave a comment here.
https://www.testingcircus.com/best-practices-creating-test-plan/https://i0.wp.com/www.testingcircus.com/wp-content/uploads/Test-Plan-Testing-Circus-Rob-van-Steenvergen.jpg?fit=500%2C301&ssl=1https://i0.wp.com/www.testingcircus.com/wp-content/uploads/Test-Plan-Testing-Circus-Rob-van-Steenvergen.jpg?resize=150%2C150&ssl=1ArticlesBest Practices,Test PlanAfter years of experience in the testing profession I have heard a lot about the ‘best practices’ for software testing. Sometimes people just want to share their best ideas, so you can use them too. Some stories I’ve overheard and noticed: The planning To start a project of, it is required...Rob van SteenbergenRob van Steenbergen[email protected]AuthorRob van Steenbergen is an independent software test consultant from the Netherlands. He has over 15 years of experience in software testing with several organizations. Currently Rob is working for ThiemeMeulenhoff, an educational book publisher. The domains he has experience in are banking, software houses, government, embedded software, infrastructure and public transport. Besides projects with clients, he is involved with a Dutch test magazine as an editor, runs a website about test events (www.testevents.com), has his own blog about testing and writes articles for national and international magazines, such as the Testing Circus. Website – www.chickenwings.nl - Rob tweets at @rvansteenbergenTesting Circus
Hi Rob,
When I started reading your article I was about to bash your ass… Until I reached the last chapter that was 🙂 Great post!
I think including test planning in a dev plan would make sense, using storypoints and plan for testing with the whole team. Like this test data can be setup in time, impediments found earlier and risk can be managed in one single place. Then make sure your testers know how to check but also how to explore…that should get you going I suppose.
Nice piece… Especially the 100 percent coverage 🙂