Dentolize · Jira/Confluence QA Pipeline Walkthrough
On this pageLearning objectiveThe mental model to install firstLesson 1 — The mapLesson 2 — Run prepare (hands-on)Lesson 3 — Work Gate 1Lesson 4 — Run test, then work Gate 2Lesson 5 — retest vs fixCommon learner mistakesCheck for understandingSee also

For 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)

  1. Open a PR on a branch (so there's somewhere to post).
  2. GitHub → ActionsSandbox QARun workflow.
  3. Select your branch (not main). Leave action at its default, prepare.
  4. Run it. When it finishes, find the ### 🧪 Quality Review comment 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

  1. Dispatch test. Watch it move Stories to Done (PASS) or In Progress + failed.
  2. 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

  • retest re-runs open/commented tickets and never touches code. Safe to run freely.
  • fix edits the branch: commits with [skip ci], self-redeploys, retests, closes FIXED tickets with the commit ref. Requires contents: 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 test right after prepare without 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 fix as safe. It pushes commits. Only run it on confirmed bugs.

Check for understanding

  1. Where does the test plan live, and when is it "locked in"? (Jira epic; at the moment you dispatch test.)
  2. Which phase can change code? (Only fix.)
  3. How do you tell the agent a failure is expected? (Comment on the ticket before the next phase.)
  4. Why was full-auto removed? (To force a human gate between phases.)

See also