QAOps

WHAT IT IS QAOps is the operating discipline of the quality function: deciding what is worth testing and at which layer, defining what a defect is and how it is triaged, analysing what escaped to production and why, and setting the gates a change passes before release. **Not this:** QAOps is not TestOps: it owns the strategy and the judgment about quality — what to test, what a defect means, what gates apply — not the infrastructure that executes tests. WHY IT EXISTS Test coverage is a measure of execution, not of judgment; a suite can be large, fast and green while systematically failing to exercise the thing that breaks. Somebody has to decide where quality effort goes, and in the absence of that decision effort follows whatever is easy to automate. The other reason is feedback: escaped defects are the highest-quality information an organisation gets about its own testing, and most organisations discard it. WHEN TO USE IT Adopt it when defects reach production in a category nobody was looking at, when triage depends on who picks the ticket up, or when "is this ready?" is answered by feel. The need grows with the number of teams, because consistency of judgment is what erodes first. WHO OWNS IT A quality function or quality-focused engineers own the strategy, the defect taxonomy and the escaped-defect analysis. Delivery teams own the quality of their own work — quality assured by a separate group at the end is the anti-pattern this discipline replaced. The product owner owns the acceptance criteria and the risk appetite that gates encode. WHAT GOOD LOOKS LIKE There is a written view of what is tested at each layer and why, and it is revisited rather than inherited. Defects have a severity definition that two people apply consistently. Every escaped defect is examined for the gap that let it through, and that analysis changes something. Release gates are explicit and proportionate to risk, and exceptions are recorded rather than negotiated silently. Quality signals from production — errors, support contacts, user reports — feed back into where testing effort goes. HOW TO IMPLEMENT Start with escaped-defect analysis on the last quarter, because it tells you where the real gaps are rather than where you imagine them. Write the defect severity definition and test it by having two people triage the same ten issues. Map what is tested at which layer and find the categories nobody covers. Define the gates, keep them proportionate, and make exceptions visible. Work with /testops on making the resulting suite fast and reliable enough to run, and connect production signals through /observability-engineering. HOW TO ASSESS YOURSELF Take the last five production defects and ask, for each, which layer should have caught it. Ask whether two people triage the same bug the same way. Ask who decides a release is ready and on what basis. Take the scored self-assessment at /assess, then plan with /roadmaps.