Overview
Managing the Test Activities covers how testing is planned, steered and closed. Test planning includes the purpose and content of a test plan, the tester's contribution to release and iteration planning, entry and exit criteria (Definition of Ready and Definition of Done in Agile), four estimation techniques, three ways of prioritizing test cases, the test pyramid and the testing quadrants. Risk management defines risk level from likelihood and impact, separates project risks from product risks, and shows how product risk analysis and risk control shape the scope and depth of testing.
The rest of the chapter covers test monitoring, test control and test completion, with the metrics used, the content and audiences of test progress and test completion reports, and ways to communicate status. It ends with configuration management and defect management, including what a good defect report contains. It turns the planning, monitoring and completion activities from Chapter 1 into practical techniques.
How it's tested
Chapter 5 questions combine K3 calculations with K2 scenarios. Expect a three-point or ratio-based estimate to compute, a list of test cases with priorities and dependencies to order, a defect report to complete or critique, and short scenarios asking you to classify a risk, a metric, a report or a test into a quadrant.
-
Calculate the estimate
Three-point values (optimistic, most likely, pessimistic) or historical ratios, and you compute the estimate and, for three-point, the standard deviation.
-
Order the test cases
Test cases with priorities and dependencies, and you find the execution order where higher priority runs first unless it depends on a lower-priority test.
-
Classify the item
A risk, a metric, a report section or a test, and you decide whether it is project or product risk, which report it belongs in, or which testing quadrant it sits in.
Test cases TC1 (priority 1) and TC3 (priority 2) both depend on TC4 (priority 3), and TC2 (priority 2) has no dependency. Asked for the first test to run, the highest-priority test is TC1, but it cannot run until TC4 has run, so TC4 executes first, followed by TC1. The clue that overrides pure priority order is the dependency.
Syllabus sections 5
Official syllabus sections from the ISTQB outline, in outline order.
5.1 Test PlanningTest plan content, tester input to planning, entry and exit criteria, estimation, prioritization, test pyramid and quadrants.
- What it means
- A test plan describes the objectives, resources and processes for a test project; it documents the means and schedule for achieving test objectives, supports communication and shows adherence to (or justified deviation from) the test policy and strategy. Typical content includes context of testing, assumptions and constraints, stakeholders, communication, a risk register, the test approach (levels, types, techniques, deliverables, entry and exit criteria, independence, metrics, test data and environment requirements), and budget and schedule. Testers contribute to release planning (testable user stories and acceptance criteria, risk analysis, test effort, test approach) and to iteration planning (story risk analysis, testability, task breakdown, effort for testing tasks).
- What to understand
- Entry criteria are preconditions for an activity (available resources and testware, initial quality such as passed smoke tests); exit criteria define completion (thoroughness measures such as coverage and unresolved defects, and completion criteria such as planned tests executed). Running out of time or budget can be a valid exit criterion if stakeholders accept the risk. The four estimation techniques are ratios, extrapolation, Wideband Delphi (with Planning Poker as a variant) and three-point estimation, where E = (a + 4m + b) / 6 and SD = (b - a) / 6. Prioritization can be risk-based, coverage-based (including additional coverage prioritization) or requirements-based, adjusted for dependencies and resource availability. The test pyramid shows that lower layers have smaller, more isolated, faster and cheaper tests; the testing quadrants group tests as business- or technology-facing and supporting the team or critiquing the product.
- How it shows up
- K3 questions ask you to calculate an estimate or order test cases; K2 questions ask which item belongs in a test plan, which is an entry versus exit criterion, or which quadrant a test belongs to; a K1 question may ask about the test pyramid.
- Common confusion
- Placing usability testing in Q4 because it is non-functional; usability and user acceptance testing are Q3 (business facing, critique the product), while Q4 holds smoke tests and non-functional tests other than usability.
5.2 Risk ManagementRisk level, project versus product risks, product risk analysis and product risk control.
- What it means
- A risk is a potential event, hazard, threat or situation whose occurrence causes an adverse effect, characterized by risk likelihood (a probability greater than zero and less than one) and risk impact (the harm). Together they express the risk level; the higher the level, the more important its treatment. Project risks concern management and control of the project: organizational issues, people issues, technical issues such as scope creep or poor tool support, and supplier issues. Product risks concern quality characteristics: missing or wrong functionality, incorrect calculations, poor performance, security vulnerabilities, poor user experience.
- What to understand
- Product risk analysis consists of risk identification (brainstorming, workshops, interviews, cause-effect diagrams) and risk assessment (categorization, likelihood, impact, level, prioritization, proposed handling), using quantitative scoring (likelihood times impact), a qualitative risk matrix, or both. Its results determine test scope, levels, types, techniques, coverage, effort, prioritization and whether non-testing measures are needed. Product risk control is risk mitigation plus risk monitoring; response options include mitigation by testing, acceptance, transfer and a contingency plan. Mitigating by testing means choosing experienced testers, the right independence, reviews and static analysis, appropriate techniques and coverage, the right test types, and dynamic and regression testing.
- How it shows up
- K2 questions give a list of risks and ask which are product risks, or describe a high-risk area and ask how product risk analysis should influence the thoroughness and scope of testing; a K1 question may ask how risk level is determined.
- Common confusion
- Classifying a risk by where it was found rather than what it affects; a delayed test environment is a project risk, while a slow checkout under load is a product risk.
5.3 Test Monitoring, Test Control and Test CompletionMetrics, test progress and completion reports, and communicating test status.
- What it means
- Test monitoring gathers information to assess progress and check exit criteria; test control turns that information into control directives such as reprioritizing tests when a risk materializes, re-checking entry or exit criteria after rework, adjusting the schedule when an environment is late, or adding resources. Test completion consolidates experience and testware at milestones such as the end of a test level, an iteration or a release. Metrics fall into project progress, test progress, product quality, defect, risk, coverage and cost groups.
- What to understand
- Test progress reports support ongoing control and are produced regularly; they include the test period, progress against schedule and notable deviations, impediments and workarounds, metrics, new and changed risks, and testing planned for the next period. Test completion reports summarize a finished level, cycle or iteration and include a test summary, an evaluation against the test plan's objectives and exit criteria, deviations from the plan, impediments, metrics, unmitigated risks, unfixed defects and lessons learned. Audience shapes formality and frequency, and status can be communicated verbally, through dashboards such as burn-down charts, electronically, through online documentation or with formal reports.
- How it shows up
- K2 questions list report items and ask which belongs only in a test completion report (for example lessons learned or unmitigated risks), or describe a distributed team and ask which communication option fits; a K1 question asks for an example metric.
- Common confusion
- Treating lessons learned and the evaluation against exit criteria as progress-report content; they belong to the test completion report.
5.4 Configuration ManagementIdentifying, controlling and tracking testware and test items as configuration items.
- What it means
- Configuration management (CM) identifies, controls and tracks work products such as test plans, test cases, test scripts, test results, test logs and test reports as configuration items. For a complex configuration item such as a test environment, CM records the items it consists of, their relationships and versions. Once a configuration item is approved for testing, it becomes a baseline and can only be changed through a formal change control process.
- What to understand
- To support testing, all configuration items, including the test items that make up the test object, are uniquely identified, version controlled, tracked for changes and related to each other so traceability is maintained, and testware references documentation and software items unambiguously. Keeping baselines makes it possible to revert to an earlier one and reproduce earlier test results. In DevOps pipelines, automated CM is normally part of continuous integration and delivery.
- How it shows up
- A K2 question describes a team unable to reproduce last month's test results or unsure which build was tested, and asks how configuration management would have helped.
- Common confusion
- Thinking configuration management applies only to source code; testware and test environments are configuration items too.
5.5 Defect ManagementThe defect management workflow and how to prepare a complete defect report.
- What it means
- Defect management is a process with a workflow from discovery to closure: logging the reported anomaly, analyzing and classifying it, deciding a response such as fix or keep as is, and closing the report. Reported anomalies may turn out to be real defects or something else, such as a false positive or a change request. Defect reports give those resolving the issue enough information, track work product quality, and suggest improvements to development and test processes.
- What to understand
- A defect report from dynamic testing typically contains a unique identifier, a short title, the date, issuing organization and author, the test object and test environment, the context (test case, activity, SDLC phase, technique or data), a description with reproduction steps and supporting logs or screenshots, expected and actual results, severity (impact), priority to fix, status (such as open, deferred, duplicate, awaiting confirmation testing, re-opened, closed, rejected) and references such as the test case. Severity describes impact; priority describes urgency of fixing, and the two can differ.
- How it shows up
- A K3 question shows a draft defect report and asks which information is missing or most needed for the developer to reproduce the failure, or which field holds a given value.
- Common confusion
- Mixing up severity and priority; a cosmetic typo on a public landing page can be low severity but high priority.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Three-point estimation
An expert-based technique using an optimistic (a), most likely (m) and pessimistic (b) estimate, combined as the weighted mean E = (a + 4m + b) / 6, with standard deviation SD = (b - a) / 6.
- Remember
- With a = 6, m = 9 and b = 18 person-hours, E = 10 and SD = 2, reported as 10 plus or minus 2 person-hours.
- Tested as
- K3 calculation questions.
- Trap
- Using a simple average (a + m + b) / 3 or forgetting to weight m by four.
-
Estimation based on ratios and extrapolation
Metrics-based techniques: ratios use historical figures such as a development-to-test effort ratio, and extrapolation uses measurements from the current project to project remaining effort.
- Remember
- With a 3:2 development-to-test ratio and 600 person-days of development, test effort is 400 person-days; extrapolation suits iterative lifecycles, for example averaging the last three iterations.
- Tested as
- K3 calculation questions.
- Trap
- Inverting the ratio and calculating 900 person-days.
-
Wideband Delphi and Planning Poker
Expert-based iterative estimation: experts estimate in isolation, results are compared, outliers are discussed, and new estimates are made until consensus is reached.
- Remember
- Planning Poker is a variant of Wideband Delphi, commonly used in Agile, with cards showing effort sizes.
- Tested as
- Questions asking which technique a team is using.
- Trap
- Calling Planning Poker a metrics-based technique.
-
Test case prioritization
Risk-based (tests for the most important risks first), coverage-based (tests with the highest coverage first, or additional coverage prioritization where each next test adds the most new coverage) and requirements-based (tests traced to the highest-priority requirements first).
- Remember
- Dependencies override pure priority: a lower-priority test that a higher-priority test depends on must run first, and resource availability also constrains order.
- Tested as
- K3 ordering questions.
- Trap
- Running tests strictly in priority order and ignoring dependencies.
-
Entry and exit criteria
Entry criteria are preconditions for starting an activity; exit criteria define what must be achieved to declare it complete.
- Remember
- In Agile, exit criteria are often called the Definition of Done and entry criteria for a user story the Definition of Ready; running out of time or budget can be a valid exit if stakeholders accept the risk.
- Tested as
- K2 compare-and-contrast questions.
- Trap
- Labeling "all smoke tests passed" as an exit criterion, when it is a typical entry criterion for test execution.
-
Test pyramid
A model showing tests at different granularity: lower layers have small, isolated, fast, cheap tests in large numbers; upper layers have fewer complex, slower, end-to-end tests.
- Remember
- Layer names vary; Cohn's original model used unit, service and UI tests, and another common version uses unit, integration and end-to-end tests.
- Tested as
- K1 recall question.
- Trap
- Thinking higher layers need more tests because they cover more functionality.
-
Testing quadrants
Q1 technology facing, support the team (component and component integration tests, automated in CI); Q2 business facing, support the team (functional tests, examples, user story tests, prototypes, API testing, simulations); Q3 business facing, critique the product (exploratory, usability, user acceptance testing); Q4 technology facing, critique the product (smoke tests and non-functional tests except usability).
- Remember
- Q1 is automated, Q3 is mostly manual, Q2 and Q4 are often automated.
- Tested as
- K2 summarize questions on quadrants with levels and types.
- Trap
- Putting usability testing in Q4 with the other non-functional tests.
-
Risk level
A measure of a risk derived from its likelihood (probability of occurrence) and its impact (consequences).
- Remember
- Quantitatively, risk level is likelihood multiplied by impact; qualitatively it can be read from a risk matrix.
- Tested as
- K1 identify-the-risk-level questions.
- Trap
- Ranking risks by impact alone.
-
Project risks versus product risks
Project risks affect management and control: delays, inaccurate estimates, skills gaps, staff shortages, scope creep, supplier failure. Product risks affect quality characteristics: wrong functionality, incorrect calculations, poor performance, security vulnerabilities.
- Remember
- Project risks threaten schedule, budget or scope; product risks threaten users, revenue, reputation and, in extreme cases, safety.
- Tested as
- K2 distinguish questions.
- Trap
- Classifying "test environment delivered late" as a product risk because it affects testing of the product.
-
Product risk control responses
Risk mitigation by testing, risk acceptance, risk transfer, or a contingency plan, followed by risk monitoring.
- Remember
- Mitigating by testing includes selecting experienced testers, choosing independence, reviews and static analysis, appropriate techniques and coverage, the right test types, and dynamic and regression testing.
- Tested as
- K2 explain-the-measures questions.
- Trap
- Thinking testing is the only possible response to a product risk.
-
Test progress report versus test completion report
Progress reports are regular and support ongoing control; completion reports summarize a finished level, cycle or iteration once exit criteria are met.
- Remember
- Only the completion report evaluates testing and quality against the test plan's objectives and exit criteria and records lessons learned, unmitigated risks and unfixed defects.
- Tested as
- K2 summarize questions on report content and audience.
- Trap
- Putting "testing planned for the next period" in a completion report; it belongs in progress reports.
-
Severity versus priority
Severity is the degree of impact of a defect on stakeholders or requirements; priority is the urgency of fixing it.
- Remember
- They are recorded separately in a defect report and can point in opposite directions.
- Tested as
- K3 defect report questions.
- Trap
- Assuming high severity always means high priority.
-
Configuration management baseline
A configuration item approved for testing becomes a baseline that can only be changed through formal change control.
- Remember
- Baselines let teams revert to an earlier configuration and reproduce previous test results.
- Tested as
- K2 questions on how CM supports testing.
- Trap
- Thinking CM covers only source code rather than testware and environments.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Project risk vs. product risk
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Project risk | A risk to the management and control of the project | Affects schedule, budget or scope, for example late deliveries, skills gaps, supplier bankruptcy | Classifying a late test environment as a product risk |
| Product risk | A risk related to product quality characteristics | Affects users and the business, for example incorrect calculations, poor response time, security vulnerabilities | Classifying an inexperienced tester as a product risk |
Q1 vs. Q2 vs. Q3 vs. Q4 testing quadrants
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Q1 | Technology facing, supports the team | Component and component integration tests, automated in CI | Placing API tests here; they are listed in Q2 |
| Q2 | Business facing, supports the team | Functional tests, examples, user story tests, prototypes, API testing, simulations | Assuming these must all be manual |
| Q3 | Business facing, critiques the product | Exploratory, usability and user acceptance testing, mostly manual | Placing usability testing in Q4 |
| Q4 | Technology facing, critiques the product | Smoke tests and non-functional tests except usability, often automated | Placing exploratory testing here |
Test progress report vs. test completion report
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Test progress report | Regular report supporting ongoing test control | Covers the period, deviations, impediments, metrics, new risks and next period's testing | Expecting lessons learned in it |
| Test completion report | Summary produced when a level, cycle or iteration is complete | Evaluates against objectives and exit criteria, lists unmitigated risks, unfixed defects and lessons learned | Thinking it is produced only once at the end of the whole project |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Simple average estimate
- What candidates pick
- The plain average of the three estimates in a three-point question.
- Why it looks right
- Averaging three numbers is the natural instinct and the result is close to the right answer.
- Why it's wrong
- Three-point estimation uses the weighted mean E = (a + 4m + b) / 6; the distractor values are usually the unweighted mean or a result using the wrong divisor.
Clue to watch for The stem gives optimistic, most likely and pessimistic values.
-
Priority ignores dependencies
- What candidates pick
- The highest-priority test case as the first to execute.
- Why it looks right
- Prioritization means running the most important tests first.
- Why it's wrong
- If a higher-priority test depends on a lower-priority one, the lower-priority test must run first; the syllabus explicitly calls this out.
Clue to watch for A dependency column or phrase such as "requires TC4 to have run".
-
Where found versus what affected
- What candidates pick
- Product risk for "the test team lacks performance testing skills".
- Why it looks right
- It could lead to performance problems in the product.
- Why it's wrong
- Skills shortages are people issues, a project risk; product risks describe a possible quality problem in the product itself.
Clue to watch for The risk describes people, schedule, tools, suppliers or budget rather than the product's behavior.
-
Usability is Q4
- What candidates pick
- Q4 for usability testing.
- Why it looks right
- Usability is a non-functional quality characteristic and Q4 holds non-functional tests.
- Why it's wrong
- Q4 explicitly excludes usability; usability testing is business facing and critiques the product, so it sits in Q3 with exploratory and user acceptance testing.
Clue to watch for The test involves users judging the experience.
-
Lessons learned in progress reports
- What candidates pick
- A test progress report as the place for lessons learned and unfixed defects.
- Why it looks right
- Progress reports are frequent and carry most of the test information.
- Why it's wrong
- Lessons learned, unmitigated risks, unfixed defects and the evaluation against exit criteria belong to the test completion report.
Clue to watch for The report is described as summarizing a completed level, cycle or iteration.
-
Missing reproduction details
- What candidates pick
- "Priority" or "author's role" as the most important missing field in a draft defect report that has no steps or environment.
- Why it looks right
- Those fields are standard and easy to spot as absent.
- Why it's wrong
- A defect report's main purpose is to give those resolving the defect enough information to reproduce and fix it, so the steps, test environment and expected versus actual results matter most.
Clue to watch for The developer cannot reproduce the failure from the draft.
-
Time-out is never an exit
- What candidates pick
- "Testing may only stop when all exit criteria based on coverage and defects are met."
- Why it looks right
- It sounds disciplined and quality-focused.
- Why it's wrong
- The syllabus says running out of time or budget can be a valid exit criterion if stakeholders have reviewed and accepted the risk of going live without further testing.
Clue to watch for Stakeholders have explicitly accepted the remaining risk.
Answer framework
For a Chapter 5 question, decide first whether it is a calculation, an ordering problem or a classification, then apply the matching steps.
- For an estimate, write the formula before using numbers: E = (a + 4m + b) / 6 and SD = (b - a) / 6, or the ratio scaled to the known effort.
- For prioritization, sort by priority, then move any test that a higher-priority test depends on ahead of it, and check resource windows.
- For a risk, ask whether it threatens schedule, budget or scope (project risk) or the product's quality (product risk).
- For a report or quadrant, identify the purpose and audience, then match to progress versus completion report or to business versus technology facing and support versus critique.
- For a defect report, ask what the person fixing the defect needs to reproduce it, and choose the field that fills that gap.
Practice question
Want more like this? The ISTQB CTFL practice test has questions for every domain.
Checklist
0 of 16
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Start with the three K3 objectives, because they decide this chapter's score. Practice three-point estimation and ratio-based estimation until you write the formula automatically, then work several prioritization exercises where a high-priority test depends on a low-priority one. Then write two or three defect reports of your own for real failures you have seen, checking each against the syllabus list of fields.
Next, cover risk management: learn the four groups of project risks (organizational, people, technical, supplier) and practice classifying mixed lists, then learn how product risk analysis changes scope, techniques, coverage and effort. After that, build one-page summaries of the testing quadrants and the two report types, since these are frequent K2 questions with tempting distractors.
Candidates commonly underestimate configuration management and the communication options because they look like common sense, but questions test specific points such as baselines and change control. Afterward, do timed mixed sets that include calculations, review every miss by redoing the arithmetic on paper, and then finish with Chapter 6 on test tools and automation.
FAQ
How many CTFL questions come from Managing the Test Activities?
The official exam structure gives Chapter 5 nine of the 40 questions: one K1, five K2 and three K3, which is 22.5% of the exam.
What is the three-point estimation formula?
The estimate is E = (a + 4m + b) / 6, where a is optimistic, m most likely and b pessimistic. The standard deviation, used to express the range, is (b - a) / 6.
What is the difference between project risk and product risk?
Project risks concern managing the project, such as delays, staff shortages, poor estimates or supplier failure. Product risks concern the quality of the product, such as wrong calculations, poor performance or security vulnerabilities.
Which quadrant does usability testing belong to?
Q3, which is business facing and critiques the product, together with exploratory and user acceptance testing. Q4 covers smoke tests and non-functional tests other than usability.
Can running out of time be a valid exit criterion?
Yes. The syllabus says that ending testing because time or budget is exhausted can be acceptable if stakeholders have reviewed and accepted the risk of going live without further testing.
What is the difference between severity and priority in a defect report?
Severity is the degree of impact the defect has on stakeholders or requirements, while priority is how urgently it should be fixed. They are recorded separately and do not always match.
How does Chapter 5 connect to other chapters?
It expands the planning, monitoring, control and completion activities from Chapter 1, uses test levels and types from Chapter 2 in the pyramid and quadrants, and uses Chapter 4 coverage in prioritization and exit criteria.
Other Quality Management certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 5 knowledge
You have just covered estimation formulas, prioritization with dependencies, risk classification, reporting and defect reports. Check that you can do the calculations and classifications accurately under exam timing.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the ISTQB CTFL AI tutor Get any concept explained your way