Test Management — Planning, Estimation, and Metrics
Test management is more than assigning tasks. Learn how to write a test plan, estimate testing effort accurately, and use metrics to monitor and control your test process.
ISTQB Foundation Level Series — Part 9 of 10 This series walks through every major topic of the ISTQB CTFL syllabus. Start from Part 1 or jump to any section that interests you.
1. Why Test Management Matters
Without test management, testing becomes random. Testers work on whatever feels most interesting. Nobody knows what has been tested. Defects found late are a surprise rather than a managed outcome. Stakeholders have no visibility into quality.
Test management replaces guesswork with deliberate decision-making. It answers the fundamental questions:
- What are we testing and why?
- How long will it take and what resources do we need?
- How do we know when we’re done?
- How is testing progressing right now?
These questions matter whether you’re running a one-week sprint or a six-month integration test programme. The artefacts scale — a Agile team’s test approach in a sprint plan and a regulated industry’s formal test plan are different in size, but they answer the same questions.
2. Test Planning (ISTQB 5.1)
Purpose of a test plan
A test plan is a document — formal or informal — that records the decisions made about testing. It is not a list of test cases. Its purpose is to communicate intent and enable coordination.
A well-written test plan captures:
- Scope — what is in scope and what is explicitly out of scope
- Objectives — what the testing is trying to achieve (confidence in specific quality characteristics, compliance with standards, risk reduction)
- Approach — which test levels, types, and techniques will be used
- Resources — people, environments, tools, and data required
- Schedule — key milestones, dependencies, and delivery dates
- Risks — what could go wrong, and how it will be mitigated
Simplified IEEE 829 structure
The IEEE 829 standard for test documentation provides a classic template. Simplified for practical use:
| Section | Content |
|---|---|
| Scope | Modules, features, and integrations under test; explicit exclusions |
| Approach | Test levels (unit, integration, system, acceptance), types (functional, performance, security), techniques |
| Environment | Hardware, OS, databases, third-party services, test data setup |
| Schedule | Start/end dates, entry criteria milestones, exit criteria milestones |
| Roles and responsibilities | Who plans, executes, reviews, and signs off |
| Risks and contingencies | Top N risks with probability, impact, and mitigation |
| Entry criteria | Conditions that must be met before testing begins |
| Exit criteria | Conditions that must be met before testing is considered complete |
Entry, Exit, and Suspension criteria
These three criteria types are among the most exam-tested topics in ISTQB test management.
Entry criteria — preconditions for starting a test phase. If these aren’t met, starting testing is wasteful or impossible.
Examples:
- Test environment is provisioned and accessible
- Build with all committed user stories has been deployed
- Smoke test suite passes with zero failures
- Test data has been loaded and verified
Exit criteria — conditions that signal a test phase is complete and the product can move forward.
Examples:
- All planned test cases have been executed
- No open critical or high-severity defects
- Defect density below 0.5 defects per function point
- Test coverage target achieved (e.g., 80% branch coverage)
Suspension criteria — conditions that pause testing because continuing would be counterproductive.
Examples:
- More than 20% of test cases are blocked by a single defect
- Test environment is unavailable for more than 4 hours
- A critical defect makes the core flow untestable
When suspension criteria are triggered, testing pauses until the resumption criteria are met — conditions that allow testing to restart (e.g., defect fixed and verified, environment restored).
:::tip[Agile and the test plan] For Agile teams, the test plan is often part of the sprint plan rather than a separate document. The questions are the same — scope, approach, risks, definition of done — but the answers live in the sprint backlog, the team’s Definition of Done, and the acceptance criteria on each story. :::
3. Test Estimation (ISTQB 5.1.4)
Why estimation is hard
Testing effort is notoriously difficult to estimate accurately because:
- Requirements are often incomplete or change during development
- The complexity of interactions between components is hard to predict upfront
- Defect density is unknown until testing begins
- Non-test activities (environment setup, defect management, reporting) are frequently under-counted
- Regression scope grows as the product matures
Despite these challenges, an estimate is always better than no estimate. Even a rough estimate enables planning, resource allocation, and risk conversations.
Estimation techniques
Expert-Based Estimation (Delphi / Wideband Delphi)
Ask experienced testers to independently estimate effort, then compare and discuss differences. Repeat until consensus is reached. Fast and pragmatic, but relies on having relevant experience available.
Metrics-Based Estimation (Historical Data)
Use data from previous similar projects:
- Average time to write and execute a test case
- Defect discovery rate per test hour
- Rework ratio (how much time is spent on defect management vs. pure testing)
If your team executes an average of 12 test cases per person per day, and you have 480 test cases to execute, you need approximately 40 person-days — before adding time for defect management, reporting, and rework.
Work Breakdown Structure (WBS)
Decompose testing into atomic tasks, estimate each task individually, then sum. This is the most accurate method but also the most time-consuming to prepare. Works best for large, well-defined test programmes.
Three-Point Estimation (PERT)
Produces a single estimate from three scenarios — optimistic, most likely, and pessimistic:
:::info[PERT formula] E = (O + 4M + P) / 6
Where:
- O = Optimistic estimate (best case, everything goes smoothly)
- M = Most likely estimate (realistic, normal conditions)
- P = Pessimistic estimate (worst case, significant problems)
- E = Expected estimate
The formula weights the most likely estimate four times more than the extremes, producing a weighted average that accounts for uncertainty.
Example: If O = 5 days, M = 8 days, P = 17 days: E = (5 + 32 + 17) / 6 = 54 / 6 = 9 days :::
Practical estimation tips
- Include all activities — test case design, environment setup, test data preparation, defect management, retesting, reporting, and meetings. Pure execution is typically only 40–60% of total testing effort.
- Add a 20–30% contingency buffer — unexpected complexity, environment issues, and scope changes are normal, not exceptional.
- Give ranges, not single numbers — “6 to 10 days” is more honest and useful than “8 days”. It communicates uncertainty and prevents commitment to an implausible point estimate.
- Document your assumptions — an estimate is only as good as the assumptions it rests on. If the build is delayed, the estimate changes. Say that explicitly.
4. Test Monitoring and Control (ISTQB 5.3)
Monitoring vs control
Monitoring is collecting data about what is happening: how many test cases have been executed, how many defects have been found, is the team on schedule.
Control is acting on that data: reassigning testers to a high-risk area, pausing testing on a stable module, escalating a critical defect, adjusting the exit criteria when scope changes.
Monitoring without control is just reporting. Control without monitoring is guessing. You need both.
Key test metrics
Progress metrics
These tell you whether testing is proceeding as planned.
| Metric | Formula / Meaning |
|---|---|
| Test case preparation progress | Cases written / Cases planned × 100% |
| Test execution progress | Cases executed / Cases to execute × 100% |
| Test pass rate | Cases passed / Cases executed × 100% |
| Blocked test rate | Blocked cases / Cases to execute × 100% |
Quality metrics
These tell you about the quality of the product under test.
| Metric | Formula / Meaning |
|---|---|
| Defect density | Defects found / Size (e.g., per 1000 lines of code or per function point) |
| Defect removal efficiency (DRE) | Defects found before release / Total defects (pre-release + post-release) × 100% |
| Escaped defects | Defects found by customers after release |
| Defect severity distribution | % critical / high / medium / low defects |
A DRE of 95% means 95% of defects were found before the product reached users — a common industry target for high-quality software.
Process metrics
These tell you about the efficiency and effectiveness of the test process itself.
| Metric | Meaning |
|---|---|
| Execution rate | Test cases executed per person per day |
| Time to detect | Average time between defect introduction and discovery |
| Automation ROI | (Time saved by automation) / (Cost to build and maintain automation) |
| Review effectiveness | Defects found in reviews / Total defects found × 100% |
Test reporting
Test metrics feed two types of reports:
Status report (for the team) — frequent (daily or sprint-level), detailed, focused on current blockers and immediate decisions. Covers: test execution progress, new defects, environment status, risks materialising.
Test summary report (for management) — produced at the end of a test phase or release. Covers: overall test objectives achieved, quality assessment, significant risks and issues, deviations from plan, recommendation (release or not release).
5. Risk-Based Testing
Product risk vs project risk
Product risk is risk that the software itself will fail to meet user needs or quality standards. Examples: security vulnerabilities, performance degradation under load, data corruption.
Project risk is risk that the testing project will not be completed on time, within budget, or to the required quality. Examples: key tester leaves the team, test environment unavailable, requirements change late.
Both types require management attention. ISTQB test management focuses primarily on product risk, but a good test manager tracks both.
Risk-based testing approach
Risk-based testing uses product risk to drive test prioritisation:
- Identify — list the product risks relevant to this release.
- Assess — for each risk, estimate its likelihood and impact. A simple 3×3 matrix (Low/Medium/High) is sufficient for most projects.
- Prioritise — rank risks by likelihood × impact. Allocate more testing time and more thorough techniques to high-risk areas.
- Review — as testing progresses and defects are found (or not found), reassess the risk landscape. Risks can be reclassified as new information emerges.
The practical result: if time runs short, you have already tested the highest-risk areas. The residual risk is concentrated in lower-priority areas where the likelihood or impact of failure is lower.
Minimal Test Plan Template
Use this template as a starting point for any feature or sprint:
## Minimal Test Plan Template
**Project:** [Name]
**Scope:** [What is/isn't tested]
**Approach:** [Levels, types, techniques]
**Environment:** [Required setup]
**Schedule:** [Key milestones]
**Risks:** [Top 3 risks + mitigation]
**Entry criteria:** [...]
**Exit criteria:** [...]How to use it: Fill it in before starting testing on a new feature. Share it with the developer and product owner for alignment. Update it when scope or schedule changes.
6. Conclusion
Test management is the infrastructure that makes quality visible and actionable.
- Test planning aligns the team on scope, approach, and success criteria before work begins.
- Estimation turns uncertainty into a manageable range and sets realistic expectations.
- Monitoring and control provide the feedback loop that keeps testing on track.
- Risk-based testing ensures the most important areas get the most attention, especially when time is short.
None of these require heavyweight processes. A one-page test plan, a PERT estimate discussed in sprint planning, and a simple dashboard of pass rate and open defects will take most teams a long way.
Action item: Before you start testing your next feature, take 20 minutes to fill out the minimal test plan template above. Share it with one other person on the team. The conversations it triggers will improve the quality of your testing more than any technique.
Next up — Part 10: Tool Support for Testing — Automation, Test Management, and Defect Tracking