Quality & Testing · master area
Pre-Merge QA Verification
Branch-deployed feature, read against the amigos scenarios, plus an exploratory session, plus an accessibility check. QA's confirmation before the PR merges.
Owners: QA Phase it lives in: How We Build (Volume IV) The corpus principle this enacts: Three confirmations, three dimensions — this is QA's.
Where it lives in the chain
- How We Build · The Review — three confirmations, QA is one
- How We Build · Testing · QA craft — what QA verifies
How to do this
QA verification is structured, not freeform:
- Read the Feature Brief. Understand what change was promised.
- Walk the amigos scenarios. Each Gherkin scenario, manually executed. Including the negative cases.
- Walk the named states. From the wireframe — every state the design named, the implementation reaches.
- Exploratory session. 30–60 minutes, themed against the feature's risk profile. Where could this surprise someone?
- Accessibility check. Automated scan + keyboard pass + screen-reader spot-check.
- QA Report. Time-boxed, written, attached to the PR.
What good QA verification looks like
A QA who reads the brief before the diff finds observation-mismatch — "The brief said Gal grades 30 exams in a session; the empty state shows when she has 0 exams. What happens after the first exam? After the last? Did anyone test the in-between?" That question is the QA's chain-aware contribution.
A QA who reads only the diff finds typos and missing states. That is also valuable, but it is what the developer should have caught. The QA's job is the trace question, at the experience level: did the brief's change reach the user, intact?
The PR doesn't merge until QA's confirmation is recorded, alongside the developer's review and the designer's UX review. Three confirmations, three angles. A merge with two-out-of-three is a merge that approved on incomplete evidence.
Related crafts
- Exploratory Testing — the open-ended half
- QA Report — the artefact this produces
- Gherkin & Amigos — the scenarios this verifies