Estimating testing effort means accounting for the QA work a story requires — test design, execution, automation, and regression impact — as part of the team's estimate, so the sprint commitment reflects the true cost of delivering the story done-and-tested, not just coded.
A common failure is estimating only development effort, so 'small' dev stories with large testing implications blow up the sprint. In Scrum, the whole team estimates a story (often in relative story points via planning poker), and QA must voice the testing dimension: how many scenarios, how much is automatable now versus manual, what regression areas are impacted, whether new test data or environments are needed, and the risk/complexity of the feature. Testing effort isn't always proportional to dev effort — a one-line config change touching payments can carry enormous test risk, while a large but low-risk UI change may be quick to verify. QA's estimate should also flag when a story's testing can't fit the sprint, prompting a split. The goal is a realistic commitment where 'done' (including testing) is achievable, avoiding the pattern where dev finishes early and QA is buried at the end.
A story to 'change the tax rate config' looks like 1 point of development. In planning, QA points out it affects every checkout path, invoices, and reports, requiring broad regression — so the team sizes it realistically and allocates regression time instead of treating it as trivial and getting surprised.
Test-effort estimate — Story: "Add PayPal as a payment option"
Dev estimate (alone): 3 points
QA effort considerations:
New scenarios:
- PayPal happy path (auto)
- PayPal cancelled / declined (auto)
- PayPal timeout / gateway error (auto)
- Refund via PayPal (manual first)
Regression impact:
- Existing card checkout must still work (regression)
- Order/invoice/reporting side effects (DB validation)
Data/env:
- PayPal sandbox account + test credentials
Whole-team estimate (dev + test): 5 points
Note: if testing can't fit, split "refunds" into a follow-up story.Scenario: Your team estimates stories using only developer effort. Sprint after sprint, developers finish by day 7 but QA is overwhelmed on days 8–10 and testing spills over. In planning, how do you change estimation to fix this recurring imbalance?