QA estimates are an important part of the Agile software development life cycle. Without reliable QA testing estimation techniques, there’s no way to know which features will fit into a release timeline.
As a result, it’s nearly impossible to have a successful sprint without estimates. And while many people think of estimates as something that only developers provide, it’s crucial to get estimates from the QA team as well.
QA Testing Estimation Techniques
When getting started, it can be difficult to get the hang of estimates. Many new QA testers wonder how they can possibly guess the number of hours ahead of time. Fortunately, a handful of pretty simple factors can help you get the hang of providing QA estimates.
Some aspects to consider when working on QA estimates include:
- The reliability of the team’s Agile process
- The skill of the developer(s)
- Devices that need testing
- The complexity of the feature or bug fix
QA Estimation Techniques in Agile
QA vs. Dev Estimates
Some companies use a set method for QA estimates. One example of this is using a percentage of the developers’ estimates. For example, let’s say that engineers estimate 40 hours to complete a given feature. If a company used the above strategy, with 25% for QA, they would automatically enter a QA estimate of 10 hours.
While it’s a popular strategy, this “one size fits all” approach can cause problems. In practice, it often results in teams over-promising and under-delivering on quality. Getting custom estimates directly from QA testers can be the difference between a late, buggy version and a successful release.
Do the Jira Stories Have What You Need for QA Estimates?
In order to give a good estimate, QA needs to know the details of the feature being developed. A vague overview won’t usually provide enough information for a good estimate. As a general rule of thumb, acceptance criteria should always be provided. QA should also feel empowered to ask clarifying questions and offer suggestions on user experience.
For example, say there’s a new video player being developed. Imagine the user story including details like “closed captioning, allowing users to save where they left off, next/previous buttons,” etc. With this information, QA would be able to give a much more accurate estimate than if the ticket simply said “video player.”