For product managers: from playbook to tickets

A playbook page maps one to one onto tickets. Each mandatory test becomes a ticket; its done condition becomes the acceptance criterion; its order becomes the dependency between tickets.

One ticket per mandatory test

  1. Open the playbook for your product type from the how-to-test index and go to section 4.
  2. Create one ticket per item. Title: the test type name and the product, for example "Payment and money-flow testing: checkout". Link the test type page for the definition.
  3. Paste the done condition verbatim as the acceptance criterion. Do not soften it into "tested" or "verified".
  4. Add the risk ids from the "Why" chips as labels. They link the ticket to the risk page and its evidence, which is what you show when someone asks why the ticket exists.
  5. Set the assignee role from "Who usually runs it" and record the tool class from the item.
  6. Make each ticket depend on the one before it in the order of work. The release smoke check, where it is mandatory, blocks everything after it.

The CSV download on each checklist page has one row per mandatory test with order, test type, risk ids, done condition, tool class and who runs it, which most trackers can import.

The release gate

A release is ready when every mandatory done condition is observed on the release build and the result is recorded with the build number. Section 9 of each page has acceptance criteria wording written for that product type; paste it into the release ticket.

Backlog and cadence

Recommended tests from section 5 go to the backlog with their condition as the trigger ("becomes mandatory when you store card data yourself"). When the condition becomes true, the ticket moves into the current plan as mandatory.

The "Ongoing cadence" column in section 7 lists events that re-run a test (each build, each store submission, each change to a provider). Create recurring tasks tied to those events, not to calendar dates.

When the page and the vendor disagree

If a vendor plan adds a test from section 6, ask for the risk it covers. If the plan drops a mandatory test, ask which evidence on the page they consider wrong; corrections go through the about page. How grades work is on the methodology page.

Not technical yourself, or briefing a founder: see for founders.