Managing test activities
Chapter summary
Chapter 5 of the ISTQB Foundation Level syllabus covers the management side of testing. It explains what goes into a test plan, how risk shapes test priorities, how testing progress is monitored and reported, how configuration management supports testware, and how to write a defect report. The chapter carries 335 minutes of training time and accounts for 9 of the 40 exam questions (22.5% of the exam), making it the second largest chapter by both training time and exam weight.
This page covers the main concepts at a level that complements the full Chapter 5 guide.
Test planning
A test plan documents how testing will be carried out for a given project or iteration. It covers the scope and objectives of testing, the test approach, the roles and communication arrangements, the tools and environments required, entry criteria and exit criteria, the schedule and budget, and the risk register covering both product and project risks.
Entry criteria define what must be true before a test activity can start. Exit criteria define what must be true before a test activity can be considered complete. Both sets of criteria help teams make objective decisions about when to proceed and when testing is done, rather than relying on elapsed time alone.
In iterative development, two kinds of planning happen: release planning (looking ahead across multiple iterations at the overall test approach and coverage goals) and iteration planning (looking ahead to the next iteration and deciding which items will be tested and how).
Estimation techniques used in test planning include estimation by analogy (comparing the work to similar past efforts), expert-based estimation (structured expert judgment), and metric-based techniques (using data from past projects). All estimation carries uncertainty, and the syllabus does not treat any technique as always superior.
Test case prioritization decides the order in which test cases run. Risk-based prioritization runs the highest-risk items first. Coverage-based and requirements-based prioritization follow similar logic but use different inputs. The goal is to find the most important defects as early in the execution phase as possible.
The test pyramid and testing quadrants
The test pyramid is a model suggesting that automated tests should be more numerous at lower levels (component testing) and fewer at higher levels (system testing). The idea is that lower-level tests are faster, cheaper, and easier to maintain than higher-level tests. The ratio is a guideline, not a rule.
The testing quadrants model classifies tests into four quadrants based on two dimensions: whether tests are technology-facing or business-facing, and whether they support the team (by informing development) or critique the product (by verifying it meets expectations). The model is a planning and communication tool, not a strict technical classification.
Risk and risk-based testing
A risk is a factor that could result in a negative consequence, described by its likelihood and its impact. The syllabus distinguishes product risks (things that might go wrong in the software itself, causing it to fail users or stakeholders) from project risks (things that might go wrong in the project, such as budget overruns, schedule delays, or loss of key personnel).
Risk analysis identifies and assesses risks. Risk control takes action in response, such as increasing test coverage for high-risk areas, adding mitigation steps, or accepting certain risks explicitly. Risk-based testing uses the results of risk analysis to prioritize what gets tested, in what order, and how thoroughly.
Test monitoring, control, and completion
Test monitoring is the ongoing comparison of actual test progress against the test plan. Metrics used in monitoring include test case pass and fail rates, defect counts, coverage achieved, and test execution progress against schedule.
Test control is the action taken when monitoring shows that testing is deviating from plan. Corrective actions might include reallocating resources, adjusting scope, changing the test approach, or escalating to management.
Test completion happens at milestones such as the end of a release, a sprint, or a project phase. It includes closing or handing off unresolved defects, archiving testware for future use, shutting down test environments, and producing a test completion report that summarizes what was tested, what was found, what coverage was achieved, and what lessons were learned.
Configuration management
Configuration management applies version control and change control to testware and the items that testware depends on. When test cases, test data, test environments, and test scripts are all under configuration management, test results are reproducible: you can run the same test suite against the same build in the same environment and get the same result. Without configuration management, it becomes difficult to know exactly what was tested and under what conditions.
Defect management
A defect report records a defect found during testing. Standard information in a defect report includes a short title describing the defect, the severity, the current status in the defect workflow, the environment in which the defect was found, the steps to reproduce the issue, the expected result, the actual result, and any supporting materials such as screenshots or logs.
Writing a clear defect report is a K3 learning objective in the syllabus, meaning the exam may ask you to evaluate or write a defect report for a described scenario. Reports should be factual, focused on reproducibility, and free of speculation about the cause.
Exam weight and K-levels
Chapter 5 contributes 9 questions to the exam (22.5%). Most objectives are K1 or K2, with two K3 objectives: estimation techniques and defect report writing. See the full Chapter 5 guide and the learning objectives page for the full breakdown.
Last reviewed: June 2026.