role · qa

QA

QA is the corpus's adversarial reader. They sit at amigos, write the scenario the team would not have written, and answer the question nobody else has the standing to ask: "is this the thing we said we were building?"

What good looks like

A competent QA produces three artefacts every cycle:

1. A Gherkin set per story — at least three scenarios, at least one negative case, written with the developer and PO, not after.
2. An exploratory report for the cycle's first release — a one-pager of what was tried that wasn't in Gherkin, and what was learned about the moment.
3. A QA-led pre-release note — a single paragraph that says this is safe to ship, this is safe to ship under flag, or this is not safe. Signed.

A QA who produces these three has the quality chain working. A QA who only verifies after merge is reviewing code, not protecting the moment.

The QA's stance

QA is responsible for	QA is not responsible for
The scenario the team would not have written	The full test pyramid by themselves
Refusing to sign a brief that has no negative case	Catching every bug
The pre-release safe-to-ship paragraph	The deploy decision
The accessibility of the change	The accessibility of code QA did not see
The exploratory pass on the moment	The exhaustive regression of everything else

QA holds the chain by holding the question the team is too close to ask.

Three artefacts to read first

1. Amigos & Gherkin
2. Testing Layers
3. Release Gate

First 30 days

Day 1–3 — Read the canon

Read What We Shape Part 5 (Amigos & Gherkin). Read As We Build Parts 5, 6 (Testing, Release Gate). Read After We Build Parts 3, 4 (Bugs and Their Roots, Incidents).

Output: in three sentences, explain the difference between a test that is green for the right reason and a test that is green for the wrong reason.

Day 4–7 — Sit at amigos

Attend at least two amigos sessions, silent first time, contributing the second. Bring at least one anti-flow ("what if the person does X instead?").

Output: notes for both sessions, plus one negative-case scenario you raised that survived into Gherkin.

Day 8–14 — Write your first Gherkin set

Take the next story. Hold amigos with PO and Developer. Write three scenarios, including at least one negative case and at least one accessibility consideration.

Output: signed Gherkin set linked from the story.

Day 15–21 — Run the first exploratory pass

When the feature lands behind flag in staging, run the exploratory pass. Try the things Gherkin didn't say.

Output: one-page exploratory report — what was tried, what was found, what the team should know.

Day 22–25 — Sign or refuse the release

Hold the pre-release conversation with the trio. Write the paragraph: this is safe / safe under flag / not safe. Sign it.

Output: the paragraph, signed, linked from the release brief.

Day 26–30 — Read the signal next to the prediction

When the first cycle's signal reading lands, read it. Compare it against the Gherkin set. Did the negative case ever fire? Did the accessibility consideration hold?

Output: notes on the gap between Gherkin and reality — at least one input to the next amigos.

Deepening — self-rate yourself

Amigos craft

• I can hold a 45-minute amigos that produces three scenarios including a negative case.
• I bring at least one anti-flow to every amigos.
• I have refused to sign a brief whose negative case I couldn't write.

Gherkin discipline

• My scenarios read like sentences a person could say.
• I have killed scenarios that were testing the test, not the thing.
• I can defend cutting a scenario that doesn't change the moment.

Exploratory

• Every release gets an exploratory pass.
• The pass produces at least one thing Gherkin didn't anticipate, every cycle.
• I can run an exploratory pass on a moment I have not lived.

Release discipline

• I can write the safe to ship paragraph in three sentences.
• I have refused a release without it being a personal moment.
• My refusal traces to a specific risk, not a feeling.

Accessibility

• Every Gherkin set has at least one accessibility scenario.
• I run keyboard-only and screen-reader passes routinely.
• I have rejected a flow that would have shipped without me.

Stuck if…

…the same bug class keeps escaping

The Gherkin is testing the implementation, not the moment. Re-read Amigos & Gherkin. Scenarios should be reads of the journey, not the code.

…you signed off and the first 48h surfaced a basic break

The exploratory pass didn't run, or it ran on the wrong surface. The release went out without the safe to ship paragraph being honest. Open First 48 Hours and find the level.

…amigos has become a rubber stamp

The trio has stopped resisting briefs. Resistance is not delay — it is the corpus's discipline. Re-read Amigos.

…leadership treats QA as a gate after the fact

The pre-release paragraph isn't being read. Either it isn't being written, or it isn't being routed to the people making the deploy call. Make it visible.

…the regression suite is the only thing the team trusts

The pyramid has inverted. Unit and integration tests have decayed. The fix isn't more regression — it's restoring the lower levels.

…a bug surfaced that has no scenario covering it

Don't add the scenario. First, ask which level produced the gap. Was the moment witnessed? Did amigos surface this anti-flow? Then write the scenario, then write the level fix.

See also

• Skill path — QA foundations
• Canon — What We Shape · As We Build · After We Build
• Practice — Holding amigos · Story writing · Release gate · First 48 hours watch
• Templates — Gherkin scenario set · Story
• Checklists — Amigos agenda · Story DoR · Trio sign-off · Release gate · First 48 hours
• Areas — 7 · Quality & Testing
• Clinics — A brief that didn't witness · A brief written from the solution backwards · A story without a state