Test Management
Plan, estimate, monitor and control testing like a professional. Understand risk-based testing, defect lifecycles and configuration management.
Test Management video walkthrough
A guided overview of chapter 5, connecting the exam language to practical testing decisions.
Briefing focus
Independence of testing
This is a structured lesson briefing. Real video/audio can be added later as a media source.
Estimated time
8 min
- 1Independence of testing
- 2The test plan — what goes in it
- 3Test estimation techniques
- 4Risk-based testing
Transcript brief
Plan, estimate, monitor and control testing like a professional. Understand risk-based testing, defect lifecycles and configuration management. The walkthrough introduces the core concept, works through a realistic project example, and closes with the mistakes learners most often make in quiz and exam questions.
Key takeaways
- Recognise the exam wording for this chapter.
- Apply the concept to a real software delivery situation.
- Know which detail to check first when a scenario question feels ambiguous.
Independence of testing
Test independence correlates with the ability to challenge the author’s assumptions. ISTQB recognises four increasing levels.
- Tests by the module developer — lowest independence.
- Tests by another developer in the same team — some independence.
- Tests by a separate test team inside the organisation — higher independence.
- Tests by an external body (certification, client, regulator) — highest independence.
The test plan — what goes in it
- Scope & objectives
- What will be tested, what is explicitly out of scope, and the measurable goals.
- Approach & strategy
- The test levels, types, techniques and tools you will apply.
- Entry criteria
- Conditions that must be true before testing can start — e.g., ‘code reviewed, smoke tests green’.
- Exit (completion) criteria
- Conditions that mark testing as done — e.g., ‘≥ 90% branch coverage, zero open P1 defects, all high-risk areas executed’.
Test estimation techniques
| Technique | How it works | When to use |
|---|---|---|
| Analogy-based | Compare with similar past projects | Stable domain, good historical data |
| Expert / Wideband Delphi | Multiple experts estimate independently, then converge | New domain, expert pool available |
| Three-point (PERT) | Best + 4×Most-likely + Worst, divided by 6 | Uncertain tasks needing a weighted estimate |
Real-life scenario · SaaS migration
Estimating a cloud re-platforming test effort
Situation. A product team must migrate from on-prem to AWS. Analogy-based estimation from a prior project suggested 40 person-days. Wideband Delphi with architects and SREs surfaced a hidden risk — legacy SSO integration — raising the estimate to 55. A three-point estimate gave Best=40, Most-Likely=55, Worst=90 → PERT = 58.3.
Lesson. No single technique is ‘right’. Triangulating estimates exposes risk assumptions early.
Risk-based testing
Risk = Likelihood × Impact. Higher-risk areas get disproportionately more coverage. Risk-based testing is the single most important concept in modern test management.
| Risk type | Origin | Example |
|---|---|---|
| Product risk | The software itself | Payment double-charging on retry |
| Project risk | Delivery of the project | Key tester leaves mid-project |
Defect lifecycle
Configuration management
Every test artefact — script, dataset, environment config — must be uniquely identifiable and version-controlled, so any result can be reproduced. Without CM, a ‘passed’ report is worthless because no one can say what was tested, on what build, in what environment.