I learnt this the hard way! The enthusiastic tester in me always wanted to jump on to the execution phase without doing proper ground work. The thrill of reporting bugs seemed way more attractive than the boredom of estimating and planning test execution. Needless to say this happy-go-lucky approach was bound to fail sooner or later. Failure, in spite of hard work, forced me to dig deep and figure out what really went wrong. And that’s when the realization dawned – “Failing to plan is planning to fail”. Simply put, if estimation and planning is not right, there is a very real chance of missing deadline or missing critical use-cases or finding bugs very late in the qa cycle which might jeopardize delivery. The good news is it’s not that difficult to fix this problem. Trust me, this may sound as a bold statement, but it’s actually an easy (and interesting) problem to solve. The only thing you need to keep in mind, there is never a perfect solution and there is always scope for improvement :). The solution is easy, just start estimating and planning. The difficult part is how do you get better at it. Just be conscious that it takes time to master these skills and the only way to get better is keep learning from failures and practice religiously. Whenever an estimate or plan goes off, analyze what went wrong and figure out a way to not repeat the same mistake again.
Based on my experience and analysis of almost 12 years, I have come up with my checklist for estimation and planning. Please keep in mind, this is not the ‘right’ checklist or the universal guide. I am sharing what I have been practicing and I am sure this list will change with more experience and exposure. I would encourage people to read it, evaluate it and refine / enrich it with your thoughts and suggestions
- Work breakdown structure
Break down modules / features into smaller tasks having a thumb rule that LOE for testing any task should not be more than 1 day. If anything requires more than 1 day, you need to break it down further.
- Define testing scope
This should be done in collaboration with Product and Dev. It’s very much possible that for some feature, performance testing is as important as functional testing. So, define testing scope with Product and Dev and once defined, publish it to all the stakeholders.
- Capture full testing effort in Test management tool
Many a times we fall in the trap of not documenting all the scenarios in test management tool (like Testlink, JIRA). We document scenarios at a high level on the pretext of not having enough time. This may lead to a situation wherein number of scenarios to be actually tested are way more than the number of test cases present. In such a situation, it’s almost impossible to have real estimates.At least, have a placeholder test case for every scenario you want to execute.
- Capture all phases of qa cycle in Test management tool
Sometimes we divide qa cycle into multiple phases like integration phase, feature testing and sanity phase. If this is your testing approach, ensure you have tickets for all the phases in Test management tool.
- Buffer time
As a thumb rule, always have buffer time in your estimates. With experience you will be able to have a better estimate of buffer time.
Identify critical tickets and use-cases along with Product and Dev. Remember, not all tickets have the same the priority. There would be some tickets which are more important than others and these are the ones which define success or failure of the release. So, you need to pay special attention to these tickets. Make sure to publish prioritized items to all the stakeholders so that everyone is on the same page.
- Sequence execution
Test execution should follow prioritization rules. Items deemed critical by the team should be executed first. There is a natural tendency to go after easy items first as you can close them quickly, don’t fall in this trip. Never rush through critical items.
- Intermediate milestones
It’s highly advisable to have some intermediate milestones before final qa complete. For example, if your qa cycle is for 3 weeks then have milestones for each week. You can have milestones for:
- test coverage
- total # tickets with qa
- total # of critical tickets
Having intermediate milestones helps to make a judgement whether your sprint or release is on track or not.
This is my checklist of planning and estimation. In my opinion, everyone should have their own checklist. This organizes your execution and makes your delivery predictable.
Hope this was helpful, thoughts and suggestions are most welcome 🙂