Test Management
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.
7 guidesUpdated Editorial method
About test management
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.
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. 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.
All guides
Nothing matches. Clear the filter to see every entry.
Questions
What is the difference between a test strategy and a test plan?
A strategy is the standing statement of how testing is done for a product or organisation: scope, product risk approach, test levels and types, entry and exit criteria, environments and automation stance. It changes yearly, not per release. A test plan applies that strategy to a specific release.
How long should a test plan be?
It depends on who reads it. A one-page plan covers one team for one sprint; a ten-page plan covers a release with external stakeholders. The test plan guide works through ten sections and suggests budgeting 8 to 16 hours for a first full draft.
How do I decide how much testing a feature needs?
Score it for likelihood and impact, each from 1 to 5, and multiply them into a product risk score of 1 to 25. Features scoring 15 to 25 are high risk and get about 55 percent of the effort and formal techniques; low-risk features get a smoke check.
Which estimation technique should I use?
Use two and compare the results. The estimation guide covers work breakdown with 15 percent contingency, three-point estimation (O plus 4M plus P, divided by 6), test point analysis, a percentage of development effort (25 to 40 percent) and planning poker.
