On this page
Learning objectiveThe mental model to install firstLesson 1 — The mapLesson 2 — Runprepare (hands-on)Lesson 3 — Work Gate 1Lesson 4 — Run test, then work Gate 2Lesson 5 — retest vs fixCommon learner mistakesCheck for understandingSee alsoFor Training
A step-by-step guide to teaching the QA pipeline to an engineer or QA reviewer. Audience: the internal team.
Learning objective
By the end, a learner can take a branch from "just opened a PR" to "QA'd, with confirmed bugs fixed," using the four phases and both human gates correctly.
The mental model to install first
The AI is a fast junior tester. You are the QA lead. It drafts and runs; you curate and approve. The pipeline is built so you must approve — there is no autopilot.
Everything else follows from that one sentence.
Lesson 1 — The map
Draw this on the whiteboard:
prepare ──[GATE: edit epic in Jira]──▶ test ──[GATE: comment on tickets]──▶ retest / fix
- prepare = draft the review + test cases → Jira epic + Confluence page.
- GATE 1 = you edit the epic. Delete nits, sharpen vague Stories, add missed ones.
- test = run the epic's current Stories on the sandbox; results per ticket.
- GATE 2 = you comment on tickets ("expected," "retry," "real bug").
- retest = re-run open + newly-commented tickets. Never commits.
- fix = repair confirmed FAIL tickets on the branch, redeploy, retest, close.
Lesson 2 — Run prepare (hands-on)
- Open a PR on a branch (so there's somewhere to post).
- GitHub → Actions → Sandbox QA → Run workflow.
- Select your branch (not
main). Leaveactionat its default,prepare. - Run it. When it finishes, find the
### 🧪 Quality Reviewcomment on your PR and click the Jira epic link.
Teaching point: the comment's call-to-action after prepare literally tells you to go edit the epic (.github/workflows/sandbox-qa.yml:98-100).
Lesson 3 — Work Gate 1
Open the epic. Walk through the Stories together and practice the three moves:
- Delete a nit-pick Story.
- Refine one — tighten its repro steps and expected result.
- Add one the agent missed.
Drive home: what the epic says when you press test is what gets tested. There is no separate "save the plan" step — the epic is the plan.
Lesson 4 — Run test, then work Gate 2
- Dispatch
test. Watch it move Stories to Done (PASS) or In Progress +failed. - Open a failed ticket. Practice commenting:
- Mark one FAIL "expected — closing."
- Ask for a retry on one ("sandbox was redeploying").
- Confirm one as a "real bug — fix it."
Teaching point: your comments become instructions the agent reads on the next phase (header :17-18).
Lesson 5 — retest vs fix
retestre-runs open/commented tickets and never touches code. Safe to run freely.fixedits the branch: commits with[skip ci], self-redeploys, retests, closes FIXED tickets with the commit ref. Requirescontents: write(:48-49).
Exercise: given three failing tickets — one "expected," one "flaky," one "real bug" — which phase for each? (Close the first at the gate; retest the second; fix the third.)
Common learner mistakes
- Skipping Gate 1. Running
testright afterpreparewithout curating the epic. The whole design exists to prevent this — slow down. - Expecting GitHub issues. They're retired; look in Jira.
- Dispatching on
main. Dispatch on the feature branch. - Running QA with no open PR. The work runs but nothing gets posted (
:86). - Treating
fixas safe. It pushes commits. Only run it on confirmed bugs.
Check for understanding
- Where does the test plan live, and when is it "locked in"? (Jira epic; at the moment you dispatch
test.) - Which phase can change code? (Only
fix.) - How do you tell the agent a failure is expected? (Comment on the ticket before the next phase.)
- Why was
full-autoremoved? (To force a human gate between phases.)
See also
- The Human QA Gates — the concept this whole lesson orbits.
- For Support — the FAQ your learners will hit next.