Test management

Test management is the unglamorous middle of the QA stack — not the writing of tests, not the running of them, but the discipline of keeping the system useful as it grows past 1,000 test cases, past 10,000, past 100,000. The team that ignores it ends up with a test suite that takes hours to run, a backlog of failures nobody owns, and a regression strategy that's "run everything and pray".

This hub is the answer to that middle. Five articles, each addressing one decision the team has to make explicitly:

1. Test-case design — writing cases that don't go stale after the third refactor
2. Traceability matrix — without spreadsheet hell
3. Regression strategy — at 10k+ tests, run-everything doesn't scale
4. Exploratory testing — alongside automation, not instead of it
5. Defect triage — the process that prevents drowning when defect volume grows

Why this matters now

Test management is in flux for three reasons:

• AI test generation has changed the volume game. A team using AI-assisted test generation can ship 5-10x more test cases per sprint than they could write manually. Most test management systems were designed for the human-authored-test era — they handle 5,000 tests fine and start to creak at 50,000. The middle is uncomfortable.
• Shift-left has put tests in the developer's hands. The old model — a separate QA team owns the test suite, files defects back to engineering — is increasingly rare in modern product engineering. Tests live in the same repo as the code; defects are tracked in the same system as stories; the QA function is increasingly about strategy and tooling rather than test authoring.
• The traceability-and-compliance bar is rising. Regulated industries (FDA, FedRAMP, SOC 2) have always needed traceability. The 2024+ trend is that non-regulated industries are adopting similar discipline as enterprise procurement starts asking for it. A test management story that says "we have tests but can't tell you which AC they verify" loses deals.

The teams getting this right have systematic answers to all five questions in this hub. The teams not getting it right have a TestRail license and hope.

What this hub assumes

You're in a 10-50 person engineering organisation with at least a thousand active test cases — manual, automated, or some mix. You have an existing tool of record (TestRail, Zephyr, qTest, Xray, or an in-house system) or you're evaluating whether to adopt one. You're shipping at least weekly, and the test suite is starting to feel like more of a constraint than a safety net.

If you're earlier than that (a few dozen tests, single product, single team), the discipline this hub describes is overkill — start with the test pyramid glossary entry and the code-review hub instead.

The five practices in one paragraph

A mature test-management practice writes tests anchored to behaviour rather than UI steps so they survive refactors, maintains traceability via the underlying entity graph rather than spreadsheets, runs regression by risk and impact rather than by exhaustive execution, complements automation with explicit exploratory sessions that find what scripts can't, and triages defects by severity-frequency-impact with explicit non-fix criteria so the backlog doesn't drown the team. Each of the five articles unpacks one of these dimensions in detail.

How to use this hub

If you're optimising an existing test-management practice, start with defect triage — most teams find their biggest pain there. If you're building from scratch, read in order — test-case design sets the foundation, traceability + regression operationalise it, exploratory closes the AI gap, and triage handles the steady state.

Each article includes practical templates (case structure, matrix layouts, triage workflows) you can adapt directly. The Stride research linked from each article digs deeper into the underlying patterns.