Test Management Guides
Planning, strategy, risk, estimation, process and the numbers that justify all of it. Seven guides for the person who has to decide what gets tested, by whom, for how long, and then defend the decision.
Test management is the part of the job that happens before and around the testing: deciding scope, choosing depth by risk, estimating effort, writing the plan that a customer or auditor will read, running the process, and reporting results in a form a sponsor can act on. It is also the part most often done badly, not because the ideas are hard but because the templates people inherit are either too long (a forty-page plan nobody reads) or too vague (a strategy slide that says 'we will test thoroughly'). The guides here are built around the artefacts a test lead actually produces, with a template table or a worked model in each.
Start with the test plan guide if you have a plan to write this month; it has a section-by-section template and a one-page versus ten-page decision. Read test strategy before that if the organisation has never written down its approach, because a plan without a strategy behind it re-decides everything from scratch. Risk-based testing is how the depth of testing gets decided per feature; test estimation compares five techniques with worked numbers so that the estimate survives a planning meeting.
All 7 guides in this hub
| # | Guide | What it settles | Level | Reading |
|---|---|---|---|---|
| 1 | How to write a test plan that survives review | A test plan is the document a reviewer reads to decide whether the testing you propose is enough. | Practitioner | 8 min |
| 2 | Test strategy: the one-page version that actually gets used | A test strategy states how an organization or product line tests, independent of any single release. | Lead | 6 min |
| 3 | Risk based testing: scoring, effort allocation, worked example | Risk based testing puts the most testing where a failure would hurt most and is most likely. | Practitioner | 6 min |
| 4 | Test estimation: five techniques with worked numbers | Every test estimate is wrong; the useful ones are wrong by a known amount. | Practitioner | 7 min |
| 5 | TMMi: the five maturity levels and what an assessment involves | TMMi, the Test Maturity Model integration, is the staged model for improving a test process. | Lead | 7 min |
| 6 | ROI of testing: cost of defects by stage and a worked model | Testing costs money that a sponsor can see against a return they cannot. | Lead | 7 min |
| 7 | Software test process: six activities, inputs and deliverables | The fundamental test process is the activity model behind every syllabus and standard: plan, analyze, design, implement, execute, complete, with monitoring and control running alongside. | Foundation | 7 min |
Where to start, by the question you have
Two guides address the conversation with management. The ROI of testing builds the cost-of-defects model (relative cost by the stage a defect is found) into a one-slide argument, and is honest about the limits of that argument. TMMi explains the five-level maturity model that European and regulated-industry organisations use to assess and improve their test process, and what moving to level 3 changes on a Tuesday. The software test process lays out the six activities, their deliverables and their exit criteria, and shows how the same process compresses into a two-week sprint.
Three situations decide where to start. If a plan is due this week, open the section-by-section test plan template, take the depth-per-feature table from the risk scoring method for the scope section, and take the schedule from a three-point or test point estimate rather than from the sprint calendar. If the build is red and nobody trusts it, the management half of the fix is in the exit criteria in the test process guide, because a suite whose failures carry no consequence will be ignored; the engineering half is the rerun-statistics rule and quarantine policy in the automation hub. If an audit is coming, read the TMMi level descriptions to learn what the assessor will ask for at level 2 and level 3, then the test strategy guide, because the first document an auditor requests is the one that states the approach.
The hub connects to the authenticity lane at two points. Risk-based testing scores likelihood and impact, and when the system under test is an AI text detector the impact lands on a person: the base-rate arithmetic shows that at 1 machine-written document in 100, a detector with a 94 percent detection rate and a 2 percent false positive rate is wrong about two thirds of the documents it flags, which is the number that belongs in the impact column before anyone decides how deep to test. The cost-of-defects model in the ROI guide has the same shape as the cost of a wrong flag: cheap to catch in the benchmark, expensive once a student or a journalist has been accused. And a test plan for an authenticity system needs its pass criterion written before the run, which is the first requirement of an evidence-grade test record. Two newer guides continue the thread for managers: keeping a chain of custody for the evidence a test produces, so a disputed result can be defended, and reproducibility, or a result with enough provenance that another team can rerun it.
Test management was the subject the original magazine returned to most, and the two standalone PDFs the old site hosted on the topic (a TMMi paper and a workshop announcement, and a return-on-investment paper) redirect to the guides that continue them. The magazine's archive is at the magazine hub; the guides here are written for current practice and cite standards (ISO/IEC/IEEE 29119, the TMMi model, the ISTQB syllabi) and books by name so that you can check them.