Skip to content

QA Report

What was tested, what was explored, what was not, what surprised. The artefact that survives the developer leaving — and the document the postmortem opens when an incident traces back to a missed scenario.

Owners: QA Phase it lives in: How We Build → After We Build The corpus principle this enacts: Every artifact in the chain is a hedge against the departure of the person who created it.

Where it lives in the chain

How to do this

The QA report has five sections, each short:

  1. What was tested — the scenarios run, the states walked. "All 7 Gherkin scenarios from amigos; the 5 named states from the wireframe."
  2. What was explored — the charter, the time-box, the paths taken. "60-min charter on language switching mid-session. Walked Hebrew→English in three states; tried mid-flow at 4 points."
  3. What was not tested — the explicit gaps. "Concurrent submissions from two tabs was out of scope this PR; flagged for the next."
  4. What surprised — non-bugs that felt off. "Success animation persists 3s; interrupts flow when grading 30 exams in a session."
  5. Findings — bugs filed, with reference numbers.

What good practice looks like

The QA report lives next to the PR — linked, not pasted. Two weeks after release, when a CS ticket arrives about "the grading thing", the PO opens the QA report and reads: "What did we test? What did we explore? What did we explicitly not test?" The answer either explains the bug or names the gap.

A QA report that says "tested, looks good" is a QA report nobody can read in postmortem. It produces no learning. The report's value is its specificity"I walked X, I did not walk Y, I observed Z that wasn't a bug."

The discipline: QA reports accumulate over months into a map of where the team's testing is sharp and where it is blind. A pattern of "we did not test concurrent edits" across five reports is a structural gap — the next chain change is a concurrent-edit testing addition to the amigos template.

200apps · How We Work · NWIRE