Estimating Your Testing Effort

“How long is it going to take you to test the release?”

Heard that question before? What team hasn’t? It’s a fair question from the business, even if they don’t understand the complexities involved.

Often I’ll turn the question around, not to push back on the stakeholder, but instead to try and level-set on what the stakeholder’s goal is. Testing is emphatically not about “assuring quality.” Testers can’t do that, only the whole team can. Instead, testing is about providing information about the system/product/application’s value, risk, and suitability.

I’ll work with the stakeholder to understand their most important goals for the release, then focus my testing efforts around those goals. Those goals should include the stakeholders high-value areas and also high-risk concerns.

High-value areas might be things like

• Checking out properly handles credit transactions, including errors like invalid card numbers
• Users can save their profile information so it’s automatically retrieved next time they browse
• Players can no longer hack their mech to run 100 MPH and instead are limited to the 10MPH as specified in the rules

High-risk concerns might include

• No privacy information is surfaced outside the account holder’s profile
• No SQL injection is possible on public-facing pages. (A lesser risk is the same concern on internal pages)
• Performance for the five most-valuable workflows are within the agreed upon metrics

I’ll use that conversation to drive out what I feel is the needed level of effort given the stakeholder’s desire for clarity around their highest priority items.

Want to learn some approaches to estimating your testing effort? Join my pal Matt Heusser on 21 April for a webinar discussing different ways to get reasonable, realistic estimates fleshed out.

More information and registration at the QASymphony site for the webinar. Go sign up!