Techniques for QA time estimation
The list of techniques below works for both QA specialists and their software development colleagues. These software testing estimation models work even better if the entire team practices them.
Use poker planning
Poker planning is an amazing technique to handle individual anxiety about giving high estimates. At the beginning of the planning session, everyone gets a dozen cards that have the number of hours to complete the task on them. When the project manager reads out a ticket, everyone shares their thoughts on how it should be tackled. The general sequence of work, the number of specialists involved, and potential blockers are just some of the aspects that you should bring up.
After the discussion, everyone on the team shows a card with what they believe is the required number of hours. Some people would usually have higher estimates than others, but that’s the point of the exercise. Have another round of discussion where people with higher/lower cards convince their teammates to change their minds. Ultimately, you will reach a consensus and move on to the next story to go through the same steps.
Linda Hoff, the Test & Release Management at Qlik, points out vital requirements for successive poker planning:
‘I like poker planning IF you have someone in the team that is brave enough to estimate high. I've been that person several times. It's tough, but we got a lot more realistic estimates.’
Another major benefit of poker planning is giving agency to everyone on the team. This is essential for adopting and observing the Scrum methodology in software testing. When a task involves several employees at different stages, you want to at least hear the pessimist out.
Alternatively, you can use the three-point estimation technique. While far less engaging, it covers a range of potential outcomes. You simply boot up your issue tracking system and look at the actual hours it took you to complete the task
Move on from hours
Estimating QA testing time is tricky on multiple levels. The same task can take a different amount of hours even for two QA specialists of the same seniority. In that sense, tight sprint planning will be disrupted pretty fast. It’s a matter of when, not if you will start to miss deadlines on certain tasks.
Prioritisation helps you see which tasks you’ll be the least sorry to be late on. Looking at the fixed number of hours, however, can still cloud your judgement. Here’s a neat piece of advice we got in our Linkedin software testing community from test engineer and YouTube author Karen Todd.
‘I like the idea of "effort estimation" as opposed to time estimation. Time is difficult because what may take one contributor an hour may take another contributor most of an afternoon. But then again what takes less effort for one person may take another person more effort. It's complicated.
I like T-Shirt sizing as a start. Think collaboratively as a team about how many systems this item will touch, how many people will be involved, how complex is it, what is the level of risk involved with implementing it... and rank the proposed features/tasks down in groups by "shirt size" (Small, Medium, Large, etc.)’
Another alternative to numerical hours is story points. They represent the relative complexity of a user story compared to what else is in the backlog. Story points are especially useful for teams with a mixed level of seniority. Testing estimations will absolutely be affected by the choice of QA specialists; the relative complexity expressed by story points remains the same.
‘We're Agile, so we use story points for estimation. QA time isn't directly estimated, but I can tell when a story has a lot of potential for the back-and-forth with the devs. When that happens, I encourage them to estimate higher and allow ample time for testing/retesting. It works well for my team.’
Get a testing strategy template that enables us to release 2 times faster
Adopt deadline-oriented approach
While testing has its beginning, the end is not as clear (unless it’s a test automation estimation). There is always room for more QA, even if it will ultimately take longer and longer to find the smallest of issues. Here’s how you can turn the tables:
‘I will usually ask "how much time can I have?" and I will try to determine if I could achieve adequate coverage in the time they give me to test. If my coverage will be poor or if I find a lot of bugs while testing, I try to assess risk and communicate risk to stakeholders. I let them decide if they want to give me more time or not. This keeps me from getting boxed by promises I cannot keep. In my experience, testing usually gets the short end of the project-schedule stick.’
While release deadlines are relatively stable, a tester may not necessarily know how deep the rabbit hole of a new feature goes. How do you make things more predictable for the QA specialist? Simple: run unit tests to catch conceptual flaws before your testers even see new code. A little bit of extra work from your devs makes effort estimation for software testing much easier.
Re-evaluate your estimates
One way to avoid disappointment in life is to adjust your expectations. Some people believe you can do the same in quality assurance. After all, you can’t miss a hard estimate if you put soft ones in your test management software.
‘When we get a big story, we try to break it into testable chunks and estimate those. Once the devs start working on it, they may find complications that can cause scope creep or just simply take longer than planned. If we get into that situation, the devs meet and discuss, and re-estimate the remaining work. This also works well: learn, readjust, and learn some more.’
This is a good tactic to align QA with the fluid nature of development. Any potential roadblocks that push a user story to the next sprint mean that your testers won’t be working on it. They could have spent some extra time polishing other features or go on the wild ride of exploratory testing. Planning development in smaller chunks would indeed also mean fewer disruptions to the testers’ calendar.
Don’t do any estimates
Time estimates are essential for planning, especially if you need to map out a whole sprint. But what if I tell you that you don’t need any estimates at all? Whatever your reaction was, it’s actually not me who will tell you that.
‘We work on Kanban, which means there is one large backlog of prioritised tasks instead of 2-week sprints. The developers do estimate their effort in story points, but our QA team doesn’t. When a developer implements a feature, I test/retest it at once. If there are multiple features waiting for QA, we go by the same priorities that developers set for themselves. Yes, there are no story-specific estimates for QA at all.’
It’s not just us: Qlik’s engineering team does not enjoy hard deadlines either, even if their spin is not as radical.
‘As soon as there is a date when something should be done, it is very difficult to do an estimate that is not affected by that date. So I prefer a flow of value without targeted release dates over release plans and committed dates. We have this constant flow for most of our features and it's awesome to see what difference it makes. We also have weekly releases, which helps a lot. If you are not done for this release, you have a new chance next week. We had monthly releases before and that was more difficult.’
This approach may also require your product team to be flexible about release deadlines. Shrinking sprints or moving on from fixed releases, however, gives you the freedom to innovate faster and ship new stuff ASAP. You can learn how well it went for us at aqua and pick up some more traditional Scrum tips in our blog article.
Conclusion
Estimation models in software testing are a very fun topic to explore. You can pretend time isn’t real, work as if time is not constant (which it is not in software development), or even reject the notion altogether. Whatever software testing estimation technique you use, giving more agency to testers and involving other stakeholders goes a long way.
You can also make estimates less of a problem if you reduce the amount of unpredictable work. This includes manual test generation, as you don’t fully know how many tests you need to fully cover a requirement. The time to make a test can differ quite a bit depending on the complexity, too.
The solution here is to bring in artificial intelligence. aqua’s AI copilot can make entire test cases from a description. Just think of key tests to cover a requirement, and aqua will create them for you.
AI testing doesn’t miss any estimates
