A dashboard reports 2,418 tests passed and 12 failed. The release meeting asks whether it can ship. The dashboard answers a different question, because it counts cases rather than naming which requirements are verified and which remain open.
Test management closes that gap. It organises cases, records runs, links both to requirements, and produces a statement a release decision can rest on.
This guide covers the four artefacts, how traceability survives, when to retire a case, and the metrics that separate a working system from a busy one.
Test management is the ongoing organisation of testing work and its evidence. The ISTQB Foundation Level syllabus treats it as a continuous activity spanning planning, monitoring, and control. ISO/IEC/IEEE 29119-3 specifies the documentation.
It sits above execution and below strategy.
| Layer | Scope | Changes |
|---|---|---|
| Strategy | Where coverage goes across the product | Quarterly |
| Test plan | One release cycle | Every cycle |
| Test management | Artefacts coherent across many cycles | Continuously |
| Execution | A single run | Per trigger |
That third row is why a question asked in March about a release shipped in January has an answer.
Every case, organised so a human finds one. Organise by feature area, since feature area survives reorganisations while author and sprint do not.
Each case carries preconditions, steps, expected result, and the requirement it traces to. Cases missing that final field accumulate until removing them becomes unjustifiable, which is why they stay forever.
What ran, against which build, on which environment and device, with what outcome. A pass carrying no build identifier proves little a week later.
Evidence belongs here. Screenshots, video, and logs turn a disputed result into a settled one.
The map from requirement to case to result. It converts a count of passing tests into a list of verified requirements, which is the form a release decision needs.
It gets skipped because maintaining it costs effort every sprint while returning value only at decision points.
Each defect linked to the case that found it, the build that fixed it, and the run that confirmed the fix. Our issues records carry that chain, so a closed defect reopens against evidence rather than memory.
Traceability decays because it gets maintained by hand after the fact. Three habits keep it alive.
Link at creation. A case written against a requirement records the link in the same minute. A case linked retroactively during an audit records a guess.
Let the requirement own the list. When a requirement changes, its cases should surface automatically for review. Where that step is manual, changed requirements silently orphan their cases.
Review orphans on a schedule. A case tracing to zero requirements and a requirement tracing to zero cases are both findings. The second is a coverage gap. The first is either dead weight or an undocumented requirement, and separating them takes a conversation.
A practical check: pick a requirement at random, ask which cases cover it and when they last ran. Longer than a minute means the link exists on paper only.
Case libraries grow and rarely shrink, producing a suite where maintenance cost rises while coverage stays flat, and the question of which cases earn their place goes unanswered.
Four retirement triggers are worth writing down.
The requirement went away. A feature removed from the product leaves its cases behind unless something prompts the deletion.
The case has passed on every run for a year and covers a path no defect has ever touched. This one deserves judgment rather than automation, since a case guarding a rare catastrophic path earns its keep by passing.
Another case covers the same assertion. Duplicates arrive when two people write against the same requirement independently, and the duplicate usually carries weaker evidence.
The case is quarantined and has stayed quarantined. A flaky case parked for a sprint gets fixed. One parked for six months is maintenance cost with zero signal.
Track two numbers per quarter: cases added and cases retired. Where the second stays at zero, the library is growing by accumulation rather than by decision.
Dashboards report volume by default. Volume answers questions the release meeting failed to ask.
| Metric | What it tells a release decision |
|---|---|
| Requirements verified against total | Whether scope is actually covered |
| Defect density by module | Where risk concentrates |
| Defect leakage to production | Whether prevention is working |
| Case pass rate per device tier | Whether coverage holds across the matrix |
| Flaky case count | How much of the signal is noise |
| Cases retired against cases added | Whether the library is curated |
| Mean time from defect raised to retest | Whether the loop is fast enough |
Flaky case count deserves weight. A suite where 8 percent of cases fail intermittently produces red runs engineers learn to re-run, and once that habit forms the gate has stopped working whatever the headline rate says.
Report trends rather than snapshots. Defect density this release against last release carries information. Defect density alone carries almost zero. Martin Fowler's test pyramid is a useful lens, since a suite shaped wrongly produces metrics that look healthy while feedback stays slow.
Mobile multiplies every record. One case across eight configurations is eight run records, and treating them as one pass hides the configuration that failed.
Three adjustments handle it.
Record per configuration rather than per case. A case passing on seven devices and failing on one is a failure, and the record should name the device.
Tier the matrix and report by tier. Tier one covers your highest-traffic configurations and gets the full suite. Lower tiers get smoke and critical paths. Reporting that mixes tiers produces a pass rate meaning nothing.
Version the matrix alongside the library. A result from three months ago was measured against a different device list, so real device testing records compare only when you know what the matrix held at the time.
Mobile app testing tools differ in whether they record per-configuration results natively or flatten them, and that single property affects test management more than any feature on a comparison page.
The question is less which product and more which properties.
Our comparison of test case management tools covers the current field against these properties.
Where UAT sign-off forms part of your process, the record needs a named approver and a timestamp beside the criteria version. Where regression suites and smoke tests run on different cadences, the record should make clear which gate produced a given result.
We assemble the run record automatically.
Our suites organise flows by feature area and cadence, so the case library and the execution schedule are one structure rather than two kept in sync by hand.
Every run records video and step-level results per device. A case passing on four devices and failing on the fifth reports that way, with the failing device named and its replay attached.
Failures link to issues, carrying the defect trail from discovery through fix to retest without manual transcription.
Our team settings assign ownership and notifications route results to whoever holds the decision, so reporting reaches people rather than waiting in a dashboard. Teams building this discipline more broadly find our quality engineering guide covers the surrounding practice.
Pick one requirement from your current release at random. Ask which cases cover it and when they last ran, then time the answer.
Under a minute means your test management is real. Longer means you hold a case library and a run history that are loosely connected, and the release meeting is relying on a count.
Then check cases retired last quarter against cases added. Where retirement sits at zero, your maintenance cost is rising on a library has gone uncurated.
.png)
Test management is the ongoing organisation of test cases, execution records, traceability to requirements, and the defect trail, so a release decision rests on what has been verified.
The case library, the run record tied to build and environment, the traceability link from requirement to case to result, and the defect trail from discovery through fix to confirmed retest.
A test plan covers one cycle: scope, devices, schedule, criteria. Test management keeps the artefacts coherent across many cycles, so questions about an earlier release still have answers.
It gets maintained by hand after the fact. Linking a case to its requirement at creation keeps it accurate, while retrofitting the link during an audit records a guess.
When its requirement went away, when another case covers the same assertion, when it has stayed quarantined beyond a sprint, or when it has passed for a year on a path no defect has touched.
Requirements verified against total, defect density by module, defect leakage, pass rate per device tier, flaky case count, cases retired against cases added, and time from defect raised to retest.
One case across eight configurations is eight records. Record per configuration rather than flattening, tier the matrix, report by tier, and version the matrix so older results stay comparable.
Which cases cover a given requirement, when they last ran, against which build and device, with what evidence, and which defects came from them. A slow query means the records are loosely connected.
