All learning objectives
5.1 Test Planning
FL-5.1.1K2Exemplify the purpose and content of a test plan
FL-5.1.2K1Recognize how a tester adds value to iteration and release planning
FL-5.1.3K2Compare and contrast entry criteria and exit criteria
FL-5.1.4K3Use estimation techniques to calculate the required test effort
FL-5.1.5K3Apply test case prioritization
FL-5.1.6K1Recall the concepts of the test pyramid
FL-5.1.7K2Summarize the testing quadrants and their relationships with test levels and test types
5.2 Risk Management
FL-5.2.1K1Identify risk level by using risk likelihood and risk impact
FL-5.2.2K2Distinguish between project risks and product risks
FL-5.2.3K2Explain how product risk analysis may influence thoroughness and test scope
FL-5.2.4K2Explain what measures can be taken in response to analyzed product risks
5.3 – 5.5
FL-5.3.1K1Recall metrics used for testing
FL-5.3.2K2Summarize the purposes, content, and audiences for test reports
FL-5.3.3K2Exemplify how to communicate the status of testing
FL-5.4.1K2Summarize how configuration management supports testing
FL-5.5.1K3Prepare a defect report
K-level legend
| Level | Verb | What the exam asks |
|---|---|---|
| K1 | Remember / Recall | "Which of the following is a metric used in testing?" |
| K2 | Understand / Explain | "Which statement BEST describes…?" |
| K3 | Apply / Use | Scenario — choose the correct action or write something |
5.1 Test Planning
5.1.1 Purpose of a test plan
A test plan describes the test objectives, resources and processes for a test project.
- Documents the means and schedule for achieving test objectives
- Helps ensure performed test activities meet established criteria
- Serves as means of communication with team members and stakeholders
- Demonstrates testing will adhere to existing test policy and test strategy (or explains deviations)
Test planning forces testers to confront future challenges: risks, schedules, people, tools, costs, effort.
Typical content of a test plan
| Content area | Examples |
|---|---|
| Context of testing | Test scope, test objectives, test basis |
| Assumptions & constraints | Limitations of the project |
| Stakeholders | Roles, responsibilities, training needs |
| Communication | Forms, frequency, documentation templates |
| Risk register | Product risks, project risks |
| Test approach | Levels, types, techniques, deliverables, entry/exit criteria, independence, metrics, data & environment requirements |
| Budget & schedule | Timelines, milestones, costs |
Full details: ISO/IEC/IEEE 29119-3 standard.
5.1.2 Tester's contribution to planning
Release planning
- Write testable user stories & acceptance criteria
- Participate in project and quality risk analyses
- Estimate test effort for user stories
- Determine test approach
- Plan testing for the release
Iteration planning
- Detailed risk analysis of user stories
- Determine testability of user stories
- Break stories into testing tasks
- Estimate test effort for all tasks
- Identify functional & non-functional aspects
5.1.3 Entry criteria vs exit criteria
Entry criteria — preconditions to START
If not met → activity will be more difficult, time-consuming, costly and riskier.
Typical:
- Resources available (people, tools, environments, test data, budget, time)
- Testware available (test basis, testable requirements, user stories, test cases)
- Initial quality level (e.g., smoke tests passed)
Agile: Definition of Ready
Exit criteria — what must be achieved to STOP
Defined for each test level; differ based on test objectives.
Typical:
- Measures of thoroughness (coverage level, unresolved defects, defect density, failed tests)
- Binary yes/no (planned tests executed, static testing done, all defects reported, regression automated)
Agile: Definition of Done
Running out of time or budget can be valid exit criteria — acceptable if stakeholders have reviewed and accepted the risk to go live.
5.1.4 Estimation techniques
Key rule: decompose large tasks into smaller ones for more accurate estimates. Always make clear to stakeholders that estimates are based on assumptions and subject to error.
| Technique | How it works | Example |
|---|---|---|
| Estimation based on ratios metrics-based |
Use standard ratios from previous projects. Own historical data is the best source. | Dev:test ratio 3:2; dev effort = 600 days → test effort = 400 days |
| Extrapolation metrics-based |
Measure early in current project; approximate remaining effort by extrapolating data using a mathematical model. Suitable for iterative SDLCs. | Extrapolate next iteration's effort as average of last 3 iterations |
| Wideband Delphi expert-based |
Experts estimate independently, share, discuss discrepancies, re-estimate until consensus. | Planning poker (agile variant) — used when little historical data exists |
| Three-point estimation expert-based |
Three estimates: Optimistic (O), Most Likely (M), Pessimistic (P). E = (O + 4M + P) / 6 |
When uncertainty is high and variance matters |
5.1.5 Test case prioritization
| Approach | Logic |
|---|---|
| Risk-based | Highest risk items first — maximizes defect detection where impact is greatest |
| Coverage-based | Maximize coverage quickly (statement, branch, path) |
| Requirement-based | Highest-priority requirements first (as assigned by stakeholders) |
| Activity-based | Most-used / most critical business flows first |
Constraints (dependencies, setup order, environment availability) may affect final ordering.
5.1.6 Test pyramid
- Bottom (widest): Unit tests — many, fast, cheap, isolated, developer-written
- Middle: Integration / service tests — test interaction between components
- Top (narrowest): UI / E2E tests — fewest, slow, costly, test full user journeys
Anti-pattern: "ice cream cone" — too many E2E tests, too few unit tests. Makes the suite slow and brittle.
5.1.7 Testing quadrants
Q1 — Technology-facing, supports team
Unit tests, component tests
Automated · Test levels: component, integration
Developer confidence
Q2 — Business-facing, supports team
Functional tests, story tests, examples, prototypes
Automated or manual · Test levels: integration, system
Validates acceptance criteria
Q3 — Business-facing, critiques product
Exploratory, usability, UAT
Manual · Test levels: system, acceptance
Finds what automation misses
Q4 — Technology-facing, critiques product
Performance, load, security, reliability
Automated tools · Test levels: system, operational
Non-functional quality
Q1 & Q2 support the team (build quality in). Q3 & Q4 critique the product (find problems). Q1 & Q4 are technology-facing. Q2 & Q3 are business-facing.
5.2 Risk Management
Risk definition (5.2.1)
A risk is a potential event, hazard, threat, or situation whose occurrence causes an adverse effect.
Risk likelihood
Probability of the risk occurring.
Always greater than 0 and less than 1.
Risk impact (harm)
Consequences if the risk occurs — damage or loss that results.
Risk Level = Likelihood × Impact
The higher the risk level, the more important its treatment.
Main risk management activities:
Risk analysis
Risk identification + risk assessment
Risk control
Risk mitigation + risk monitoring
Risk-based testing = test approach where activities are selected, prioritized and managed based on risk analysis and risk control.
5.2.2 Project risks vs product risks
| Project risks | Product risks |
|---|---|
| Affect project management & control | Affect product quality characteristics (ISO 25010) |
| Impact: schedule, budget, scope | Impact: user satisfaction, revenue, safety |
| Organizational: delays, inaccurate estimates, cost cutting | Missing or wrong functionality |
| People: insufficient skills, conflicts, staff shortage | Incorrect calculations, runtime errors |
| Technical: scope creep, poor tool support | Poor architecture, inefficient algorithms |
| Supplier: third-party delivery failure, bankruptcy | Inadequate response time, poor UX |
| Security vulnerabilities |
Consequences of product risks: user dissatisfaction · loss of revenue/trust/reputation · damage to third parties · high maintenance costs / help-desk overload · criminal penalties · physical damage, injuries or death (extreme cases)
5.2.3 Product risk analysis
Goal: provide awareness of product risk to focus test effort in a way that minimizes residual product risk. Ideally begins early in the SDLC.
Risk identification
Generate a comprehensive list of risks.
Techniques: brainstorming, workshops, interviews, cause-effect diagrams.
Involves all relevant stakeholders.
Risk assessment
For each risk: categorize → determine likelihood → determine impact → calculate risk level → prioritize → propose handling.
Can be quantitative (likelihood × impact) or qualitative (risk matrix) or mixed.
Categorization helps assign mitigation — risks in the same category can usually be mitigated using a similar approach.
Results of product risk analysis are used to:
- Determine the test scope to be carried out
- Determine the particular test levels and propose test types to be performed
- Determine the test techniques to employ and coverage to be achieved
- Estimate the test effort required for each task
- Prioritize testing to find critical defects as early as possible
- Determine whether additional activities beyond testing could reduce risk
5.2.4 Product risk control
All measures taken in response to identified and assessed product risks.
| Response option | Meaning |
|---|---|
| Risk mitigation by testing | Test more thoroughly to find defects and reduce likelihood of release with defects |
| Risk acceptance | Acknowledge and proceed without specific mitigation |
| Risk transfer | Transfer consequence to a third party (insurance, outsourcing) |
| Contingency plan | Prepare a plan to deal with the risk if it does occur |
Mitigation actions by testing:
- Select testers with the right level of experience and skills for a given risk type
- Apply an appropriate level of independence of testing
- Perform reviews and static analysis
- Apply appropriate test techniques and coverage levels
- Apply appropriate test types addressing the affected quality characteristics
- Perform dynamic testing, including regression testing
Risk monitoring goal: ensure mitigation is effective; obtain further info to improve assessment; identify emerging risks.
Exam scenario guide
| Scenario | Risk type |
|---|---|
| Key developer left the team | Project risk (people) |
| Payment module crashes under load | Product risk (performance) |
| Third-party vendor may go bankrupt | Project risk (supplier) |
| Login page has SQL injection vulnerability | Product risk (security) |
| Budget was cut by 20% | Project risk (organizational) |
| Calculation produces wrong results | Product risk (functional) |
5.3 Test Monitoring, Control & Completion
Three activities — precise definitions
Test monitoring
Gathering information to assess test progress and measure whether exit criteria are satisfied (coverage of product risks, requirements, or acceptance criteria).
Test control
Uses monitoring info to provide control directives — guidance and corrective actions to achieve the most effective and efficient testing.
Test completion
Collects data to consolidate experience, testware, and relevant information at project milestones.
Control directives (syllabus examples):
- Reprioritizing tests when an identified risk becomes an issue
- Re-evaluating whether a test item meets entry or exit criteria due to rework
- Adjusting the test schedule to address a delay in delivery of the test environment
- Adding new resources when and where needed
Test completion occurs at milestones:
Test level completed · Agile iteration finished · Test project completed or cancelled · Software system released · Maintenance release completed
5.3.1 Seven metric categories (K1 — recall all)
| Category | Examples |
|---|---|
| Project progress | Task completion, resource usage, test effort |
| Test progress | Test case implementation progress, environment preparation, test cases run/not run/passed/failed, execution time |
| Product quality | Availability, response time, mean time to failure (MTBF) |
| Defect | Number and priorities of defects found/fixed, defect density, defect detection percentage |
| Risk | Residual risk level |
| Coverage | Requirements coverage, code coverage |
| Cost | Cost of testing, organizational cost of quality |
Memory aid: P · T · P · D · R · C · C — Project, Test progress, Product quality, Defect, Risk, Coverage, Cost
5.3.2 Test reports
Test progress report
Generated regularly (daily, weekly) during testing.
Supports ongoing test control.
Audience: team — often frequent and informal.
Content:
- Testing period
- Test progress (ahead/behind schedule, notable deviations)
- Impediments and workarounds
- Test metrics
- New and changed risks within period
- Testing planned for next period
Test completion report
Produced once per phase/release when exit criteria ideally met.
Follows a set template.
Standard: ISO/IEC/IEEE 29119-3.
Content:
- Test summary
- Quality evaluation vs original test plan (objectives & exit criteria)
- Deviations from plan (schedule, duration, effort)
- Impediments and workarounds
- Test metrics (based on progress reports)
- Unmitigated risks, defects not fixed
- Lessons learned
5.3.3 Communication options (syllabus list)
| Option | Notes |
|---|---|
| Verbal communication | With team members and stakeholders — stand-ups, meetings |
| Dashboards | CI/CD dashboards, task boards, burn-down charts |
| Electronic channels | Email, chat (Slack, Teams) |
| Online documentation | Wikis, shared docs, test management tools |
| Formal test reports | Progress and completion reports (section 5.3.2) |
More formal communication is more appropriate for distributed teams where face-to-face communication is not always possible.
Exam tip — identify the activity:
Tester checks execution counts vs targets → test monitoring
Manager adds two more testers because team is behind → test control
Team writes up coverage and lessons learned at release end → test completion
Tester checks execution counts vs targets → test monitoring
Manager adds two more testers because team is behind → test control
Team writes up coverage and lessons learned at release end → test completion
5.4 Configuration Management
What CM provides in testing
CM provides a discipline for identifying, controlling, and tracking work products as configuration items.
Work products tracked (configuration items):
Test plansTest strategiesTest conditionsTest casesTest scriptsTest resultsTest logsTest reports
Baselines and change control
- For a complex item (e.g., test environment), CM records the items it consists of, their relationships, and versions
- When a configuration item is approved for testing, it becomes a baseline
- A baseline can only be changed through a formal change control process
- CM keeps a record of changed items when a new baseline is created
- Possible to revert to a previous baseline to reproduce previous test results
How CM supports testing (K2)
- All configuration items are uniquely identified, version controlled, tracked for changes, and related to other items so traceability is maintained throughout the test process
- All documentation and software items are referenced unambiguously in testware
In CI/CD DevOps pipelines, automated CM is normally included as part of the automated pipeline.
Key CM terms:
| Term | Meaning |
|---|---|
| Configuration item | Any work product managed under CM |
| Baseline | Approved snapshot — the "official" version at a point in time |
| Change control | Formal process required to change a baselined item |
| Traceability | Ability to link test items back to requirements, test cases, defects, builds |
5.5 Defect Management
Purpose of defect management
- Provide sufficient information to resolve the issue
- Provide a means of tracking the quality of the work product
- Provide ideas for improvement of the development and test process
Reported anomalies may turn out to be real defects, a false-positive result, or a change request — resolved during the process. Anomalies can be reported in any SDLC phase.
Defect workflow:
Log anomaly→
Analyze & classify→
Decide response(fix or keep)→
Close report
Process must be followed by all involved stakeholders. Static testing defects should be handled the same way.
Defect report — all fields (K3 — be ready to write one)
auto = may be auto-populated by defect management tools
Unique identifier autoSystem-generated reference (e.g., BUG-1042)
Title / summaryShort summary of the anomaly being reported
Date autoWhen the anomaly was observed; plus issuing organization and author including their role
Test object & environmentIdentification of the test object and the test environment used
Context of defectTest case being run, test activity, SDLC phase, test technique, checklist, test data being used
Description of failureEnables reproduction and resolution — test steps that detected the anomaly, plus test logs, database dumps, screenshots or recordings
Expected resultWhat should have happened per requirements
Actual resultWhat actually happened (the observed failure)
SeverityDegree of impact on the interests of stakeholders or requirements (technical — set by tester)
Priority to fixHow urgently it must be fixed (business decision — set by product owner)
Status autoOpen · Deferred · Duplicate · Waiting to be fixed · Awaiting confirmation testing · Re-opened · Closed · Rejected
ReferencesLinks to the test case, requirement, or other related items
Standard: ISO/IEC/IEEE 29119-3 — refers to defect reports as incident reports.
Severity vs priority — exam trap
| Severity | Priority | |
|---|---|---|
| Definition | Degree of impact on interests of stakeholders or requirements | How urgently the defect must be fixed |
| Set by | Tester / developer | Product owner / business stakeholder |
| Example 1 | LOW — cosmetic typo on homepage | HIGH — visible to all users, brand impact |
| Example 2 | HIGH — crash in rarely-used admin screen | LOW — affects very few users |
All 26 keywords — quick reference
| Term | Definition |
|---|---|
| risk | A potential event, hazard, threat, or situation whose occurrence causes an adverse effect |
| risk level | Measure of a risk = likelihood × impact; the higher, the more important its treatment |
| risk likelihood | Probability of risk occurrence (always >0 and <1) |
| risk analysis | Risk identification + risk assessment |
| risk assessment | Categorize, determine likelihood/impact/level, prioritize, propose handling |
| risk identification | Generating a comprehensive list of risks using brainstorming, workshops, interviews, etc. |
| risk management | Risk analysis + risk control (mitigation + monitoring) |
| risk mitigation | Implementing actions to reduce the risk level |
| risk monitoring | Ensuring mitigation is effective; identifying emerging risks |
| risk control | Risk mitigation + risk monitoring |
| risk-based testing | Test approach where activities are selected, prioritized, and managed based on risk analysis and control |
| product risk | Risk related to product quality characteristics (ISO 25010) |
| project risk | Risk related to project management and control (organizational, people, technical, supplier) |
| test plan | Document describing objectives, resources, and processes for a test project |
| test planning | Activity of creating and maintaining a test plan |
| test strategy | High-level organizational description of test levels and testing within those levels |
| test approach | Implementation of the test strategy for a specific project |
| entry criteria | Preconditions that must be met before a given activity can begin |
| exit criteria | Conditions that must be achieved to declare an activity completed |
| test monitoring | Ongoing gathering and analysis of data to assess progress against the test plan |
| test control | Corrective actions (control directives) taken when actual progress deviates from plan |
| test progress report | Regular report during testing supporting ongoing test control |
| test completion report | Summary report produced at end of a test phase documenting results, residual risks, lessons learned |
| test pyramid | Model showing unit tests most numerous and fastest; E2E tests fewest and slowest |
| testing quadrants | Framework (Q1–Q4) categorizing tests across business/technology-facing and support/critique axes |
| defect management | Process for handling anomalies from discovery to closure, including classification and workflow |
| defect report | Documentation of an anomaly with sufficient info to reproduce and resolve it (called "incident report" in ISO 29119-3) |