Test Monitoring, Control and Completion
A test plan is only a prediction of the future. Once execution begins, reality takes over - this topic covers how to read the dashboard, correct course when things go off track, and formally close out testing when it's done.
~11 min read
The core ideas, explained
Test Monitoring (The Dashboard)
Test monitoring and control is the continuous activity of gathering metrics to evaluate the progress of testing against the schedule and the exit criteria. Monitoring measures three things: Product Metrics (how good is the software - defect density, pass/fail rates), Process Metrics (how well is testing progressing - execution status, environment readiness), and Project Metrics (are we on budget and schedule - hours spent vs. planned).
A Test Manager checks the dashboard on Wednesday. The plan stated 200 tests should be executed by now, but the metric shows only 100 have been. Monitoring has revealed a 50% schedule variance.
Test Control (The Steering Wheel)
Control involves taking guiding or corrective actions based on the information gathered during monitoring - when reality deviates from the plan, you must act. Typical control actions include re-prioritizing (running high-risk modules immediately, delaying low-risk cosmetic tests), adjusting scope (dropping tests, with stakeholder approval), adding resources (developers help with automation, overtime), and adjusting the environment (rebooting a slow server).
Following the 50%-behind-schedule example above, the Test Manager applies a control action: re-prioritizing the remaining tests to run only "Critical" and "High" risk tests, explicitly skipping "Low" risk tests to ensure core business logic is validated before Friday's release.
Test Reporting (Progress vs. Summary)
Data must be communicated to stakeholders so they can make release decisions. A Test Progress Report is issued during testing, answering "are we on track? What's blocking us? Are there new risks?" - in Agile, this is often a daily burn-down chart or stand-up. A Test Summary Report is issued after a phase or project finishes, answering "did we meet the exit criteria? What was the overall quality? What risks remain unmitigated?"
During a two-week sprint, the team updates a burn-down chart daily (Progress Report). At the sprint's end, the Test Manager writes a document confirming exit criteria were met and listing any remaining known issues (Summary Report).
Test Completion
Testing doesn't just stop when the last test passes - it must be formally closed. Test Completion activities occur at project milestones (a release, the end of an iteration, or a cancelled project). Key activities: checking open defects are accepted as known issues or deferred, archiving testware so it can be reused for future regression, handover of automated suites and domain knowledge to the next team, and analyzing lessons learned via a retrospective.
The software launches successfully. During Test Completion, the QA lead archives the Postman API scripts in the company's Git repository, closes the temporary cloud test servers to save money, and leads a retrospective where the team realizes they need to start performance testing earlier next sprint.
Key points to remember
- Monitoring is reading the data; Control is acting on it - you cannot have control without monitoring.
- Metrics must be actionable - measuring lines of code means nothing; measuring defect discovery rate tells you if the software is stabilizing.
- Progress = during. Summary = after.
- Test Completion secures the ROI of testing - if you don't archive your testware, you have to rewrite it all for the next release.
- Retrospectives are a formal completion activity - learning from mistakes is mandated by the ISTQB syllabus.
Terminology
A few terms from this topic worth knowing precisely.
Continuously comparing actual test progress against the plan (monitoring), and taking corrective action based on that information (control).
A status report issued during testing, answering "are we on track, what's blocking us, are there new risks?" - often a daily burn-down chart or stand-up update in Agile.
A completion report issued after a phase or project finishes, answering "did we meet the exit criteria, what was the overall quality, what risks remain unmitigated?"
The activity, at project milestones, of finalizing test summary reports, archiving testware, and capturing lessons learned for future cycles.
Summary
Managing test activities requires constant vigilance. Test Monitoring uses metrics to compare actual progress against the Test Plan. When deviations occur, Test Control takes corrective action, such as risk-based re-prioritization. Test Reporting keeps stakeholders informed throughout (Progress Reports) and at the end (Summary Reports). Finally, Test Completion ensures the testing effort is properly wrapped up, with testware archived for reuse and process improvements captured for the future.
| Concept | One-line memory hook |
|---|---|
| Test Monitoring | "Where are we right now compared to the plan?" |
| Test Control | "We are behind schedule; let's drop the low-risk tests." |
| Test Progress Report | The mid-flight update (e.g. daily Agile burn-down chart) |
| Test Summary Report | The post-flight review of final quality and remaining risks |
| Test Completion | Archiving scripts, handing over knowledge, holding retrospectives |
Check your understanding
20 questions, easy to hard - click an option to see if you got it right.