QA Process
QA Weekly Status Report Template.
A weekly QA status report keeps everyone aligned on testing progress, risks, and blockers. This is a simple copy-paste template, a fuller QA-lead version with a RAG rollup, and a completed example.
When to use it
Send one every week during any release cycle or ongoing project — anywhere stakeholders need a reliable read on testing progress and risk without chasing you for it.
Who uses it
QA engineers reporting up, QA leads rolling several workstreams into one view, and the product owners, managers, and stakeholders who read it to gauge release risk.
On this page8 sections
WHY WEEKLY QA REPORTS MATTER
A weekly QA report buys you three things: visibility (everyone sees the same progress), early warning (risks and blockers surface while there's still time to act), and a record (a paper trail of how quality tracked across the cycle).
It also protects your focus. A predictable report on a known day stops the steady stream of "how's testing going?" pings and replaces them with one answer everyone trusts.
WHAT TO INCLUDE
| Field | What to include |
|---|---|
| Reporting period | The week or sprint this report covers. |
| Overall status — On track | Everything is progressing to plan; no blockers, risks under control. |
| Overall status — At risk | Something could derail the plan; a risk or slip needs attention. |
| Overall status — Blocked | Work cannot progress without help or a decision. |
| Testing completed this week | What was tested and finished. |
| Testing planned next week | What's queued next. |
| Defects raised | New defects logged, by severity. |
| Defects closed | Defects fixed and verified. |
| Blockers | Anything stopping progress — with an owner and an ask. |
| Risks | What could go wrong, and the mitigation. |
| Environment issues | Downtime, data, or access problems affecting testing. |
| Automation progress | New or updated automated coverage and CI health. |
| Regression status | State of the regression suite (pass rate, gaps). |
| Support needed | Decisions or help you need from the reader. |
WHO SHOULD RECEIVE IT
At minimum: the delivery team, the QA lead or manager, and the product owner. On a release with wider stakes, add the stakeholders who'll make the go-live call.
Match depth to audience. Executives want the one-line RAG status and the headline risk; the team wants the full breakdown. The same report can serve both if the status leads and the detail follows.
SIMPLE WEEKLY STATUS TEMPLATE
# QA weekly status: <week / sprint>
## Reporting period
The week or sprint this report covers.
## Overall status
On track / At risk / Blocked — in one line.
## Testing completed this week
What was tested and finished.
## Testing planned next week
What's queued next.
## Defects raised
New defects logged, by severity.
## Defects closed
Defects fixed and verified.
## Blockers
Anything stopping progress — with an owner and an ask.
## Risks
What could go wrong, and the mitigation.
## Environment issues
Downtime, data, or access problems affecting testing.
## Automation progress
New or updated automated coverage and CI health.
## Regression status
State of the regression suite (pass rate, gaps).
## Support needed
Decisions or help you need from the reader.
# QA weekly status: Week of 9 Jun (Sprint 23)
## Reporting period
9–13 Jun 2026
## Overall status
At risk — guest-checkout testing slipped two days waiting on the payments sandbox.
## Testing completed this week
Guest-checkout functional pass on Chrome and Safari; address-validation cases done.
## Testing planned next week
Apple Pay / PayPal paths, confirmation email, and full regression.
## Defects raised
5 new (1 High, 2 Medium, 2 Low).
## Defects closed
3 closed and verified.
## Blockers
Payments sandbox was down Mon–Tue (owner: Payments team — confirm it stays up).
## Risks
3DS flakiness in the sandbox may slow payment testing — building in a retry buffer.
## Environment issues
Staging redeployed twice mid-run; cost about half a day of re-testing.
## Automation progress
Added 6 checkout API checks to CI; suite green.
## Regression status
Not started — scheduled next week once the new paths are stable.
## Support needed
Confirmation that the payments sandbox stays up through Thursday.
DETAILED QA LEAD VERSION
# QA weekly status (lead): <week / sprint>
## Reporting period
The week or sprint covered, and the release it feeds.
## Overall status
A RAG rollup across areas, then a one-line summary.
| Area | Status | Note |
| --- | --- | --- |
| Functional | <RAG> | <one line> |
| Regression | <RAG> | <one line> |
| Automation | <RAG> | <one line> |
| Environments | <RAG> | <one line> |
## Testing completed this week
Per workstream: what finished, with coverage where it's useful.
## Testing planned next week
Per workstream: what's next, and any sequencing or dependencies.
## Defects raised
New defects by severity, with the trend versus last week.
## Defects closed
Closed and verified, plus the current open count by severity.
## Blockers
Each blocker with owner, age, and the specific ask.
## Risks
Scored risks (impact × likelihood) with owner and mitigation.
## Environment issues
Stability, data, and access issues, with their impact on the schedule.
## Automation progress
Coverage added, flake rate, CI health, and any quarantined tests.
## Regression status
Suite pass rate, what's excluded, and confidence for release.
## Support needed
Decisions, people, or environments you need — and by when.
# QA weekly status (lead): Week of 9 Jun (Sprint 23) — v2.4 release
## Reporting period
9–13 Jun 2026 · feeds the Storefront v2.4 release (go-live 19 Jun)
## Overall status
At risk — payments-sandbox downtime cost ~2 days; recoverable with next week's buffer.
| Area | Status | Note |
| --- | --- | --- |
| Functional | Green | Guest checkout passing on Chrome + Safari |
| Regression | Amber | Not yet started; scheduled next week |
| Automation | Green | 6 new checkout checks in CI, suite green |
| Environments | Red | Staging unstable; sandbox down Mon–Tue |
## Testing completed this week
Guest-checkout functional (Chrome, Safari) and address validation complete;
6 new API checks automated.
## Testing planned next week
Apple Pay + PayPal, confirmation email, and the full regression suite (86 cases).
## Defects raised
5 new (1 High, 2 Medium, 2 Low) — up from 3 last week, all in new guest paths.
## Defects closed
3 closed and verified. Open: 0 Critical, 1 High, 2 Medium, 2 Low.
## Blockers
Payments sandbox down Mon–Tue (owner: Payments, age 3 days) — need it stable through Thu.
## Risks
3DS sandbox flakiness (impact High × likelihood Medium) — mitigation: retry x2, log gateway IDs.
## Environment issues
Staging redeployed twice mid-run (~0.5 day lost); sandbox outage (~1.5 days lost).
## Automation progress
+6 checkout API checks; flake rate <2%; no quarantined tests; CI green.
## Regression status
Not started; planned next week. Confidence for 19 Jun is moderate pending regression.
## Support needed
Keep the payments sandbox up through Thursday; confirm the 19 Jun date holds given the slip.
EXAMPLE COMPLETED REPORT
Read the completed Sprint 23 report above as a story, not a form. The overall status is "At risk" — and crucially it says why in the same line: the payments sandbox went down for two days. A reader knows the headline before reading another word.
The rest earns its place by being specific and honest. Defects raised went up (3 → 5) and the report says so; the blocker names an owner and an age; the one ask — keep the sandbox up through Thursday — is impossible to miss. That's the difference between a report that informs and one that just logs activity.
COMMON MISTAKES
A wall of text with no clear status.
Lead with the RAG status and the one thing the reader must know. Detail comes after, for those who want it.
Only reporting good news.
Surface blockers and risks early and honestly — a report that hides problems is worse than none, because it removes the chance to help.
Numbers with no meaning.
Don't just say "5 defects raised". Say what it implies for the release — still on track, or a new risk.
The same detail for every audience.
Tailor depth to the reader: a one-line RAG for execs, the full breakdown for the team.
Writing it for yourself.
The report exists to drive the reader's decisions. End with exactly what you need from them.