QA Testing Estimation Techniques

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.

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.”

To learn more about optimizing Jira for QA, see our article on the Jira QA Workflow and Best Practices.

What Type of QA Testing Are the Estimates For?

Manual testing is usually the default type of QA testing. It’s considered by many to be the first level of defense against bugs and user experience issues. If the team only has manual testers, the test timeline should be divided into at least three parts:

Writing test cases
Testing new features
Regression testing to make sure old features still work

If automated testers are also on the team, the initial effort may increase the QA estimate. However, with QA automation in place, the long-term benefit will be saving time and lowering estimates for future sprints.

Learn more about the different types of software testing.

Developer Skill

How Experienced is the Developer?

There are many levels of expertise when it comes to developers. It’s a good idea to factor this into QA testing estimation techniques. You might wonder, “How do you know the abilities/speed of the developer on day one?” Psychic abilities, of course. (Just kidding.) The simple answer is, you don’t. Instead, it’s best to add points that will cover extra time for the first few test runs. After that, you’ll be able to predict the level of quality coming out of the development team, and can adjust your estimates accordingly. (Learn more about the developer and QA relationship.)

Feature Complexity

How Complicated is the Feature or Bug Fix That Needs QA Estimates?

There’s more than meets the eye with this one. For example, a feature could seem relatively simple. But when you break it down piece by piece, you might realize that there’s a lot more going on than you initially thought. That’s why it can be helpful to make a list of every part of a feature, which will help you provide more realistic QA estimates.

Device/Browser Coverage

How Many Devices and/or Browsers Need QA Estimates?

There’s a big difference between testing a feature on an iPhone X with iOS 12 vs. testing it on six types of iPhones, three versions of iOS, four types of Androids, and four versions of Android OS. (Not to mention tablets!) There’s also a big difference between testing a web update solely on the newest version of Chrome vs. the last four versions of Chrome, Firefox, Safari, IE, Microsoft Edge, and more.

The amount of coverage needed should play a big part in any QA testing estimation techniques. Sometimes the product owner provides the list of devices/operating systems/browsers that the company wants tested. Other times, they’ll look to QA’s expertise in determining this. In the latter scenario, reviewing market share data and, even better, the customer’s user analytics can help you come up with a fact-based coverage strategy. Once you have your list, voila — you can multiply the initial estimate by the number of scenarios it needs to be tested in.

You can also suggest doing full QA testing on a few devices, and spot-checking the others for design issues. This practice can cut testing time in half, saving both time and money.

Learn more about how to do cross browser testing.

Techniques for Communicating QA Estimates

It’s a great idea for your estimate to include coverage details and a breakdown of the level of testing needed. This can help the rest of the team understand why your estimated hours might sound high. From the outside, it might look like a task is a relatively small amount of work. But communicating all of the ingredients that went into the estimate can add a welcomed level of clarity.

It’s easy to feel nervous about giving a realistic estimate (which may seem unrealistic to the rest of the team). Many QA testers fear that their estimate will sound too high. But if you downplay your estimated hours, this will only result in more trouble down the road. After all, if a release date is based on an unrealistic timeline, it will inevitably be delayed.