3 Tips for near-perfect Test Planning
Every plan is perfect until the execution happens. As a losing team’s coach once said: “We had a perfect plan on the paper. The only problem is that the match was played on the ground and not on the paper”.
So should we stop striving for better planning? Of course not. Rather we should learn from each execution so that our next plan is better than the previous ones. Taking a hint from this thinking, let me share 3 tips based upon execution failures to improve your test planning.
I have selected the tips based upon 3 layers of what I’m calling Agile test planning. Such that as a Tester, you are required to do “Release Planning” or asked to do an “Iteration Planning” or asked to do an “Individual Tester Planning”.
Let’s take an example of “Release Planning” first.
Many years ago my Employer decided to start offering solutions in the Mobile world. Before that we were only in the Desktop world. Our first solution was for Android and then we worked on a Platform that can produce Apps in Android, iOS or Windows. A year or so after this has happened, I was asked to do some test planning for a release meant for a Client in China. I ‘assumed’ that they’ll need mobile solution as it was our top priority then. So my plan started with Android and then iOS testing on Simulators and Devices.
The plan looked great. Our first iteration started and by that time, I had no interaction with the Client. Client started reporting a lot of bugs and all of them were reported in Windows Desktop environment. I learned that this Client is only interested in good old Windows Desktop solution and doesn’t care about mobile.
The lesson which I learned is my tip # 1 for this blog:
Always ask question rather than assuming things
Let’s now move to “Iteration Planning”.
In a project that I was part as the lead tester, the Product Owner complained that the number of new bugs reported towards the end of Iteration is far greater than the ones reported at the start. My first response was that as more things get ready for testing towards the end, more testing is done and hence more defects were found.
Then I gave it a deep thought by looking at the history of tests we were executed. One pattern was there that certain test plans produced higher number of defects (following the heuristic that Software Bugs are like Real bugs) and the test execution order was left on the tester to pick. Tester knew that this test plan will consume lot of time and energy, so they left these to the end.
The rule that we made afterwards is my tip # 2 for this blog:
Prioritize test execution based upon which tests will fail first
This article can help you get started on Risk Based Testing.
Let’s look at the last one called “Individual tester planning”.
When I was young and raw, I had very ambitious plans for myself assuming that I’ll get all things in my favor. I planned it 8 hours a day with no distractions. Eventually I couldn’t always finish the stuff that I committed at the start of Iteration.
With age and lot of experiences, I have become more realistic about my estimates and always consider it as a 6 hours day. I also account for unknown distractions like network outage, random meeting popping up, sick days and what not. It’s not that I give a pessimistic by including all those factors but I do keep margin for some of them.
The lesson that I learned is my tip # 3 for this blog:
A plan that doesn’t incorporate change is not a plan
What tips you can offer from your execution failures to improve test planning?