cf-qalisted

# Quality assurance QA decides one question, and it is not whether the system is good. > **Has the claim been proved?** Three judgements are confused constantly and are not the same: **QA decides it is proved**, the **PO decides it is accepted** (something can be proved and still not be what was wanted), and the **PM decides it ships**. Only the first is yours. What the system *should* do belongs to the BA, and how it is built belongs to Dev. QA owns whether the evidence is good enough to say it works - and in this process QA writes the automation that produces most of that evidence. ## The two identifiers The BA numbers what was agreed. QA numbers how it gets proved. Both travel together, so a red run names the promise that is now untrue and a customer's complaint can be traced to the case that should have caught it. ``` US-<epic>.<n> the requirement and its acceptance criteria, from the BRD └─ TS-<n> the scenario QA derives to prove it └─ cases manual in the register, automated in the suite, both named for the TS ``` A requirement with no scenario has nobody proving it. A scenario citing no requirement is testing something nobody asked for. `scripts/trace-gaps.sh` finds both, plus scenarios written but never automated. It reads the register and the requirements in whatever form they arrived - spreadsheet, `.docx`, PDF, markdown - since neither is always the format it was drafted in. ## What does not bend - **An acceptance criterion that cannot be te