ISTQB CTFL Chapter 5: Managing the Test Activities (Planning, Risk, Reporting, Defects)

ISTQB CTFL › 5. Managing the Test Activities Syllabus v4.0.1 · updated 3 Nov 2026

Keywords to remember (K1): defect management, defect report, entry criteria, exit criteria, product risk, project risk, risk, risk analysis, risk assessment, risk control, risk identification, risk level, risk management, risk mitigation, risk monitoring, risk-based testing, test approach, test completion report, test control, test monitoring, test plan, test planning, test progress report, test pyramid, test strategy, testing quadrants.

5.1 Test planning

5.1.1 Purpose and content of a test plan (K2)

A test plan describes the test objectives, resources and processes for a test project. It:

• documents the means and schedule for reaching the test objectives,
• helps ensure the test activities will meet the agreed criteria,
• is a communication tool for the team and stakeholders, and
• shows that testing follows the test policy and test strategy (or explains why it deviates).

Writing the plan forces the team to think through risks, schedules, people, tools, costs and effort before they happen.

5.1.2 Tester’s contribution to iteration and release planning (K1)

5.1.3 Entry criteria and exit criteria (K2)

Both should be defined per test level and depend on the test objectives. Running out of time or budget can also be a valid exit criterion, if stakeholders have reviewed and accepted the risk of going live without more testing.

5.1.4 Estimation techniques (K3)

Estimates are always based on assumptions and contain error; small tasks are estimated more accurately, so large tasks are broken down.

Worked example: three-point estimation

A tester estimates a regression cycle at a = 3 days, m = 5 days, b = 13 days.

• E = (3 + 4 × 5 + 13) / 6 = 36 / 6 = 6 days
• SD = (13 − 3) / 6 = 10 / 6 ≈ 1.67 days
• Report it as 6 ± 1.67 days (about 4.3 to 7.7 days).

Worked example: extrapolation

Test effort in the last three sprints was 18, 22 and 20 person-days. Extrapolating with the average: (18 + 22 + 20) / 3 = 20 person-days for the next sprint.

5.1.5 Test case prioritization (K3)

Once test cases are assembled into suites, they are arranged in a test execution schedule.

Two constraints override pure priority:

1. Dependencies: if a high-priority test depends on a lower-priority one, the lower-priority test runs first.
2. Resource availability: tools, environments or people may only be available in certain time windows.

Worked example

Order: TC4 → TC1 → TC2 → TC3. TC4 has the lowest priority, but TC1 and TC2 depend on it, so it must run first. Then the remaining tests follow their priority, with TC3 after TC1 as required.

5.1.6 Test pyramid (K1)

The test pyramid shows that tests have different granularity and helps decide how much to automate at each layer.

The higher the layer: the lower the granularity and isolation, and the higher the execution time. Layer names and numbers vary; Mike Cohn’s original model used unit, service and UI tests.

5.1.7 Testing quadrants (K2)

Brian Marick’s testing quadrants group test levels with test types, activities, techniques and work products in Agile development. They help make sure all needed test types and levels are included and help explain test types to everyone.

Two dimensions: business facing vs technology facing, and support the team (guide development) vs critique the product (measure it against expectations).

5.2 Risk management

Risk management raises the chance of meeting objectives, improves product quality and builds stakeholder confidence. Its two main activities:

• Risk analysis = risk identification + risk assessment
• Risk control = risk mitigation + risk monitoring

A test approach in which test activities are selected, prioritised and managed based on risk analysis and control is called risk-based testing.

5.2.1 Risk definition and attributes (K1)

A risk is a potential event, hazard, threat or situation whose occurrence causes an adverse effect.

• Risk likelihood: the probability it happens (greater than 0 and less than 1)
• Risk impact (harm): the consequences if it happens

Together they give the risk level. The higher the level, the more important it is to treat the risk.

5.2.2 Project risks and product risks (K2)

5.2.3 Product risk analysis (K2)

Aim: create awareness of product risk so test effort minimises the residual product risk. Start it early in the SDLC.

• Risk identification: build a comprehensive list of risks using brainstorming, workshops, interviews or cause-effect diagrams.
• Risk assessment: categorise risks, determine likelihood, impact and level, prioritise them and propose how to handle them.
• Quantitative: risk level = likelihood × impact.
• Qualitative: risk level from a risk matrix.

Results of product risk analysis are used to:

• determine the test scope,
• determine test levels and propose test types,
• choose test techniques and the coverage to achieve,
• estimate effort for each task,
• prioritise testing to find critical defects early, and
• decide whether activities other than testing could reduce risk.

Example risk matrix (likelihood × impact, each 1 to 3):

5.2.4 Product risk control (K2)

Risk control = all measures taken in response to analysed risks.

• Risk mitigation: implement the proposed actions to lower the risk level.
• Risk monitoring: check that mitigation works, improve the assessment and spot emerging risks.

Response options: mitigation by testing, risk acceptance, risk transfer or a contingency plan.

Ways to mitigate product risk by testing:

• Choose testers with the right experience and skills for the risk type
• Apply the right level of independence
• Do reviews and static analysis
• Apply suitable test techniques and coverage levels
• Apply test types that address the affected quality characteristics
• Run dynamic testing, including regression testing

5.3 Test monitoring, test control and test completion

• Test monitoring gathers information to assess progress and check whether exit criteria are met (for example coverage of product risks, requirements or acceptance criteria).
• Test control uses that information to give control directives: corrective actions for effective and efficient testing.
• Test completion collects data at milestones (end of a test level, iteration, project, release or maintenance release) to consolidate experience and testware.

Examples of control directives:

• Reprioritise tests when an identified risk becomes an issue
• Re-evaluate whether a test item meets entry or exit criteria after rework
• Adjust the test schedule when the test environment is delivered late
• Add resources where needed

5.3.1 Metrics used in testing (K1)

5.3.2 Test reports: purpose, content and audience (K2)

Different audiences need different information, which affects formality and frequency.

5.3.3 Communicating the status of testing (K2)

Options: verbal communication, dashboards (CI/CD dashboards, task boards, burn-down charts), electronic channels (email, chat), online documentation, and formal test reports. One or more can be used. Distributed teams across time zones often need more formal communication, and information should be tailored to each stakeholder group.

5.4 Configuration management (K2)

Configuration management (CM) identifies, controls and tracks work products such as test plans, strategies, conditions, cases, scripts, results, logs and reports as configuration items.

• For complex items (for example a test environment), CM records the parts, their relationships and versions.
• An item approved for testing becomes a baseline and can only change through formal change control.
• CM records changes when a new baseline is created, so the team can revert to a previous baseline to reproduce earlier test results.

CM ensures that all configuration items, including test items, are uniquely identified, version-controlled, tracked for changes and related to each other (supporting traceability), and that documentation and software items are referenced unambiguously in testware. In DevOps pipelines, CM is usually automated.

5.5 Defect management (K3)

Reported anomalies may be real defects or something else (for example a false positive or a change request). A defect management process has at least a workflow from discovery to closure (log, analyse and classify, decide the response such as fix or keep, close) and classification rules, and everyone must follow it. Defects from static testing should be handled similarly.

Defect reports aim to:

• give the people resolving the issue enough information to fix it,
• provide a way to track the quality of the work product, and
• give ideas for improving development and test processes.

A defect report from dynamic testing typically includes:

Learning objectives checklist

Next: Chapter 6: Test Tools.