5.4 Monitoring, Control, and Reporting

Monitoring vs Control

Test monitoring gathers information about testing. It compares actual progress with the plan, checks whether exit criteria and related tasks are being met, and shows the current quality picture. Monitoring asks: "What is happening, and what does the evidence say?"

Test control uses monitoring information to guide action. It asks: "What should we change now?" Control actions include reprioritizing tests, adjusting the schedule, adding resources, revisiting entry or exit decisions after rework, removing blockers, or escalating risks. Monitoring without control produces reports but no correction.

A simple example: a dashboard shows only 40 percent of high-risk test cases have run and the environment is unstable. That is monitoring. The test manager then moves low-risk cosmetic tests later, asks operations to stabilize the environment, and warns stakeholders of risk to the release date. That is control.

Metrics Used in Testing

Metrics need interpretation. A large pass count may hide that high-risk features were never tested. A falling defect-discovery rate may mean quality is improving, or that testing is shallow, blocked, or repeating the same checks. A high automation count is worthless if those checks do not cover important risks. The exam favors answers that question what a metric means over answers that treat the raw number as the conclusion.

Test Progress Reports

Test progress reports are produced during testing, often daily, weekly, or per iteration. They support ongoing control and give stakeholders enough information to adjust schedule, resources, scope, or plan. The audience may include the team, managers, product owners, customers, or compliance staff.

A useful progress report includes the reporting period, progress against plan, notable deviations, impediments and workarounds, relevant metrics, new or changed risks, and testing planned for the next period. It should call out decisions needed from stakeholders, such as deferring a feature, extending testing, or accepting a residual risk.

Progress reports are tailored. A development team may need a task board, failed-build list, and defect links. Executives may need release confidence, top residual risks, schedule impact, and decisions needed. Auditors may need evidence that required activities occurred and deviations were approved.

Test Completion (Summary) Reports

A test completion report (also called a test summary report) is prepared when a project, test level, test type, test cycle, iteration, release, or maintenance activity is complete or stopped. It summarizes what was done, evaluates testing and product quality against the plan, and provides information for later testing.

Typical completion content: a test summary, evaluation against test objectives and exit criteria, deviations from the plan, impediments and workarounds, metrics from progress reports, unmitigated risks, defects not fixed, and lessons learned. The report should make residual risk visible, not bury it under pass counts.

Communicating Status

Status may be communicated verbally, or through dashboards, email, chat, online documentation, task boards, burn-down charts, CI/CD dashboards, or formal written reports. The best channel depends on the team, its distribution, regulatory needs, stakeholder preference, and urgency.

The exam trap is believing there is one universally best reporting format. A co-located Agile team may use a daily standup and a board for frequent informal updates. A distributed, regulated project may need formal written reports, signed approvals, and versioned evidence. The key is useful, timely, audience-appropriate information rather than a fixed template.

Good communication also closes the loop with control. If a report shows high-risk areas under-tested, the value comes from the decision it triggers, not from the document itself. Reporting that nobody acts on is monitoring without control.

A Worked Monitoring-to-Control Flow

Imagine a release cycle with 200 planned test cases, 60 of them tagged high-risk. Mid-cycle metrics show 120 cases run, 35 high-risk cases run, a defect find rate that is still rising, and an environment that has been down for two of the last five days. Monitoring summarizes those numbers; interpretation matters because the rising find rate plus low high-risk coverage suggests the riskiest areas are still largely unexplored.

Control then acts: the test lead reprioritizes the remaining high-risk cases ahead of low-risk cosmetic ones, asks operations to stabilize the environment, requests one extra tester for the regression backlog, and escalates a possible one-day schedule slip to the product owner with the residual-risk picture. Each action is a control response driven directly by a monitored signal, and each is recorded so the eventual completion report can explain the deviation. This loop, observe then steer, is exactly what the syllabus means by monitoring and control working together rather than as separate reporting and decision activities.

Exam Traps

• Monitoring observes; control acts. Reading a dashboard is monitoring; changing the plan because of it is control.
• A raw metric is not a conclusion; interpretation is required, and a high pass count can mask untested high-risk areas.
• Progress reports steer active testing; completion (summary) reports record a finished activity. Watch the timing in the stem.
• There is no single best reporting format; the right one fits the audience, context, and formality needed.