QA Process
QA Retrospective Template.
A QA retro turns a cycle's pain into process fixes instead of repeated complaints. This template gives seven focused prompts and a completed example with concrete, owned actions — not vague "let's do better".
When to use it
Run it at the end of a sprint or release cycle, especially after a hard one — when the same testing problems keep recurring and you want them fixed rather than endured.
Who uses it
QA engineers reflecting on how the cycle actually went, and QA leads who facilitate the retro and make sure its actions are owned and followed through.
On this page7 sections
WHY RUN A QA RETRO
A QA retro exists to improve how the team tests, not to vent. Each cycle surfaces the same kinds of friction — unclear requirements, flaky environments, late information — and without a deliberate look back, those problems quietly recur every sprint because nobody owns fixing them.
The payoff is compounding. A retro that produces one or two real, owned changes per cycle makes next cycle measurably smoother, and the one after that smoother still. The cost is half an hour; the return is a process that gets better instead of staying stuck.
WHEN TO RUN IT
Run it at the end of each sprint or release cycle, while the details are fresh. A retro held two weeks late collects vague impressions; one held the day after collects specifics — the exact bug, the exact wait, the exact handoff that went wrong.
It's most valuable after a difficult cycle, but don't skip the smooth ones — those are where you find the practices worth protecting. A good cadence is every sprint for the team's own QA, plus a deeper look after a major release.
HOW TO RUN IT
Keep it short and structured. Walk the seven prompts in order, give everyone a few minutes to note thoughts before discussing so the loudest voice doesn't set the agenda, and focus on patterns rather than blaming individuals — the goal is a better process, not a culprit.
End on actions, and make them real. Every action gets an owner and a definition of done, so "improve test data" becomes "add a daily data-reset job — owner X, done when it runs in CI". Review last retro's actions at the start of the next one; an action nobody checks is an action nobody does.
THE TEMPLATE
# QA retrospective: <sprint / cycle>
## What went well
The testing practices worth keeping — what helped quality this cycle.
## What caused defects
Where the defects came from: unclear requirements, gaps in coverage, risky changes.
## What slowed testing
Anything that cost testing time — waits, rework, handoffs, unclear stories.
## Environment issues
Downtime, data, access, or config problems that affected testing.
## Automation issues
Flaky tests, gaps, slow runs, or maintenance burden in the suite.
## Communication gaps
Where information was missing, late, or lost between QA, dev, and product.
## Actions for next sprint
Concrete, owned actions — each with a name and a definition of done. Not "do better".
# QA retrospective: Sprint 23 (Storefront v2.4)
## What went well
Running the environment readiness check at the start of the cycle caught a failed deploy
before testing began — saved us a wasted morning. Risk-based test design meant payment
paths got deep coverage and the low-risk help-page change got a quick check, not equal time.
## What caused defects
Two of the four Medium defects traced to an acceptance criterion that didn't mention VAT on
the confirmation email — the requirement was incomplete, not the code. The PayPal spinner bug
came from a slow-network case nobody had specified.
## What slowed testing
The payments sandbox was down Mon–Tue, blocking payment testing for ~1.5 days. Staging was
also redeployed twice mid-run, costing about half a day of re-testing.
## Environment issues
Payments sandbox outage (2 days) and unstable staging (2 mid-cycle redeploys). Both were
flagged in the weekly status but had no health check to catch them early.
## Automation issues
The receipt-email verification is still manual and was the only gap in regression. No new
flakiness; suite stayed under the 2% flake budget and green on the release branch.
## Communication gaps
The failed deploy wasn't announced — QA found it via the readiness check, not from the deploy
channel. The VAT requirement gap should have surfaced in story refinement, not in test.
## Actions for next sprint
1. Automate the receipt-email verification — owner: A. Okafor, done when it runs in CI regression.
2. Add a health check + alert on the payments sandbox — owner: payments team, done when alerting fires on downtime.
3. Add "notify #qa on deploy" to the deploy pipeline — owner: D. Rossi, done when QA gets an automatic deploy message.
4. QA joins story refinement for payment stories — owner: L. Chen, done when it's on the refinement invite.
EXAMPLE COMPLETED RETRO
Read the completed Sprint 23 retro above for how specific each answer is. "What caused defects" doesn't say "unclear requirements" in the abstract — it names the missing VAT acceptance criterion and the unspecified slow-network case. "What slowed testing" quantifies the cost: ~1.5 days lost to the sandbox outage, half a day to staging redeploys. Specifics are what make a retro actionable.
The actions section is where it pays off. Each of the four actions has a named owner and a concrete definition of done — "automate the receipt-email verification, done when it runs in CI regression", not "improve automation". That's the difference between a retro that changes the next cycle and one that just produces a list of grievances everyone forgets by Monday.
COMMON MISTAKES
Ending with vague actions like "do better".
Every action needs an owner and a definition of done. "Improve test data" is a wish; "add a daily reset job, owner X, done when it runs in CI" is an action.
Letting it become a blame session.
Focus on the process, not the person. Ask what made the mistake easy to make, not who made it.
Never reviewing last retro's actions.
Start each retro by checking the previous actions. Unreviewed actions never get done, and the retro loses all credibility.
Only running a retro after a bad cycle.
Smooth cycles reveal the practices worth keeping. Run it every cycle so you protect what works, not just patch what broke.
Keeping the output in one person's notes.
Share the retro and its actions with the whole team. Improvements that live in a private doc don't change how anyone works.