Quality Management Checklist

1. Strategy & Governance

• Quality is defined as a measurable business outcome, not just a function or team.
• Quality goals are tied to specific customer or business metrics (e.g., retention, MTTR, defect escape rate).
• Leadership reviews quality KPIs at least monthly and acts on regressions.
• A clear quality policy exists and is reviewed at least annually.
• Risk-based prioritization is documented for which work gets which level of quality scrutiny.
• A single accountable owner for quality at the program level (not just the QA team).

2. Process & Documentation

• Written definition of "ready" and "done" for work items, shared across teams.
• Major processes (release, incident, change) have current SOPs that match how work actually happens.
• Process documentation is searchable, versioned, and updated when reality changes.
• Acceptance criteria are written before development starts, not after.
• Onboarding for a new engineer to ship-ready takes a documented, predictable amount of time.
• Decisions are recorded (ADRs, decision logs) so context survives turnover.

3. Quality Engineering

• Automated tests run on every commit; a red build blocks merge.
• Test pyramid is healthy: most tests are fast unit tests, fewer integration, fewer end-to-end.
• Test data is reproducible and does not depend on a fragile shared environment.
• Quality gates in CI/CD enforce coverage, security, and performance thresholds.
• Code review checks for quality concerns (testability, observability) — not just correctness.
• Feature flags allow shipping incomplete work safely behind a switch.
• Production has observability adequate to detect, diagnose, and recover from new failure modes.
• Rollback for any change is achievable within a documented timeframe.

4. Measurement & Metrics

• Defect escape rate (bugs found by users vs caught pre-release) is measured per release.
• Mean time to detect and mean time to recover (MTTD / MTTR) are tracked for production incidents.
• Quality metrics are reported alongside delivery metrics (not in isolation).
• A small number of leading indicators are watched (e.g., test flake rate, change failure rate).
• Metrics are reviewed for what they incentivize, not just what they measure.
• Targets are anchored to customer impact, not vanity numbers.

5. People & Culture

• Engineers feel safe raising quality concerns without career penalty.
• Postmortems are blameless and lead to system changes, not just individual training.
• Skill gaps in testing, observability, and review are surfaced and funded.
• New hires are paired with experienced engineers during their first months.
• Quality work is recognized in promotions and performance reviews, not just feature delivery.
• Cross-team collaboration on quality is structured (guilds, communities of practice, office hours).

6. Continuous Improvement

• A retrospective cadence exists and produces durable actions, not just feelings.
• Action items from retros are tracked to completion with an owner and a deadline.
• Improvement work has explicit budget within each sprint or planning cycle.
• Process changes are piloted on small surface area before rolling out broadly.
• External benchmarking (DORA metrics, industry standards) informs internal targets.
• A clear escalation path exists when a fix is repeatedly deferred for "later."

7. AI & Tooling

• AI tools used in development have a documented policy: when they help, when they need extra review.
• AI-generated code is reviewed with the same rigor as human-written code.
• Test generation tools are evaluated for false-confidence (passing tests that test nothing).
• Where AI is part of the product, model behavior has its own evaluation suite.
• Sensitive data flows to AI tools are governed and logged.
• Tool sprawl is periodically audited; redundant or unused tools are removed.
• Build, test, and CI tooling is reliable enough that engineers trust the signal.

How to use this checklist

Walk through it with your team once a quarter. For each item:

• ✓ Doing well — keep it, watch for drift.
• → Improving — assign an owner and a target review date.
• ✗ Not yet — decide if it matters; if it does, add it to next quarter's plan.