Publication Information {.unnumbered}

Title: ISTQB Certified Tester Foundation Level (CTFL v4.0)
Subtitle: Complete Study Guide and Certification Preparation Manual
Author: AI Generated Study Manual
Version: 1.1, aligned to the English CTFL Syllabus v4.0.1
Date generated: 29 September 2026

This independent study manual teaches the knowledge areas in the ISTQB Certified Tester Foundation Level v4.0.1 syllabus. It is not an official ISTQB publication and does not reproduce live examination questions. ISTQB and related marks are the property of their respective owners. Always confirm administrative rules with the examination provider through which you book.

How to Use This Manual

Read Chapters 1 to 6 in order on the first pass. On the second pass, work every exercise without looking at its solution. Use the glossary and memory aids for spaced repetition, then sit the 100-question mock examination under timed conditions. Finish with the rapid revision and exam-strategy sections. The official syllabus remains the controlling source when terminology differs between employers.

Table of Contents

The PDF contains a generated, clickable table of contents. Its major divisions are:

1. Introduction and official resources
2. Fundamentals of Testing
3. Testing Throughout the Software Development Lifecycle
4. Static Testing
5. Test Analysis and Design
6. Managing the Test Activities
7. Tool Support for Testing
8. ISTQB Glossary Study Guide
9. Memory Aids, Flashcards, Formula Sheet, and Quick Revision
10. Recommended Video Learning Path, Watch Order, Highest-ROI List, and LO Traceability
11. 100-Question Mock Examination, Answer Key, and Detailed Explanations
12. Last-Minute Revision Guide
13. Final Exam Strategy Guide

Introduction {.unnumbered}

What ISTQB Is

The International Software Testing Qualifications Board (ISTQB) is a not-for-profit association that maintains an internationally used certification scheme for software testing. National and regional member boards or recognised exam providers administer examinations using common syllabi, learning objectives, terminology, and examination structures. This common body of knowledge lets testers, developers, analysts, managers, and customers discuss testing with a shared vocabulary.

ISTQB certification demonstrates knowledge; it does not, by itself, prove years of practical competence. A strong practitioner combines the vocabulary and techniques in this manual with judgement, domain knowledge, communication skill, and repeated experience on real products.

What CTFL Certification Is

The Certified Tester Foundation Level (CTFL) is the entry qualification in the ISTQB scheme. Version 4.0 integrates testing in sequential, iterative, incremental, Agile, DevOps, and continuous-delivery contexts. It covers the fundamentals of testing, testing across the lifecycle, static testing, test techniques, management of test activities, and tool support.

The certificate has no prerequisite. It is suitable for testers, test analysts, test engineers, developers, business analysts, product owners, project managers, quality professionals, user acceptance testers, and anyone who needs a disciplined understanding of software testing.

Examination Format

The standard CTFL examination contains 40 multiple-choice questions worth a total of 40 points. The pass mark is 65%, which means at least 26 points. The normal duration is 60 minutes. Candidates taking an examination in a language that is not their native language may qualify for a 25% time extension, commonly giving 75 minutes, subject to the provider's rules. Questions may assess recall (K1), understanding (K2), or application (K3). K3 questions often require a small calculation, classification, or choice of test cases.

Treat provider-specific delivery details, permitted identification, remote-proctoring rules, rescheduling policy, and language allowance as administrative facts to verify before the examination.

Recommended Study Approach

1. Map the syllabus. Know the six chapters and the purpose of each learning objective.
2. Learn precise distinctions. Many distractors are plausible statements attached to the wrong term—for example, confusing confirmation testing with regression testing.
3. Practise application. Calculate coverage, derive partitions and boundaries, build decision tables, and follow state transitions.
4. Explain aloud. If you can explain why each wrong option is wrong, your understanding is exam-ready.
5. Use timed practice. Complete official sample examinations and this manual's mock exam without notes.
6. Review errors by cause. Categorise each miss as terminology, calculation, careless reading, or knowledge gap.

Exam tip: The exam tests the syllabus meaning of a term, not a company's local usage. When your workplace vocabulary differs, answer according to ISTQB.

Official Resources {.unnumbered}

The following links were current when this manual was generated:

1. Official ISTQB CTFL v4.0.1 Syllabus — the controlling source for learning objectives, keywords, scope, and examinable content.
2. Official CTFL v4.0 page and Sample Exams A-D — current question papers, answer papers, and exam-structure downloads.
3. Official ISTQB Glossary — canonical definitions and a searchable glossary interface.
4. ASTQB Foundation Level Resources — syllabus, exam-format guidance, and additional Foundation Level practice resources from the U.S. member board.
5. GASQ ISTQB Downloads — syllabus and examination-related downloads from an exam provider.
6. ISTQB Downloads — central download area for syllabi, sample examinations, rules, and supporting documents.

Use the official syllabus to resolve wording disputes. Use official sample exams to learn question style rather than memorising answers. Use the glossary to check exact meanings and relationships between terms.

Chapter 1: Fundamentals of Testing

1.1 What Testing Is and Why It Is Necessary

Software testing is a set of activities used to discover defects and evaluate the quality of software work products. It includes static testing, where work products are examined without executing the code, and dynamic testing, where the software is executed. Testing is not merely running test cases: it includes planning, analysing the test basis, designing tests, implementing testware, executing tests, recording results, evaluating completion, and communicating information.

Software can cause financial loss, injury, operational disruption, legal exposure, reputational damage, or simple frustration. Human beings make errors. An error may introduce a defect into a requirement, design, code item, test case, or configuration. When executed under particular conditions, a defect may cause a failure—observable behaviour that differs from expectation. Some failures are caused by environmental conditions rather than a software defect; for example, radiation or network interruption can corrupt execution.

Running example

A banking requirement says that transfers above R50,000 require two approvals. An analyst accidentally writes R500,000 in the specification: that is an error. The incorrect threshold in the specification and code is a defect. A R75,000 transfer being released after one approval is a failure. The underlying organisational cause might be ambiguous review ownership or an unreadable requirements template; addressing that underlying cause is root cause analysis.

Testing contributes to success by detecting defects, reducing the risk of failures, verifying that specified requirements have been met, validating that the product satisfies user needs, and providing information for decisions. Testing cannot prove that a non-trivial system contains no defects. It can increase confidence, expose known weaknesses, and provide evidence about risk.

Exam focus: Testing includes both verification and validation. Verification asks whether the work product meets specified requirements; validation asks whether the product supports stakeholder needs in its operational environment.

Common mistakes

• Saying testing proves correctness. It provides evidence; exhaustive proof is normally impossible.
• Treating a failure as identical to a defect. A failure is observed behaviour; the defect is a cause within a work product.
• Assuming every defect causes a failure every time. A defect may be in unreachable code or require a rare condition.
• Treating testing as a phase owned only by testers. Different roles contribute throughout the lifecycle.

1.2 Testing Objectives

Typical test objectives are to:

• evaluate work products such as requirements, user stories, designs, code, and the system;
• trigger failures and find defects;
• achieve required coverage of the test object;
• reduce the risk of inadequate software quality;
• verify compliance with stated requirements, contractual obligations, laws, and standards;
• validate whether the test object is complete and works as stakeholders expect;
• provide information that helps stakeholders make decisions;
• build confidence in the quality of the test object.

Objectives vary by context. A safety-critical controller emphasises risk reduction and regulatory evidence. A prototype may emphasise rapid learning. A maintenance release may emphasise confirmation of fixes and regression risk. Good test planning makes objectives explicit because objectives determine techniques, levels, environments, data, resources, and exit criteria.

Example: For an online checkout, a functional objective might verify tax calculation. A non-functional objective might evaluate response time at 5,000 concurrent users. A compliance objective might verify that card data is not logged. A decision-support objective might provide release stakeholders with residual-risk information.

Exam trap: “Finding every defect” is not a realistic objective. “Preventing defects” can be a legitimate effect of testing activities such as early reviews, but testing still cannot guarantee defect-free software.

1.3 Testing and Quality Assurance

Testing is product-oriented and corrective: it evaluates work products and can reveal failures and defects. Quality assurance (QA) is process-oriented and preventive: it establishes confidence that appropriate processes will produce suitable quality. QA may include defining a development process, auditing adherence, training people, improving templates, and analysing root causes across projects.

They support each other. Test results reveal patterns that QA can address. If repeated defects arise from misunderstood date formats, testing detects examples; root cause analysis may show that the requirements template lacks locale rules; QA can improve the template and review checklist.

1.4 Testing Versus Debugging

Testing and debugging are separate activities. Dynamic testing can reveal a failure. Debugging finds the cause, analyses it, and removes the defect. Developers commonly debug, although responsibilities depend on context. After a defect is fixed, a tester performs confirmation testing to check that the original failure no longer occurs and regression testing to check that the change did not damage previously working areas.

In static testing, a review can directly identify a defect without observing a failure. The author then performs rework. The distinction remains useful: identifying a defect is not the same as correcting it.

Diagnostic sequence

Test execution -> failure observed -> defect report -> debugging -> fix
       -> confirmation test -> regression test -> closure or further work

Example: A search returns no results for names containing an apostrophe. The tester reports the failure. A developer debugs the query-building code and finds incorrect escaping. The original apostrophe test passes after the fix (confirmation). Other search cases are rerun to detect side effects (regression).

1.5 Errors, Defects, Failures, and Root Causes

An error is a human action that produces an incorrect result. A defect is an imperfection or deficiency in a work product. A failure is an event in which a component or system does not perform a required function within specified limits. A root cause is a fundamental reason for a problem whose removal reduces the likelihood of recurrence.

These concepts form a causal chain, but not always a one-to-one chain:

Pressure + ambiguous rule -> human error -> requirement defect -> code defect
                                       -> specific input -> visible failure

One error can create several defects; several defects can combine into one failure; a defect may never be executed; and environmental conditions can produce failures without a software defect. Root cause analysis studies patterns rather than stopping at the immediate code fault. Techniques include the “five whys,” cause-and-effect diagrams, and defect classification.

Worked example: A hospital application displays a dose ten times too high. The code multiplied milligrams by 10 because the developer misunderstood a unit. Immediate defect: wrong conversion factor. Why misunderstood? Requirement used “dose units” without defining the unit. Why not caught? Review checklist lacked unit consistency. Corrective action fixes the factor; preventive action adds explicit units and checklist checks.

1.6 The Seven Testing Principles

Principle 1: Testing shows the presence, not the absence, of defects

Testing can show that defects exist by exposing failures. Passing tests reduce uncertainty only for the conditions covered; they cannot prove the complete absence of defects.

Example: Passing 2,000 browser tests does not prove the application will behave correctly for every browser, dataset, timing, and integration state.

Principle 2: Exhaustive testing is impossible

Testing every combination of inputs and preconditions is normally infeasible. Testers use risk analysis, techniques, and priorities to select a valuable subset.

Example: Ten fields with ten possible values already produce 10 billion combinations before workflows and environments are considered.

Principle 3: Early testing saves time and money

Testing activities should begin as early as possible. Reviewing an ambiguous requirement is cheaper than correcting code, data, documentation, and deployed integrations after release. This supports shift-left, but does not mean late testing disappears.

Principle 4: Defects cluster together

A small number of components often contain a large proportion of discovered defects or cause most operational failures. Historical defect density, complexity, and change frequency can guide additional testing, while avoiding the assumption that other areas are safe.

Principle 5: Tests wear out

If the same tests are repeated unchanged, they become less effective at finding new defects. Tests and test data should be reviewed, extended, or replaced. Repetition remains valuable for regression detection; the principle warns against relying on a stale set as the only testing.

Principle 6: Testing is context dependent

There is no universal test approach. A medical device, mobile game, data migration, and internal report differ in risk, users, technology, regulation, and acceptable evidence.

Principle 7: Absence-of-defects fallacy

Finding and fixing many defects is useless if the product does not meet user needs or business goals. A technically stable system that solves the wrong problem is not a successful product.

Exam trap: “Tests wear out” does not say regression tests should be discarded after one use. It says an unchanged suite eventually finds fewer new defects.

1.7 Test Activities and the Test Process

The syllabus groups the test process into related activities. They may be iterative, overlap, and be tailored to context.

Test planning

Define test objectives and choose an approach that meets constraints. Decide scope, people, environments, techniques, schedule, budget, risks, entry/exit criteria, reporting, and coordination.

Test monitoring and test control

Test monitoring compares actual progress against the plan using information such as coverage, executed tests, defect trends, effort, and residual risk. Test control takes corrective action: reprioritising tests, adding resources, changing scope, or adjusting dates.

Test analysis

Analyse the test basis to identify testable features and define test conditions. Ask “what should be tested?” Evaluate the basis for defects and testability.

Test design

Turn test conditions into test cases, coverage items, test data requirements, and environment requirements. Ask “how will it be tested?” Apply test techniques and identify necessary infrastructure.

Test implementation

Create and organise test procedures, automated scripts, data, suites, and schedules. Establish the environment and confirm readiness. The distinction from design is important: design specifies tests; implementation makes them executable.

Test execution

Run tests, compare actual with expected results, log outcomes, analyse anomalies, report defects, and perform confirmation or regression testing as needed.

Test completion

Assess unresolved defects, archive useful testware, hand over assets, restore environments, close activities, prepare a test completion report, and capture lessons learned.

Planning -----> Monitoring and control (continuous)
   |                         |
   v                         v
Analysis -> Design -> Implementation -> Execution -> Completion
          feedback and iteration may move in either direction

1.8 Testware, Test Basis, and Traceability

Testware is the work product produced during testing. It can include a test plan, risk register, test conditions, test cases, test charters, coverage items, test data, scripts, expected results, execution logs, defect reports, and completion reports. The test basis is the body of knowledge used for analysis and design: requirements, user stories, acceptance criteria, architecture, contracts, laws, models, or code.

Traceability links the test basis to testware, results, and defects. Bidirectional traceability answers both “which tests cover this requirement?” and “why does this test exist?” It supports coverage evaluation, change impact analysis, audit evidence, prioritisation, and reporting.

Traceability has a cost. Capture links that support decisions; avoid producing detailed matrices nobody uses.

1.9 Exit Criteria, Benefits, and Limitations

Exit criteria define measurable conditions used to declare an activity complete. Examples include required coverage achieved, no open critical defects, planned tests executed, residual product risk accepted, or mandatory reports delivered. They inform a decision but do not make it automatically; stakeholders may release with unmet criteria if they explicitly accept risk.

Benefits of testing include earlier feedback, defect detection and prevention, lower failure risk, evidence for decisions, improved shared understanding, and regulatory or contractual confidence. Limitations include incomplete coverage, imperfect oracles, environment differences, time and budget constraints, human bias, flaky automation, and uncertainty about rare conditions.

Worked exercise

A release has executed 980 of 1,000 planned tests, achieved 92% requirement coverage, and has one open critical security defect. Exit criteria require 95% tests executed, 90% requirement coverage, and no open critical defects.

Solution: Execution is 98%, so that criterion passes. Coverage is 92%, so it passes. The critical-defect criterion fails. The test team reports the status and residual risk; the release decision belongs to the authorised stakeholders.

Chapter 1 Review Questions

1. A developer misunderstands a tax rule and writes an incorrect formula. During execution, a customer is overcharged. Identify the error, defect, and failure.
2. Which principle explains why a risk-based sample is needed instead of all combinations?
3. What is the difference between testing and debugging?
4. Give two benefits of traceability.
5. Which activity asks “what should be tested?” and which asks “how should it be tested?”
6. Why can a product pass all planned tests yet still be unsuccessful?
7. Is an unmet exit criterion an automatic prohibition on release?
8. Distinguish QA from testing.

Chapter 1 Answer Key

1. The misunderstanding is the error; the incorrect formula in the work product is the defect; the observed overcharge is the failure.
2. Exhaustive testing is impossible.
3. Testing exposes failures and evaluates quality; debugging locates, analyses, and removes the defect that caused a failure.
4. Examples: coverage evaluation, change impact analysis, audit evidence, test prioritisation, and explaining why a test exists.
5. Test analysis asks what; test design asks how.
6. The absence-of-defects fallacy: it may not meet user or business needs.
7. No. It informs a stakeholder decision and makes residual risk visible.
8. Testing is primarily product-oriented quality control; QA is process-oriented and preventive.

Chapter 2: Testing Throughout the Software Development Lifecycle

2.1 SDLC Overview and the Influence on Testing

A software development lifecycle (SDLC) model describes how development work is organised. Testing must be adapted to the model, but good testing exists in every model. The chosen lifecycle affects the timing and scope of test activities, documentation detail, role distribution, automation, regression frequency, and feedback speed.

Good testing practices across lifecycles include selecting an appropriate test approach, performing test activities at each development stage, beginning analysis early, involving testers in reviews, and maintaining traceability where useful. Every development activity should have a corresponding test activity, and each test level should have specific objectives.

2.2 Sequential Development and the V-Model

In a sequential development model, major phases are completed in order. The waterfall model is the familiar example. Feedback arrives relatively late when executable software becomes available, so defects in early documents may be expensive unless static testing is strong.

The V-model connects each development work product with a corresponding test level. Test analysis and design begin against the relevant basis before execution becomes possible.

Business needs ------------------------------ Acceptance testing
     System requirements ---------------- System testing
          Architecture --------------- Integration testing
               Detailed design ---- Component testing
                         Coding

This diagram expresses relationships, not a rule that each test level starts only after coding. Acceptance tests can be designed from business needs early; component tests can be designed from detailed design.

Example: A payroll project defines acceptance conditions while business requirements are written, system tests while system requirements are refined, interface tests from architecture, and component tests from module design.

Exam trap: The V-model supports early test design; it is not simply “test at the end.”

2.3 Iterative, Incremental, and Agile Development

Incremental development delivers the product in pieces; each increment adds capability. Iterative development revisits and improves a solution through repeated cycles. A project can be both iterative and incremental.

In these models, each iteration may include analysis, design, coding, and testing. Feedback is faster, but repeated integration creates a strong need for automated regression testing, continuous integration, and disciplined configuration management.

Agile software development emphasises frequent delivery, collaboration, responsiveness to change, working software, and a whole-team approach. Testing is integrated into day-to-day development. Testers contribute to refinement, acceptance criteria, risk discussions, exploratory testing, automation, and quality coaching. Independence can still exist through perspective and review even when testing is embedded in one team.

Example: During backlog refinement, a tester challenges an ambiguous refund story, supplies examples for boundaries, and helps write acceptance criteria. During the sprint, developers implement component checks, the team automates acceptance tests, and the tester explores interactions with older promotions.

2.4 DevOps and Continuous Delivery

DevOps promotes shared responsibility and cooperation among development, testing, and operations, supported by automation and rapid feedback. A typical pipeline builds code, performs static analysis, executes tests at several levels, packages a release, deploys to environments, and monitors operation.

Benefits include faster feedback, repeatable environments, earlier detection, frequent regression testing, and operational visibility. Risks include overconfidence in automation, pipeline maintenance cost, slow or flaky suites, security exposure in pipeline credentials, and production-like failures not represented in test environments.

Commit -> Build -> Static checks -> Component tests -> Integration tests
       -> Package -> System checks -> Deploy -> Monitor -> Feedback

Testing within DevOps includes both shift-left and feedback from the right. Shift-left testing moves test activities earlier—for example, reviewing stories, using static analysis at commit time, or designing acceptance tests before implementation. It does not mean all testing happens early. Production monitoring, canary releases, and user analytics provide later evidence.

2.5 Retrospectives and Process Improvement

A retrospective is a meeting in which the team examines what went well, what did not, and what to change. It can identify process improvements, automation opportunities, communication problems, environmental bottlenecks, and effective practices to retain. Actions should be specific, owned, and reviewed.

Example: The team notices that half its failed acceptance tests were caused by unstable test data. It agrees to create versioned data fixtures, assigns an owner, and measures flaky failures during the next iteration.

2.6 Test Levels

A test level is a group of test activities managed together. Levels differ in test object, objectives, test basis, defects/failures, approach, and responsibility.

Component testing

Component testing focuses on separately testable components such as a class, function, module, or service. Objectives include evaluating functional and non-functional behaviour, reducing component risk, and building confidence. The basis may include detailed design, code, data models, and component specifications. It is often performed by developers with frameworks, stubs, drivers, and debugging support.

Example: Test an interest-calculation function with normal, boundary, zero, and invalid rates.

Component integration testing

This tests interfaces and interactions between components. Integration strategy may be incremental. Defects often involve data formats, interface assumptions, sequences, timing, or error handling.

Example: Test the interaction between the checkout service and payment adapter using a controllable payment stub.

System testing

System testing examines the behaviour and capabilities of the complete system or product, including end-to-end tasks and non-functional characteristics. The basis may include system requirements, use cases, risk analyses, and business processes. A representative environment is valuable.

Example: Place an order, pay, reserve inventory, send confirmation, and expose the order in customer history.

System integration testing

This tests interfaces between the system under test and external systems or services. It can occur after or alongside system testing.

Example: Verify that the order platform exchanges correct messages with an external courier and handles timeouts safely.

Acceptance testing

Acceptance testing evaluates readiness for deployment and use by intended users or stakeholders. Forms include user acceptance, operational acceptance, contractual/regulatory acceptance, alpha, and beta testing. Its focus is often validation, business processes, user needs, and operational readiness—not merely repeating system tests.

Example: Operations verifies backup restoration, monitoring alerts, job recovery, user provisioning, and support procedures before go-live.

Exam trap: A test's level is determined by its objective and test object, not by who executes it. A developer can help with system testing; a user can execute a component-level check.

2.7 Test Types

Functional testing

Functional testing evaluates what the test object should do. It derives tests from functions, requirements, business rules, or user stories. It can be performed at every test level.

Non-functional testing

Non-functional testing evaluates how well the system behaves. Relevant quality characteristics include performance efficiency, compatibility, usability, reliability, security, maintainability, portability, and safety where applicable. Non-functional testing should start early; performance risks can influence architecture before code exists.

Black-box testing

Black-box testing derives tests from specifications without using the internal structure as the basis. The tester reasons about inputs, outputs, behaviours, and rules.

White-box testing

White-box testing derives tests from internal structure, such as statements and branches. It measures structural coverage and can expose unexecuted logic.

Change-related testing

Confirmation testing verifies that a defect has been successfully fixed. Regression testing checks whether a change has caused adverse consequences in unchanged or connected areas. Both may be needed after a fix. Regression suites are strong automation candidates because they run repeatedly.

Scenario: A rounding bug in invoices is fixed. Re-run the failing rounding case: confirmation. Test discounts, tax totals, exports, refunds, and reports that share calculation logic: regression.

2.8 Maintenance Testing

Maintenance testing tests changes to an operational system or changes in its environment. Triggers include corrective changes, enhancements, migrations, platform upgrades, infrastructure changes, retirement, archiving, and data conversion.

Impact analysis evaluates the consequences of a change and identifies affected areas and tests. It considers dependencies, interfaces, data, configuration, documentation, and operational processes. Its accuracy depends on good architecture knowledge, configuration management, and traceability.

Maintenance scope is influenced by the degree of change, existing system size, risk, available documentation, and testware quality. A small library upgrade can have broad consequences if many services depend on it.

Worked scenario

A bank upgrades its database engine. Direct confirmation testing verifies corrected compatibility issues. Regression testing covers transaction processing, stored procedures, backups, reporting, monitoring, and failover. Non-functional testing evaluates performance and recovery. Impact analysis identifies applications, drivers, and jobs using the database.

Chapter 2 Review Questions

1. How are iterative and incremental development different?
2. What does the V-model connect?
3. Give two testing benefits and two testing risks of DevOps.
4. What is shift-left testing, and what does it not mean?
5. Distinguish system testing from system integration testing.
6. What determines a test level?
7. Distinguish confirmation and regression testing.
8. Give three maintenance triggers.
9. What is the purpose of impact analysis?

Chapter 2 Answer Key

1. Incremental development adds product pieces; iterative development refines through repeated cycles. They can coexist.
2. Development work products with corresponding test levels and early test activities.
3. Benefits: rapid feedback and repeatability; risks: flaky suites and overconfidence in automation, among others.
4. It moves testing earlier. It does not eliminate later dynamic testing or production feedback.
5. System testing evaluates the whole system; system integration testing evaluates its interfaces with external systems.
6. Its test object, objectives, basis, characteristic defects, approach, and context—not merely the executor.
7. Confirmation checks the fix; regression checks for adverse side effects elsewhere.
8. Defect correction, enhancement, migration, environment upgrade, retirement, or data conversion.
9. To identify consequences, affected areas, risks, and tests required by a change.

Chapter 3: Static Testing

3.1 Static Testing Concepts

Static testing evaluates work products without executing the software. It includes human reviews and tool-supported static analysis. Almost any readable work product can be reviewed: requirements, user stories, acceptance criteria, architecture, code, test cases, contracts, plans, manuals, and infrastructure definitions.

Static testing can directly detect defects, while dynamic testing normally detects failures from which defects are investigated. Static analysis tools can detect certain coding-rule violations, unreachable code, security patterns, complexity, or dependency problems. Reviews can expose ambiguity, inconsistency, omission, inaccuracy, duplication, non-testability, and deviations from standards.

3.2 Value, Benefits, and Cost Savings

Early detection reduces rework because fewer dependent products exist. Finding an ambiguous acceptance criterion before implementation may require a brief conversation; finding it after release may require code correction, data repair, retesting, deployment, support, and customer communication.

Benefits include:

• early defect detection and correction;
• prevention through shared understanding and author learning;
• detection of defects that dynamic execution may not reveal easily;
• improved consistency, maintainability, testability, and development productivity;
• reduced total development cost and time;
• improved communication among participants.

Static testing and dynamic testing complement one another. A review may detect missing requirements, while execution may reveal timing failures that are difficult to infer from documents.

Example: A review discovers that “the report loads quickly” is not measurable. The team replaces it with “95% of reports containing up to 50,000 rows display within four seconds under the defined workload.” The new requirement is testable and guides architecture.

3.3 The Review Process

Review formality depends on risk, goals, lifecycle, regulations, and team culture. A generic review process contains the following activities.

Planning

Define scope, purpose, work products, quality characteristics, review type, participants, schedule, effort, entry/exit criteria, and information to collect. Select reviewers with relevant perspectives.

Review initiation

Distribute the work product and supporting material, explain objectives, roles, process, review techniques, and expected outputs. Confirm that the item is ready and reviewers have access and time.

Individual review

Each reviewer examines the work product, identifies potential anomalies, records questions or defects, and may apply checklists, scenarios, perspective-based reading, or role-based review.

Communication and analysis

Participants discuss anomalies, determine their status and ownership, and decide actions. A meeting is optional for some review types. The goal is to evaluate the product, not the author.

Fixing and reporting

The author performs rework on accepted defects. Results, metrics, decisions, and new risks are recorded as appropriate.

Follow-up

Check that agreed actions are completed, exit criteria are met, and the review can close. The moderator may collect data for improvement.

Plan -> Initiate -> Individual review -> Communicate/analyse
                                  -> Rework -> Follow-up and close

3.4 Review Roles

One person may hold several roles in a lightweight review. Independence and diverse perspectives improve defect detection, but excessive formality can reduce speed and participation.

Exam trap: The author fixes defects. The moderator facilitates; the moderator does not automatically own the corrections.

3.5 Review Types

Informal review

An informal review has no defined process and may produce little documentation. A colleague reading a user story or pair programming are examples. It is quick and inexpensive but depends heavily on the participants.

Walkthrough

A walkthrough is led by the author. Objectives may include finding defects, evaluating quality, building confidence, generating ideas, and educating participants. Preparation may be individual, but it can be limited. The author guides participants through the work product.

Technical review

A technical review is performed by technically qualified reviewers and is typically led by a moderator. It may aim to find defects, evaluate quality, build confidence, gain consensus, and make technical decisions. It is more formal than a walkthrough but less prescribed than an inspection.

Inspection

An inspection is the most formal review type. It follows a defined process with specified roles, entry and exit criteria, individual preparation, documented defects, and metrics. The author should not act as review leader or scribe where that compromises objectivity. Inspections support process improvement as well as defect detection.

3.6 Factors for Review Success

Successful reviews have clear objectives, appropriate work-product size, suitable review type, adequate preparation time, trained participants, management support, constructive communication, and a culture that treats defects as information rather than blame. Review small portions at a sustainable pace. Track useful metrics, not metrics that punish authors or reviewers.

Scenario: A security architecture review includes an architect, security specialist, tester, operations engineer, and developer. Each uses a perspective-specific checklist. The moderator limits scope to authentication and session management. Findings are prioritised, assigned, corrected, and verified.

3.7 Worked Review Exercise

Requirement: “Registered customers may reset a forgotten password quickly. A reset link should usually expire, and the new password must be strong.”

Potential review findings:

• “quickly” is ambiguous and non-measurable;
• “usually expire” does not define conditions or duration;
• “strong” lacks password rules;
• no rule for single use, throttling, account enumeration, or audit;
• unclear behaviour when several reset links exist;
• missing accessibility and notification expectations.

The exercise demonstrates why static review prevents entire families of later defects.

Chapter 3 Review Questions

1. What is the essential difference between static and dynamic testing?
2. Name four types of work product suitable for review.
3. Put the generic review activities in order.
4. Who performs rework? Who normally facilitates the review?
5. Which review type is led by the author?
6. Which review type is most formal and normally collects metrics?
7. Why can static testing reduce cost?
8. Give two cultural factors that improve review success.

Chapter 3 Answer Key

1. Static testing does not execute the software; dynamic testing does.
2. Any four of requirements, stories, design, code, tests, plans, contracts, manuals, or infrastructure definitions.
3. Planning, initiation, individual review, communication/analysis, fixing/reporting, and follow-up.
4. The author performs rework; the moderator facilitates.
5. Walkthrough.
6. Inspection.
7. Defects are found before dependent work products multiply the rework.
8. Psychological safety, constructive feedback, management support, adequate preparation time, trained participants, and clear objectives.

Chapter 4: Test Analysis and Design

This chapter contains the techniques most likely to require application and calculation. A test technique is a systematic way to derive test conditions, coverage items, and test cases. Techniques improve selection; they do not mechanically guarantee good tests. Combine specification-based, structure-based, experience-based, and collaboration-based perspectives.

4.1 Black-Box Testing Techniques

4.1.1 Equivalence Partitioning

Equivalence partitioning (EP) divides data into equivalence partitions whose values are expected to be processed similarly. One representative from a partition may reveal defects affecting the whole partition. Partitions must be non-empty, disjoint for the characteristic being modelled, and together cover the relevant domain. Partitions can be valid or invalid.

Method

1. Identify the input or output domain and the relevant rule.
2. Divide it into partitions with expected common behaviour.
3. Identify valid and invalid partitions.
4. Select at least one representative from every partition needed by the coverage objective.
5. Add combinations deliberately when several inputs interact; do not assume one-dimensional EP covers interactions.

Worked example 1: age rule

A membership form accepts ages 18 through 65 inclusive.

Minimum tests for 100% partition coverage: {17, 40, 66}. Values 18 and 65 are important boundaries but are not required merely to cover EP.

Worked example 2: enumerated and malformed values

A shipping field permits STANDARD, EXPRESS, or COLLECT.

• valid partition: each listed value may need separate treatment if behaviour differs;
• invalid partition: unsupported but syntactically valid strings such as DRONE;
• invalid partition: blank or null if mandatory;
• invalid partition: malformed type or excessively long input where relevant.

Do not combine values into one partition merely because all are valid. Values belong together only if the system is expected to handle them in the same way for the testing objective.

Exercise 4.1

A discount accepts order quantities from 1 to 99. Quantities 1–9 receive no discount, 10–49 receive 5%, and 50–99 receive 10%. Other integers are rejected. Identify partitions and a minimal representative set.

Solution: Invalid <1; valid 1–9; valid 10–49; valid 50–99; invalid >99. Representatives could be {0, 5, 20, 70, 100}. Five tests achieve one-dimensional 100% EP coverage.

Exam trap: A boundary is not an equivalence partition. EP asks which groups behave alike; BVA asks where behaviour may change.

4.1.2 Boundary Value Analysis

Boundary value analysis (BVA) tests values at the edges of ordered partitions because defects often occur there. It applies where values have an order: numbers, dates, lengths, counts, or ordered states.

In CTFL v4.0, know 2-value BVA and 3-value BVA. For each boundary:

• 2-value BVA covers the boundary value on each adjacent side of the boundary. For a valid range, this commonly produces the first value in the partition and its immediate neighbour outside.
• 3-value BVA covers the boundary value and both immediate neighbours.

For the inclusive range 18–65:

For adjacent business bands such as 0–99 and 100–499, boundaries occur at 0, 99/100, and 499/500 relative to the specified domain. Draw the number line before counting.

invalid       valid 18........................65       invalid
--------17 | 18 19 ---------------------- 64 65 | 66--------

Worked example: password length

Passwords of length 8 through 20 inclusive are accepted.

• 2-value BVA: lengths 7, 8, 20, 21.
• 3-value BVA: lengths 7, 8, 9, 19, 20, 21.

The character content can be held constant so that the test isolates length.

Exercise 4.2

A booking permits 1–6 passengers inclusive. Give 2-value and 3-value BVA sets.

Solution: 2-value: {0,1,6,7}. 3-value: {0,1,2,5,6,7}.

Exercise 4.3

A field accepts integer scores 0–100 inclusive, with classifications fail 0–49 and pass 50–100. Identify important boundaries and a 2-value set.

Solution: Domain boundaries at 0 and 100; classification change between 49 and 50. A suitable set is {-1,0,49,50,100,101}. Depending on how boundary coverage is defined for the model, include the pairs bracketing each change.

Common mistake: Selecting only valid endpoints. BVA is especially valuable across the valid/invalid boundary.

4.1.3 Decision Table Testing

Decision table testing models combinations of conditions and resulting actions. It is useful for business rules where several conditions interact. A column is a rule representing one combination. Limited-entry tables use Boolean conditions; extended-entry tables allow ranges or sets.

Construction process

1. List relevant conditions.
2. List possible actions or outcomes.
3. Enumerate condition combinations.
4. Determine the action for each combination from the specification.
5. Identify impossible or irrelevant combinations.
6. Simplify columns only when the differing condition cannot affect the action; mark it “-” (don't care).
7. Create at least one test for each feasible rule required by coverage.

Worked example: loan pre-check

A loan is automatically approved when identity is verified and either the credit score is good or an existing-customer override applies. Otherwise it is referred; unverified identity is rejected.

R1 and R2 are actually duplicates once both other conditions are don't-care; simplify them to one rule. The final table has four meaningful rules: unverified -> reject; verified plus good credit -> approve; verified, poor credit, override -> approve; verified, poor credit, no override -> refer.

Coverage: Decision-table coverage is commonly measured as exercised feasible rules divided by total feasible rules. One test per rule achieves 100% rule coverage.

Exercise 4.4

An account login succeeds when credentials are valid and the account is active. If credentials are invalid, show “invalid credentials” regardless of account state. If credentials are valid but the account is inactive, show “account locked.” Construct a simplified table.

Solution:

Exam trap: A dash means “the value does not affect the action for this rule,” not “unknown” or “not tested.”

4.1.4 State Transition Testing

State transition testing models a system whose response depends on its current state and an event. A transition moves from one state to another and may produce an action. The same event can lead to different outcomes in different states.

Common coverage criteria include valid transitions coverage and, when specified, attempts of invalid transitions. A state table is often easier to count than a diagram.

Worked example: account lock

An account begins Active with zero failed attempts. Each invalid password increments the failure count. After the third consecutive failure it becomes Locked. A successful login resets the count. An administrator can unlock a Locked account.

[Active,0] --bad--> [Active,1] --bad--> [Active,2] --bad--> [Locked]
     ^                    |                   |
     |------good----------|------good---------|
     |                                        |
     +-------------- admin unlock ------------+

Possible tests include the full lock path, successful reset after one or two failures, unlock, and invalid events such as attempting a normal login while locked if the specification forbids it.

Transition table

Exercise 4.5

A document can be Draft, Submitted, Approved, or Rejected. Submit moves Draft to Submitted. Approve moves Submitted to Approved. Reject moves Submitted to Rejected. Edit moves Rejected to Draft. Design a shortest sequence that covers every valid transition at least once, allowing a new document when necessary.

Solution: One sequence is Draft -> Submitted -> Rejected -> Draft -> Submitted -> Approved, using Submit, Reject, Edit, Submit, Approve. It covers all five valid transitions without creating a second document.

Common mistake: Counting states when the question asks for transitions. Visiting every state does not necessarily exercise every transition.

4.1.5 Use Case Testing

Use case testing derives tests from interactions between an actor and a system to achieve a goal. Although use-case testing is broader than the core CTFL v4.0 black-box technique list, it is useful for end-to-end and acceptance scenarios.

A use case normally contains preconditions, trigger, main success scenario, alternate flows, exception flows, postconditions, and business rules. Tests should cover the main flow plus meaningful alternatives and exceptions.

Example: withdraw cash

• Preconditions: valid card, ATM online, account available.
• Main flow: insert card, authenticate, select amount, authorise, dispense, debit, return card.
• Alternatives: receipt declined, another amount selected.
• Exceptions: wrong PIN, insufficient funds, cash unavailable, network timeout, card retained.

An end-to-end test that covers only the happy path is incomplete. Use cases reveal sequence and actor interaction but may need EP/BVA for detailed data and decision tables for rule combinations.

4.2 White-Box Testing

White-box testing derives coverage from internal structure. At Foundation Level, focus on statement testing and branch testing. Coverage tells you what structure was executed, not whether the assertions were strong or requirements were correct.

4.2.1 Statement Testing and Coverage

A statement is an executable instruction. Statement coverage is:

[ \text{Statement coverage} = \frac{\text{number of statements executed}}{\text{total executable statements}} \times 100% ]

Consider:

1 total = price * quantity
2 if total > 1000:
3     discount = total * 0.10
4 else:
5     discount = 0
6 payable = total - discount

Ignoring the control keywords as separate statements, suppose executable statements are 1, 3, 5, and 6. A test with total=1500 executes 1, 3, and 6: 3/4 = 75%. Adding a test with total=500 executes statement 5, making coverage 4/4 = 100%.

Important: The exact statement count in an exam question follows the given model or code representation. Do not invent hidden compiler behaviour.

4.2.2 Branch Testing and Coverage

A branch is a transfer of control between nodes in a control-flow graph. For a decision with true and false outcomes, both outcomes are branches. Branch coverage is:

[ \text{Branch coverage} = \frac{\text{number of branches executed}}{\text{total branches}} \times 100% ]

For one if statement with true and false outcomes, a single test normally covers one of two branches = 50%; tests causing both outcomes achieve 100%.

Worked example

if member:
    apply_member_discount()
if total > 500:
    free_delivery()
send_confirmation()

There are four decision outcomes: member true/false and total>500 true/false. Test A (member=true,total=700) covers two true branches. Test B (member=false,total=300) covers two false branches. Together they achieve 4/4 = 100% branch coverage and execute every statement.

4.2.3 Coverage Comparison

100% branch coverage subsumes 100% statement coverage: exercising every branch executes every reachable statement. The reverse is not guaranteed. A test can execute every statement without taking every decision outcome, especially where an if has no else body containing a unique statement.

if x > 0:
    y = 1
print(y)

A positive x executes every statement but only the true branch. Thus statement coverage may be 100% while branch coverage is 50%.

Neither criterion proves absence of defects. They do not ensure all data combinations, paths, requirements, or missing functions are tested.

Exercise 4.6

A module contains 80 executable statements. A suite executes 68. Calculate statement coverage.

Solution: 68 / 80 x 100 = 85%.

Exercise 4.7

A control-flow model contains 12 branches. Eight were executed. How many additional previously unexecuted branches must be covered to reach at least 90%?

Solution: 90% of 12 is 10.8, so at least 11 branches must be covered. Three additional branches are required.

4.3 Experience-Based Testing

Error guessing

Error guessing uses tester knowledge to anticipate defects, failures, and error-prone situations. Sources include past failures, common developer mistakes, production incidents, technology weaknesses, and domain knowledge.

Examples: divide by zero, blank values, duplicate submission, clock changes, expired sessions, special characters, interrupted networks, incorrect permissions, and overflow. Error guessing is systematic when defect taxonomies and lessons learned are recorded.

Checklist-based testing

Checklist-based testing uses a high-level list of conditions, risks, quality characteristics, or common failures. A good checklist is concise, maintained, and tailored. It guides attention without dictating exact steps.

Example security checklist items: authentication required, authorisation enforced server-side, secrets not logged, sessions expire, errors do not expose internal details, and input is validated.

Exploratory testing

Exploratory testing combines learning, test design, and execution. The tester adapts tests based on observations. A test charter provides mission, scope, risks, and constraints; time-boxed sessions, notes, and debriefs add discipline.

Example charter: “Explore refund cancellation for concurrent actions, focusing on duplicate financial postings, stale status, and audit evidence, for 60 minutes.” The tester models behaviour while testing and follows promising findings.

Exam trap: Exploratory testing is not random clicking. It is a skilled, evidence-producing approach with a mission and continuous learning.

4.4 Collaboration-Based Test Approaches

Collaborative user-story writing

User stories encourage conversation. A common pattern is “As a [role], I want [capability], so that [benefit].” Good stories are supported by examples and acceptance criteria. The 3 Cs are Card, Conversation, and Confirmation.

Acceptance Test-Driven Development

In acceptance test-driven development (ATDD), team members collaboratively derive acceptance tests from acceptance criteria before implementation. Tests provide shared examples, guide development, and later support regression checking.

Behaviour-Driven Development overview

Behaviour-driven development (BDD) expresses examples in business-readable scenarios, often using Given-When-Then:

Given an active customer with a balance of R1,000
When the customer transfers R200
Then the balance is R800
And an audit entry records the transfer

Given describes context, When describes an event, and Then describes observable outcomes. BDD is a collaboration and discovery practice; a syntax tool alone does not create shared understanding.

Three Amigos

The Three Amigos is a collaborative discussion among business, development, and testing perspectives. It clarifies examples, risks, acceptance criteria, and testability before implementation. It need not be exactly three people; the point is complementary perspectives.

Worked collaboration exercise

Story: “As a customer, I want to cancel an order.” Questions reveal missing rules: cutoff time, shipped orders, refunds, partial orders, permissions, notifications, retries, and audit. The team turns examples into acceptance tests before coding. This is defect prevention through collaboration.

4.5 Integrated Technique Selection

Real tests often combine techniques. For a locked account, use state transitions for attempt history, BVA for password length, decision tables for MFA rules, branch coverage for component code, and exploratory testing for concurrent sessions.

Chapter 4 Review Questions

1. A field accepts integers 10–20 inclusive. State the EP partitions and 2-value BVA set.
2. What does “-” mean in a decision-table condition?
3. Why does visiting all states not guarantee all-transition coverage?
4. Calculate coverage when 45 of 60 statements execute.
5. Does 100% statement coverage imply 100% branch coverage? Explain.
6. Does 100% branch coverage imply complete testing? Explain.
7. Distinguish error guessing, checklist-based testing, and exploratory testing.
8. What is ATDD's timing and purpose?
9. Give a Given-When-Then example.
10. Which technique would you start with for a rule involving customer type, payment status, and delivery country?

Chapter 4 Answer Key

1. <10 invalid, 10–20 valid, >20 invalid; 2-value BVA {9,10,20,21}.
2. The condition is irrelevant to the action for that rule—a don't-care value.
3. Several transitions may connect the same states or remain unused even when each state is visited.
4. 45/60 x 100 = 75%.
5. No. All statements may execute without both outcomes of every decision.
6. No. It covers structural branches, not all data, paths, requirements, environments, or missing functionality.
7. Error guessing predicts defects from expertise; checklists guide checks from a maintained list; exploratory testing learns, designs, and executes dynamically under a mission.
8. Acceptance tests are collaboratively derived before implementation to clarify expected behaviour and guide work.
9. Any correct context-event-observable outcome scenario.
10. Decision table testing, because condition combinations determine actions.

Chapter 5: Managing the Test Activities

5.1 Test Planning

A test plan describes objectives, resources, processes, schedules, scope, approach, and coordination of test activities. Planning is continuous: as risk, progress, and product knowledge change, plans are revised.

Typical planning decisions include test scope and objectives; assumptions and constraints; stakeholders; test levels and types; techniques; entry and exit criteria; environments and data; staffing and training; automation; estimates; schedules; deliverables; reporting; defect handling; configuration management; and risks.

Example test-plan extract: Objective: assess payment release risk. Scope: transfer creation through settlement messages. Approach: risk-based, using decision tables for approval rules, state models for lifecycle, performance tests for peak settlement, and exploratory sessions for recovery. Exit criteria: all critical risk items covered, no open severity-1 defects, and accepted residual risk documented.

5.2 Entry Criteria and Exit Criteria

Entry criteria define preconditions for starting an activity: approved basis, available environment, deployable build, test data, access, and required tools. Exit criteria define completion measures: coverage, executed tests, defect status, risk level, and deliverables.

Criteria reduce ambiguity but require judgement. Starting with unmet entry criteria may be appropriate if the risk of delay is higher and limitations are transparent. Exit criteria support a release recommendation, not an automatic release decision.

5.3 Risk-Based Testing

Risk is the effect of uncertainty on objectives. In testing, the risk level depends on likelihood and impact. A common qualitative or numeric model is:

[ \text{Risk level} = \text{likelihood} \times \text{impact} ]

This formula is a prioritisation aid, not universal physics. Scales must be defined. A 1–5 likelihood and 1–5 impact model yields scores 1–25, but teams must still discuss assumptions.

Product risks and project risks

Product risk concerns the possibility that a work product will fail to satisfy legitimate needs: incorrect calculations, security vulnerabilities, poor performance, data corruption, unusability, or regulatory noncompliance.

Project risk concerns the ability to deliver the project: unavailable specialists, unrealistic estimates, unstable environments, supplier delay, tool failure, scope volatility, or insufficient budget.

Product risk influences what and how intensely to test. Project risk influences how testing work can be delivered.

Risk identification, assessment, analysis, and control

Risk identification finds risks using workshops, checklists, incident history, architecture analysis, stakeholder interviews, and retrospectives. Risk assessment evaluates likelihood and impact. Risk analysis studies causes, consequences, exposure, and priority. Risk control includes risk mitigation and monitoring.

Testing mitigates product risk by reducing uncertainty and detecting defects. Other responses include avoiding the feature, reducing likelihood through design, reducing impact through controls, transferring risk, accepting risk, or preparing contingency plans.

Risk-based testing allocates effort according to risk, selects techniques and coverage, determines order, and communicates residual risk. It does not mean low-risk areas receive no testing.

5.4 Test Estimation

Test estimation predicts effort, duration, cost, or resources. Two broad approaches are:

• Metrics-based estimation, using historical data and ratios. Example: historical execution takes 12 minutes per test case, adjusted for automation and complexity.
• Expert-based estimation, using knowledgeable people. Wideband Delphi gathers independent estimates, discusses assumptions, and repeats until convergence. Planning poker is a collaborative relative-estimation technique.

Estimates should include analysis, design, implementation, data, environment setup, execution, defect investigation, confirmation, regression, reporting, meetings, maintenance, and contingency. Duration is not simply effort divided by people because tasks have dependencies and communication overhead.

Worked estimate: 300 manual tests x 10 minutes = 3,000 minutes = 50 execution hours. Add 20% for evidence and logging = 60 hours. This is execution effort only; it must not be presented as the complete test estimate.

Exam trap: Historical data improves estimates only when the new context is comparable and assumptions are adjusted.

5.5 Prioritising Test Cases

Tests may be prioritised by risk, coverage, requirements priority, dependencies, failure probability, business value, or feedback speed. Common strategies include:

• risk-based prioritisation: execute tests covering highest risk first;
• coverage-based prioritisation: maximise coverage early;
• requirements-based prioritisation: follow stakeholder priority;
• additional-coverage prioritisation: each next test covers the most not-yet-covered items.

Dependencies can override ideal priority. An end-to-end test may require a successful login setup first. Test order should maximise useful early information while respecting prerequisites.

5.6 The Test Pyramid and Testing Quadrants

The test pyramid suggests many fast, focused lower-level automated tests, fewer service/integration tests, and a small number of slower end-to-end tests. It is a heuristic, not a mandatory ratio. Architecture and risk matter.

Agile testing quadrants help discuss tests by whether they support the team or critique the product, and whether they are business-facing or technology-facing. They are a thinking model, not sequential phases.

5.7 Monitoring, Control, Metrics, and Reporting

Test monitoring gathers information and compares actual progress with plan. Test control uses that information to guide corrective actions. Useful test metrics may include:

• preparation and execution status;
• pass, fail, blocked, and not-run counts;
• requirement, risk, or code coverage;
• defect discovery and resolution trends;
• defect age and reopen rate;
• effort and schedule variance;
• environment availability;
• residual risk.

A metric must have a decision purpose. Pass rate alone can mislead: 98% may hide one catastrophic failure, and counting many trivial tests can inflate it. Defect counts are influenced by test intensity and reporting practice, so they are not a direct measure of developer quality.

Test progress reports

A test progress report is periodic and supports ongoing control. It can cover status, deviations, blockers, new risks, forecast, metrics, and requested decisions.

Test completion reports

A test completion report summarises completed testing: scope, deviations, coverage, defects, residual risks, evaluation against exit criteria, reusable assets, and lessons learned. It supports release and future maintenance.

Example control action: Monitoring shows the test environment unavailable 30% of the week and critical risk coverage behind plan. Control actions might secure a stable environment, move suitable tests to service-level mocks, defer low-risk cosmetic tests, and revise the forecast.

5.8 Configuration Management

Configuration management (CM) identifies and controls versions of work products and test items. Testing must know exactly which build, requirements, environment, data, scripts, and tool configurations produced a result. A baseline is an approved version that can be changed only through controlled procedures.

CM supports reproducibility, traceability, parallel work, rollback, and audit. A perfect defect report against an unknown build is weak evidence.

Example configuration record: application build 4.7.18; API image digest; database schema 2026.09.12; browser version; test-data snapshot; automation commit; environment variables; feature flags.

5.9 Defect Management

The defect management process recognises, records, classifies, investigates, resolves, and closes defects. A typical defect lifecycle is:

New -> Triaged -> Assigned -> In progress -> Resolved
                       -> Rejected/Duplicate/Deferred
Resolved -> Confirmation failed -> Reopened
Resolved -> Confirmation passed -> Closed

Actual states vary. The important concepts are transparent status, ownership, controlled resolution, and evidence.

Effective defect reports

A useful defect report includes:

• unique identifier and concise title;
• reporter and date;
• test object and exact version;
• environment and configuration;
• preconditions and reproducible steps;
• expected and actual results;
• evidence such as logs, screenshots, messages, or data;
• impact, severity, and proposed priority;
• references to requirements, tests, risks, and related defects;
• current status, owner, and resolution information.

Severity versus priority

Severity describes the degree of impact caused by a defect. Priority describes the urgency/order of fixing it. A spelling mistake on a highly visible launch page may be low severity but high priority. A crash in a rarely used administrator function may be high severity but lower immediate priority. Organisations define scales differently.

Root cause analysis in defect management

Aggregated defect data can reveal process causes: ambiguous requirements, insufficient unit testing, fragile interfaces, missing expertise, or configuration drift. Fixing only individual defects treats symptoms. Root cause actions should be measurable and checked for effectiveness.

5.10 Test Completion Activities

At completion, teams check that known defects and change requests are recorded, create summary reports, archive or transfer reusable testware, return or reset environments, close accounts, identify follow-up actions, and run lessons-learned discussions. Testware may be reused for maintenance; data containing personal information must be retained or destroyed according to policy.

5.11 Templates

Compact test plan template

Compact defect report template

Title:
Build/environment:
Preconditions:
Steps:
Expected result:
Actual result:
Evidence:
Severity / suggested priority:
Requirement/test/risk links:
Reproducibility and notes:

Chapter 5 Review Questions

1. Distinguish product risk from project risk with an example of each.
2. If likelihood is 4 and impact is 5 on a defined 1–5 model, what is the score?
3. Why is the score not an objective universal truth?
4. Distinguish test monitoring from test control.
5. Give three misleading uses of metrics.
6. What is the difference between a progress report and a completion report?
7. Why is configuration management essential to reproducibility?
8. Distinguish severity from priority.
9. Name six useful fields in a defect report.
10. What should happen to reusable testware at completion?

Chapter 5 Answer Key

1. Product risk: duplicate payment; project risk: unavailable performance environment.
2. 4 x 5 = 20.
3. Scales and assumptions are context-defined; qualitative judgement remains necessary.
4. Monitoring observes and compares; control takes corrective action.
5. Examples: equating pass rate with safety, equating defect count with developer quality, or ignoring risk/coverage context.
6. Progress reports support ongoing control; completion reports summarise finished work, residual risk, and exit status.
7. It identifies the exact versions of software, testware, data, and environment that produced results.
8. Severity is impact; priority is urgency/order of resolution.
9. Any six relevant fields from the template.
10. Archive or transfer it with versions, ownership, and retention handled appropriately.

Chapter 6: Tool Support for Testing

6.1 Why Tools Support Testing

Tools can increase repeatability, speed, coverage, traceability, measurement, and access to information. They can reduce repetitive manual work and enable activities that are impractical manually, such as sustained load generation or scanning millions of lines. A tool supports a process; it does not replace critical thinking, clear objectives, or skilled people.

6.2 Tool Categories

Test management tools

Support plans, requirements and risk links, test cases, schedules, execution results, dashboards, and defect integration. They improve visibility but can encourage excessive documentation if workflows are poorly designed.

Test execution and automation tools

Execute tests at component, API, UI, mobile, or other interfaces. They compare results, prepare data, drive systems, and collect evidence. Maintainability depends on design, stable interfaces, coding standards, and ownership.

Static analysis tools

Analyse source code or other work products without executing them. They can find rule violations, some security weaknesses, unreachable code, dependency risks, duplication, and complexity. False positives and context-specific interpretation require human review.

CI/CD tools

Orchestrate builds, checks, packaging, deployment, and feedback. They connect many specialised tools. A pipeline's value depends on fast, trustworthy signals and secure configuration.

Performance testing tools

Generate workloads, measure response time and throughput, monitor resources, and help analyse bottlenecks. A script that sends requests is not a valid performance test unless workload, environment, data, monitoring, and success criteria are realistic.

Other categories

Tools also support reviews, defect management, service virtualisation, data generation, security testing, accessibility, coverage measurement, monitoring, collaboration, and configuration management.

6.3 Benefits of Test Automation

Potential benefits include reduced repetitive work, faster feedback, repeatable execution, objective measurement, improved regression frequency, easier large-scale data comparison, and more time for human exploration. Automation can execute at times or scales unavailable to people and can enforce consistent checks.

Benefits are conditional. An automated test that is flaky, opaque, slow, or obsolete creates noise. Automation changes work rather than eliminating it: people design, implement, review, monitor, diagnose, and maintain the system.

6.4 Risks and Common Pitfalls

Common risks include:

• unrealistic expectations of immediate savings;
• choosing a tool before understanding the problem;
• underestimating maintenance, training, infrastructure, and integration;
• automating unstable or low-value tests;
• relying only on UI automation when lower interfaces are faster and more stable;
• vendor lock-in or poor support;
• insecure credentials and sensitive test data;
• false confidence from high execution counts;
• flaky tests that train teams to ignore failures;
• loss of human observation and exploratory testing;
• inadequate version control and ownership.

Example: A team automates 600 brittle UI scripts against frequently changing screens. Daily runs take eight hours and fail randomly. The nominal automation count is high, but feedback is slow and distrusted. Moving rule checks to component/API layers and retaining a small critical UI suite improves value.

6.5 Tool Selection

A responsible selection process:

1. Identify the problem, objectives, users, constraints, and success measures.
2. Assess organisational maturity, process fit, skills, architecture, security, and integrations.
3. Define requirements and evaluation criteria.
4. Evaluate alternatives, including build versus buy and doing nothing.
5. Conduct a representative proof of concept or pilot project.
6. Evaluate results and total cost.
7. Plan rollout, training, support, governance, and retirement.

Do not let a polished demonstration substitute for a representative pilot using real technology, data volume, security constraints, and team skills.

6.6 ROI and Total Cost

Return on investment (ROI) compares expected benefits with costs. A simple expression is:

[ \text{ROI} = \frac{\text{benefit} - \text{cost}}{\text{cost}} \times 100% ]

Costs include licensing, procurement, training, hardware, integration, test design, scripting, maintenance, triage, upgrades, support, and opportunity cost. Benefits include labour saved, faster feedback, additional coverage, earlier defect detection, reduced failure loss, and improved release frequency. Some benefits are difficult to monetise, so assumptions must be stated.

Worked example: Annual benefit is estimated at R500,000 and total first-year cost at R400,000. ROI = (500,000 - 400,000) / 400,000 x 100 = 25%. This does not prove success; validate benefit assumptions and recurring cost.

6.7 Pilot Projects and Implementation Strategy

A pilot project should be limited but representative, have measurable goals, include motivated and sceptical users, and produce reusable learning. Avoid selecting only the easiest demonstration or the most critical project for a first trial.

Implementation activities include naming an owner, establishing standards, integrating version control and CI, designing maintainable architecture, training users, providing coaching, monitoring adoption, measuring value, and improving incrementally. Retain manual and exploratory testing where human judgement is superior.

Real-world implementation example

A payments team wants faster regression feedback. The pilot automates 30 high-risk API scenarios across approval, idempotency, timeout, and reversal. Success criteria are execution under ten minutes, less than 2% flaky failures, clear diagnostics, and maintenance under four hours per sprint. After two sprints, the team compares results with criteria before scaling.

Chapter 6 Review Questions

1. Name five tool categories and one use for each.
2. Why can automation increase work initially?
3. List four automation risks.
4. Why is a representative pilot important?
5. What costs belong in ROI beyond licence price?
6. Calculate ROI when benefit is 240 and cost is 200.
7. Why is high automated test count not sufficient evidence of value?
8. What characteristics make pipeline feedback trustworthy?

Chapter 6 Answer Key

1. Any five valid categories and uses from this chapter.
2. Infrastructure, learning, design, implementation, integration, and maintenance must be established.
3. Any four listed risks, such as flakiness, unrealistic expectations, weak process fit, maintenance cost, or false confidence.
4. It tests actual fit and cost under real constraints rather than a demonstration scenario.
5. Training, integration, infrastructure, design, scripting, maintenance, triage, upgrades, support, and opportunity cost.
6. (240-200)/200 x 100 = 20%.
7. Counts ignore risk coverage, assertion quality, maintainability, runtime, and diagnostic value.
8. Fast, deterministic, relevant checks with clear diagnostics, secure configuration, and active ownership.

ISTQB Glossary Study Guide {.unnumbered}

These explanations are study-oriented paraphrases. Use the official glossary for canonical wording.

Chapter 1 Terms

• Testing: Activities that discover defects and evaluate software work products and quality.
• Test object: The work product being tested, such as a component, system, document, or data migration.
• Test basis: Information used to derive tests, such as requirements, stories, design, risk analysis, or code.
• Testware: Work products produced during testing, including plans, cases, data, scripts, logs, and reports.
• Error: A human action producing an incorrect result.
• Defect: An imperfection or deficiency in a work product.
• Failure: Observed inability to perform a required function within specified limits.
• Quality: Degree to which an object satisfies stated and implied needs.
• Quality assurance: Process-focused activities that provide confidence quality requirements will be fulfilled.
• Verification: Confirmation that specified requirements have been fulfilled.
• Validation: Confirmation that the product fulfils needs for its intended use.
• Debugging: Finding, analysing, and removing the cause of a failure.
• Root cause: Fundamental reason for a problem whose removal reduces recurrence.
• Test condition: A testable aspect identified as a basis for testing.
• Test case: Preconditions, inputs, actions, expected results, and postconditions developed for an objective.
• Test procedure: A sequence of test cases in execution order plus setup and wrap-up actions.
• Test suite: A set of test scripts or test procedures intended for a particular execution.
• Expected result: Predicted observable behaviour based on the test basis.
• Actual result: Behaviour observed when the test is executed.
• Traceability: Ability to link related work products, tests, results, risks, and defects.
• Coverage: Degree to which specified coverage items are exercised by tests.
• Exit criteria: Conditions used to declare a test activity complete.

Chapter 2 Terms

• SDLC model: Framework describing development activities and relationships through the product lifecycle.
• Sequential development model: Lifecycle in which major phases are organised mainly in sequence.
• Iterative development: Repeated cycles refine a solution.
• Incremental development: Product capability is delivered in pieces.
• Agile development: Iterative-incremental development emphasising collaboration and responsiveness.
• DevOps: Organisational and technical practices joining development and operations for rapid, reliable delivery.
• Shift-left: Performing test activities earlier in the lifecycle.
• Test level: Group of test activities managed together for a particular object and objective.
• Component testing: Testing individual components separately.
• Integration testing: Testing interfaces and interactions between components or systems.
• System testing: Testing the complete integrated system.
• Acceptance testing: Testing readiness and acceptability for stakeholders or deployment.
• Functional testing: Testing what the test object does.
• Non-functional testing: Testing how well it behaves against quality characteristics.
• Black-box testing: Deriving tests from specifications without internal structure as the basis.
• White-box testing: Deriving tests from internal structure.
• Confirmation testing: Testing whether a specific defect was successfully fixed.
• Regression testing: Testing for adverse consequences of change.
• Maintenance testing: Testing changes to an operational system or its environment.
• Impact analysis: Evaluation of consequences and affected areas of a proposed change.

Chapter 3 Terms

• Static testing: Testing without executing the test object.
• Dynamic testing: Testing involving execution of the software.
• Review: Evaluation of a work product by one or more people.
• Static analysis: Tool-supported evaluation without execution, often against code or models.
• Informal review: Review without a defined formal process.
• Walkthrough: Author-led review, often serving education and defect finding.
• Technical review: Review by technically qualified participants, often seeking consensus.
• Inspection: Formal review with defined process, roles, criteria, and metrics.
• Moderator: Person who facilitates review activities.
• Scribe: Person who records findings and decisions.

Chapter 4 Terms

• Equivalence partitioning: Dividing a domain into partitions expected to be treated similarly.
• Boundary value analysis: Deriving tests from partition boundaries.
• Decision table: Tabular model of condition combinations and resulting actions.
• State transition: Change from one state to another due to an event.
• Statement coverage: Percentage of executable statements exercised.
• Branch coverage: Percentage of branches in a control-flow structure exercised.
• Error guessing: Deriving tests from knowledge of likely errors and failures.
• Checklist-based testing: Designing or executing tests using a list of conditions to check.
• Exploratory testing: Simultaneous learning, design, and execution.
• Test charter: Mission and scope for a test session.
• ATDD: Collaborative derivation of acceptance tests before implementation.
• BDD: Collaborative specification through examples of behaviour, often in Given-When-Then form.

Chapter 5 Terms

• Test plan: Documentation describing objectives, resources, processes, scope, approach, and schedule.
• Product risk: Risk that a work product may fail to satisfy needs.
• Project risk: Risk to project delivery or objectives.
• Risk level: Measure based on likelihood and impact.
• Test monitoring: Ongoing collection and comparison of test status against plan.
• Test control: Corrective action based on monitoring information.
• Test metric: Measurement relating to testing, quality, progress, or resources.
• Test progress report: Periodic report supporting ongoing monitoring and control.
• Test completion report: Summary of completed testing, outcomes, deviations, and residual risk.
• Configuration management: Identification and control of configuration items and versions.
• Defect management: Process for recognising, recording, investigating, resolving, and closing defects.
• Severity: Degree of impact caused by a defect.
• Priority: Urgency or order in which work should be addressed.

Chapter 6 Terms

• Test automation: Use of software to perform or support testing activities.
• Test execution tool: Tool that runs tests and records outcomes.
• Test management tool: Tool supporting planning, control, traceability, and reporting.
• Pilot project: Limited representative implementation used to evaluate a tool or approach.
• Tool support: Assistance a tool provides to a testing activity; it does not remove accountability.

Memory Aids and Quick Revision Sheets {.unnumbered}

Mnemonics

Seven principles: P-E-E-D-W-C-A

Presence, not absence; Exhaustive is impossible; Early saves; Defects cluster; tests Wear out; Context matters; Absence-of-defects fallacy.

Phrase: “Practical Examiners Expect Disciplined Work in Context Always.” Use the phrase only as a recall trigger; know each meaning.

Core activities: P-M-A-D-I-E-C

Planning; Monitor/control; Analysis; Design; Implementation; Execution; Completion.

Review flow: P-I-I-C-F-F

Plan, Initiate, Individual review, Communicate/analyse, Fix/report, Follow up.

Technique selector: Groups-Edges-Rules-History-Structure-Experience

• Groups -> EP
• Edges -> BVA
• Rules -> decision table
• History -> state transition
• Structure -> white-box
• Experience -> error guessing/checklist/exploration

Flashcards

Key Formulas

[ \text{Coverage percentage} = \frac{\text{covered items}}{\text{total identified items}} \times 100% ]

[ \text{Statement coverage} = \frac{\text{executed statements}}{\text{total executable statements}} \times 100% ]

[ \text{Branch coverage} = \frac{\text{executed branches}}{\text{total branches}} \times 100% ]

[ \text{Risk score (when defined)} = \text{likelihood} \times \text{impact} ]

[ \text{ROI} = \frac{\text{benefit} - \text{cost}}{\text{cost}} \times 100% ]

One-Page Technique Sheet

Frequently Confused Concepts

Recommended Video Learning Path {.unnumbered}

This curriculum turns the textbook into a guided video course. The official syllabus remains authoritative; videos are explanations and practice aids. Video availability, titles, advertisements, and durations can change. A direct link was used when a stable watch URL could be verified. A YouTube search link is deliberately used when an individual watch URL or exact metadata could not be verified. Search links contain the exact channel and title to select.

The backbone is the TM SQUARE CTFL v4.0 playlist, a 61-video topic sequence last updated in February 2025. The O.M Academy CTFL v4.0 playlist provides longer second explanations. The Test Made Easy CTFL v4.0 playlist is useful for short reinforcement. Publication dates shown as “2023–2024” are approximate playlist-era dates when the exact day was not visible. “Not verified” means no claim is made about the upload date.

How to Learn From the Videos

For each topic: read the corresponding manual section, watch the beginner video without taking extensive notes, close the video and explain the concept aloud, work the linked questions, then watch the intermediate or exam-focused item only where your answer exposes a gap. K1 videos are for recognition and recall; K2 videos must support comparison and explanation; K3 videos require pausing before worked answers and deriving the result yourself.

Core viewing time: approximately 11 hours 45 minutes for the chapter-path videos. Chapter 4 extended track: approximately 7 hours 30 minutes if all beginner, intermediate, exam-focused, and practice items are watched. Complete curriculum: approximately 19 hours 15 minutes of video, or 25–28 hours including pauses, notes, and linked exercises.

Chapter 1 Video Learning Path: Fundamentals of Testing

Why These Videos Matter

• Tutorial 2 covers FL-1.1.1 and FL-1.1.2 and supports mock Questions 1, 4, 7, 75, 76, and 78. It is K1/K2 focused. Watch for the common errors that testing is only execution and that testing equals debugging.
• Tutorial 3 covers FL-1.2.1–1.2.3 and supports Questions 2, 3, 74, 77, and 79. It is K1/K2 focused. The usual trap is confusing a human error, a work-product defect, an observed failure, and an underlying root cause.
• Tutorial 4 covers FL-1.3.1 and supports Questions 5, 6, 73, 74, 96, and 99. It is K2 focused. Learners commonly misread “tests wear out” as an instruction to delete regression tests.
• Tutorials 5–6 cover FL-1.4.1–1.4.5 and support Questions 7–10, 79, and 80. They are K2 focused. The key distinctions are analysis versus design, design versus implementation, and monitoring versus control.
• Tutorials 7–8 cover FL-1.5.1–1.5.3 and support Questions 80 and 81 plus the Chapter 1 review. They are K1/K2 focused. Independence is beneficial but not absolute; whole-team responsibility does not mean nobody owns testing work.

Chapter 2 Video Learning Path: Testing Throughout the SDLC

Why These Videos Matter

• Tutorial 10 covers FL-2.1.1–2.1.2 and Questions 11–12, 77, and 95. It is K1/K2 focused. Do not equate the V-model with “all testing after coding.”
• Tutorial 11 covers FL-2.1.3–2.1.4 and Questions 13, 44–46, and 89. It is K1/K2 focused. TDD, BDD, and ATDD overlap but have different focal points.
• Tutorial 12 covers FL-2.1.5–2.1.6 and Questions 14 and 94. It is K2 focused. Shift-left does not eliminate later testing; retrospectives need actions and follow-up.
• Tutorials 13–19 cover FL-2.2.1–2.2.2 and Questions 15–16 and 35–40. They are K2 focused. A test level is determined by object and objective, not job title.
• Tutorial 20 covers FL-2.2.3 and Questions 17–18. It is K2 focused. Confirmation targets the specific fix; regression targets adverse effects.
• Tutorial 21 covers FL-2.3.1 and Questions 19–20. It is K2 focused. Maintenance includes migration, retirement, and environmental change, not only bug fixes.

Chapter 3 Video Learning Path: Static Testing

Why These Videos Matter

• Tutorials 23–24 cover FL-3.1.1–3.1.3 and Questions 21, 75, and 82. They are K1/K2 focused. Static testing finds defects without execution; dynamic testing observes behaviour during execution.
• Tutorial 25 covers FL-3.2.1–3.2.3 and Questions 22–23 and 83. It is K1/K2 focused. The author performs rework, the moderator facilitates, and the scribe records.
• Tutorial 26 covers FL-3.2.4 and Questions 24–25. It is K2 focused. Remember: walkthrough is author-led; inspection is the most formal.
• Tutorial 27 covers FL-3.2.5 and Questions 26 and 84. It is K1 focused. Psychological safety and product focus matter; review metrics must not become a blame mechanism.

Chapter 4 Video Learning Path: Test Analysis and Design

Four-Level Technique Curriculum

The following mandatory stacks give each technique a beginner explanation, a second explanation, exam-oriented reinforcement, and practice. Search-target metadata is intentionally marked when an individual URL, exact duration, or exact date was not independently verified.

Equivalence Partitioning

Why this video stack matters: It covers FL-4.2.1 (K3) and supports Questions 27–28, 84. The beginner item establishes the model; the intermediate item supplies a second explanation; the exam item trains recognition of distractors; the practice item forces application. The principal misconception to challenge is that knowing the definition is enough: this is a K3 technique, so the learner must derive tests from a new scenario.

Boundary Value Analysis

Why this video stack matters: It covers FL-4.2.2 (K3) and supports Questions 29–30, 85. The beginner item establishes the model; the intermediate item supplies a second explanation; the exam item trains recognition of distractors; the practice item forces application. The principal misconception to challenge is that knowing the definition is enough: this is a K3 technique, so the learner must derive tests from a new scenario.

Decision Tables

Why this video stack matters: It covers FL-4.2.3 (K3) and supports Questions 31–33, 86. The beginner item establishes the model; the intermediate item supplies a second explanation; the exam item trains recognition of distractors; the practice item forces application. The principal misconception to challenge is that knowing the definition is enough: this is a K3 technique, so the learner must derive tests from a new scenario.

State Transition Testing

Why this video stack matters: It covers FL-4.2.4 (K3) and supports Questions 34–35, 87. The beginner item establishes the model; the intermediate item supplies a second explanation; the exam item trains recognition of distractors; the practice item forces application. The principal misconception to challenge is that knowing the definition is enough: this is a K3 technique, so the learner must derive tests from a new scenario.

Use Case Testing (supplemental)

Why this video stack matters: It covers Supplement to 4.2; not a named CTFL v4.0 LO and supports Chapter 4 use-case exercise. The beginner item establishes the model; the intermediate item supplies a second explanation; the exam item trains recognition of distractors; the practice item forces application. The principal misconception to challenge is that knowing the definition is enough: the learner must explain the technique, its coverage, and its limitations rather than merely name it.

Statement Coverage

Why this video stack matters: It covers FL-4.3.1 (K2) and supports Questions 37, 39, 88. The beginner item establishes the model; the intermediate item supplies a second explanation; the exam item trains recognition of distractors; the practice item forces application. The principal misconception to challenge is that knowing the definition is enough: the learner must explain the technique, its coverage, and its limitations rather than merely name it.

Branch Coverage

Why this video stack matters: It covers FL-4.3.2–4.3.3 (K2) and supports Questions 38–40, 89–90. The beginner item establishes the model; the intermediate item supplies a second explanation; the exam item trains recognition of distractors; the practice item forces application. The principal misconception to challenge is that knowing the definition is enough: the learner must explain the technique, its coverage, and its limitations rather than merely name it.

Exploratory Testing

Why this video stack matters: It covers FL-4.4.2 (K2) and supports Questions 42–43. The beginner item establishes the model; the intermediate item supplies a second explanation; the exam item trains recognition of distractors; the practice item forces application. The principal misconception to challenge is that knowing the definition is enough: the learner must explain the technique, its coverage, and its limitations rather than merely name it.

Error Guessing

Why this video stack matters: It covers FL-4.4.1 (K2) and supports Question 41. The beginner item establishes the model; the intermediate item supplies a second explanation; the exam item trains recognition of distractors; the practice item forces application. The principal misconception to challenge is that knowing the definition is enough: the learner must explain the technique, its coverage, and its limitations rather than merely name it.

ATDD

Why this video stack matters: It covers FL-4.5.3 (K3) and supports Questions 44–46. The beginner item establishes the model; the intermediate item supplies a second explanation; the exam item trains recognition of distractors; the practice item forces application. The principal misconception to challenge is that knowing the definition is enough: this is a K3 technique, so the learner must derive tests from a new scenario.

Chapter 4 Misconception Checklist

• EP: valid values with different expected behaviour may require different partitions.
• BVA: 2-value BVA does not mean two tests total; model every relevant boundary.
• Decision tables: a dash is don't-care, not false; infeasible rules are not feasible-rule coverage items.
• State transitions: state coverage does not imply transition coverage.
• Use cases: a happy path is not the whole use case; alternatives and exceptions matter. This topic is supplemental rather than a named v4.0 LO.
• Statement coverage: 100% does not imply all decision outcomes.
• Branch coverage: 100% branch coverage does not imply all paths, data combinations, or requirements.
• Exploratory testing: it is chartered learning and testing, not random clicking.
• Error guessing: it is strengthened by defect taxonomies and experience; it is not unsupported intuition.
• ATDD: acceptance tests are collaboratively derived before implementation; automation is optional.

Chapter 5 Video Learning Path: Managing the Test Activities

Why These Videos Matter

• Tutorials 44–46 cover FL-5.1.1–5.1.3 and Questions 54, 91, and 92. They are K1/K2 focused. Planning is ongoing; entry is a starting precondition and exit is a completion condition.
• Tutorial 47 covers FL-5.1.4 and Questions 52–54. It is K3 focused. Pause before calculations and identify whether the question uses ratios, extrapolation, Wideband Delphi, or three-point estimation.
• Tutorial 48 covers FL-5.1.5 and Question 91. It is K3 focused. Risk is important, but dependencies can constrain order; additional-coverage prioritisation is a specific strategy.
• Tutorial 49 covers FL-5.1.6–5.1.7 and Question 71. It is K1/K2 focused. The pyramid and quadrants are heuristics, not phases or fixed ratios.
• Tutorials 50–51 cover FL-5.2.1–5.2.4 and Questions 47–51. They are K1/K2 focused. Product risk concerns quality harm; project risk concerns delivery.
• Tutorials 52–53 cover FL-5.3.1–5.3.3 and Questions 55–57. They are K1/K2 focused. Monitoring observes and reports; control changes the work.
• Tutorial 54 covers FL-5.4.1 and Questions 58–59. It is K2 focused. CM controls the versions of testware, test objects, data, and environments, not only source code.
• Tutorial 55 covers FL-5.5.1 and Questions 60–65. It is K3 focused. A defect report must be reproducible and decision-useful; severity is impact and priority is urgency.

Chapter 6 Video Learning Path: Tool Support for Testing

Why These Videos Matter

• Tutorial 57 covers FL-6.1.1 and Questions 66–67. It is K2 focused. The exam asks what activity a tool supports; it does not require brand memorisation.
• Tutorial 58 covers FL-6.2.1 and Questions 68–72 and 95. It is K1 focused. Automation creates maintenance, training, integration, and false-confidence risks as well as speed and repeatability benefits.
• Tutorial 59 trains the chapter's terminology and distractors. Do not assume buying a tool guarantees benefit or that every repeatable activity should be automated.

Watch Order {.unnumbered}

The order integrates reading, video, and practice over four weeks. A “tutorial number” refers to the TM SQUARE playlist unless a different channel is named.

Week 1: Foundations and Lifecycle — about 4 hours video

1. Open Exam Prep – How to Pass the ISTQB CTFL Exam in 2026.
2. Tutorials 2–8: Chapter 1 concepts.
3. Tutorial 9: Chapter 1 questions; then complete manual Questions 1–10 and 73–80.
4. Tutorials 10–12: SDLC, test-first, DevOps, shift left, retrospectives.
5. Tutorials 13–21: test levels, types, confirmation/regression, maintenance.
6. Tutorial 22: Chapter 2 questions; then complete manual Questions 11–20 and 89.

Week 2: Static Testing and Black-Box Techniques — about 5 hours video

1. Tutorials 23–27: static testing and reviews.
2. Tutorial 28 and manual Questions 21–26 and 81–84.
3. Tutorial 29: technique families.
4. Tutorial 30 plus O.M Academy EP; solve EP exercises before watching answers.
5. Tutorial 31 plus Software Testing Mentor or Guru99 BVA; solve 2-value and 3-value BVA exercises.
6. Tutorials 32–33 plus O.M Academy decision-table and state-transition videos.
7. Complete manual Questions 27–35 and 84–87.

Week 3: White-Box, Experience-Based, Collaboration, and Management — about 6 hours video

1. Tutorials 34–36: statement, branch, and white-box value.
2. Tutorials 37–39: error guessing, exploratory, and checklist-based testing.
3. Tutorials 40–42: collaborative stories, acceptance criteria, and ATDD.
4. Tutorial 43 and manual Questions 36–46 and 88–90.
5. Tutorials 44–49: planning, estimation, prioritisation, pyramid, and quadrants.
6. Work every estimation and coverage calculation without viewing the solution first.

Week 4: Risk, Reporting, Tools, and Exam Rehearsal — about 4 hours 15 minutes video

1. Tutorials 50–55: risk, monitoring/control, reports, CM, and defects.
2. Tutorial 56 and manual Questions 47–65 and 91–94.
3. Tutorials 57–59 and manual Questions 66–72 and 95–99.
4. Tutorial 60: Exam Details and 30-Minute Summary.
5. Viral Courses – CTFL 4.0 Practice Questions and Detailed Explanations, then sit the manual's 100-question mock under timed conditions.
6. Sit at least two official 40-question sample exams. Review every distractor, not only wrong answers.

Highest ROI Videos {.unnumbered}

These 20 items provide the strongest return for exam preparation. “ROI” means coverage and error prevention per minute, not entertainment value.

1. What is Testing – TM SQUARE, 13:49 — establishes objectives and the testing/debugging distinction used throughout the exam.
2. Testing Principles – TM SQUARE, 14:36 — seven principles generate frequent K2 scenario questions.
3. Impact of SDLC on Testing – TM SQUARE, 15:03 — prevents lifecycle and V-model misconceptions.
4. Confirmation and Regression Testing – TM SQUARE, 11:04 — fixes one of the most common terminology reversals.
5. Static Testing Basics – TM SQUARE, 13:42 — efficiently covers review/static-analysis foundations.
6. Review Types – TM SQUARE, 12:15 — comparison questions become straightforward after one clear table.
7. Equivalence Partitioning – TM SQUARE, 15:06 — core K3 technique and a prerequisite for BVA reasoning.
8. Boundary Value Analysis – TM SQUARE, 13:41 — directly trains 2-value and 3-value calculations.
9. Decision Table Testing – TM SQUARE, 9:59 — high value for condition/action combination questions.
10. State Transition Testing – TM SQUARE, 11:56 — clarifies state versus transition coverage.
11. Statement Testing and Coverage – TM SQUARE, 11:40 — teaches the structural coverage formula and its limitations.
12. Branch Testing and Coverage – TM SQUARE, 11:52 — explains why branch coverage subsumes statement coverage.
13. Exploratory Testing – TM SQUARE, 11:05 — prevents the “random testing” misconception.
14. ATDD – TM SQUARE, 10:11 — addresses the Chapter 4 K3 collaboration objective.
15. Chapter 4 Sample Questions – TM SQUARE, 12:20 — highest-concentration technique practice.
16. Test Estimation Techniques – TM SQUARE, 16:36 — covers the K3 estimation objective with worked methods.
17. Test Reports – TM SQUARE, 12:51 — separates progress and completion reporting.
18. Defect Management – TM SQUARE, 10:17 — prepares the K3 defect-report objective.
19. Tool Support for Testing – TM SQUARE, 8:58 — covers Chapter 6's tool categories in minimal time.
20. Exam Details and Summary – TM SQUARE, 27:29 — an efficient final review after, not before, full study.

Skip If Short On Time {.unnumbered}

• O.M Academy duplicate chapter introductions: useful second explanations, but skip when the TM SQUARE explanation and your practice score are already strong.
• Use Case Testing supplemental videos: useful professionally, but use-case testing is not a named CTFL v4.0 learning objective. Read the manual section instead.
• A second general “full CTFL course” playlist: switching instructors can consume hours without increasing retrieval practice.
• Long generic automation-framework tutorials: CTFL Chapter 6 tests tool-support concepts and risks, not Selenium, Cypress, Playwright, or framework syntax.
• Deep DevOps implementation demonstrations: the exam expects impact on testing, feedback, automation, and collaboration—not pipeline administration.
• Extended Ministry of Testing conference talks: excellent professional development, but less efficient for last-week syllabus recall.
• Older CTFL v3.1 question walkthroughs: many fundamentals transfer, but changed terminology and learning objectives can create avoidable confusion.
• Shorts under one minute: useful as reminders, not as primary teaching for K2 or K3 objectives.

Video-to-Syllabus Traceability Matrix {.unnumbered}

Every formal CTFL v4.0.1 learning objective is mapped below. Question numbers refer to the 100-question mock in this manual. Several videos cover multiple objectives; this is intentional because the syllabus concepts interact.

Traceability Completeness Check

The matrix maps all 64 formal learning objectives in CTFL v4.0.1: 14 in Chapter 1, 10 in Chapter 2, 8 in Chapter 3, 14 in Chapter 4, 16 in Chapter 5, and 2 in Chapter 6. Use Case Testing is retained as requested supplemental material and is explicitly not presented as a named CTFL v4.0.1 learning objective.

Video Metadata and Selection Notes

• TM SQUARE's playlist exposes a syllabus-ordered set of topic videos with durations and chapter practice videos, making it the most efficient backbone for traceability.
• O.M Academy's 24-video playlist provides longer explanations for learners who need a second model, especially for Chapter 4.
• Software Testing Mentor's Boundary Value Analysis in Testing was published 10 December 2020 and is useful as an alternate explanation even though it predates v4.0.
• Guru99's Boundary Value Analysis and Equivalence Partitioning is a beginner-oriented combined explanation; the exact publication date and duration were not reliably exposed during verification.
• Test Made Easy's Branch Coverage in Software Testing was published 14 May 2025 and reinforces calculation and comparison.
• Ministry of Testing is recommended through exact search links for professional-depth exploratory testing and ATDD. Its conference-style content is conceptually strong but may be less exam-efficient than the syllabus-ordered backbone.
• Dimo Stefanov, The Testing Academy, SDET-QA Automation Techie, Rahul Shetty, Naveen Automation Labs, QAFox, and Software Testing Help are valuable practical educators. Their videos should be selected through the exact topic searches in this section when a stable individual CTFL-v4 URL is not shown; practical framework courses are optional for this theory-focused exam.

Mock Examination: 100 Original CTFL-Style Questions {.unnumbered}

Instructions: Allow 150 minutes for this expanded mock (approximately 1.5 minutes per question). Select one answer per question. Do not consult the answer key until finished. For an exam-equivalent score, also calculate performance for Questions 1-40 using a 26/40 pass threshold.

Question 1

Which statement best describes a limitation of testing?

A. Testing can prove the absence of defects when coverage is 100% B. Testing reduces uncertainty but cannot normally prove that no defects remain C. Testing is useful only after implementation D. Testing and debugging are the same activity

Question 2

A business analyst misunderstands a regulation and writes the wrong retention period. What is the analyst's misunderstanding?

A. Failure B. Defect C. Error D. Test condition

Question 3

Which is primarily a quality assurance activity?

A. Executing a boundary test B. Auditing whether the review process is followed C. Reporting an observed crash D. Calculating branch coverage

Question 4

A tester observes a failure. What activity normally locates and removes its cause?

A. Test monitoring B. Debugging C. Test design D. Configuration management

Question 5

Which testing principle explains why tests should be selected by risk and technique?

A. Defects cluster B. Exhaustive testing is impossible C. Tests wear out D. Testing is context dependent

Question 6

A suite repeatedly finds no new defects although the product keeps changing. Which principle is most directly relevant?

A. Tests wear out B. Early testing saves C. Absence-of-defects fallacy D. Defects cluster

Question 7

Which activity identifies test conditions from the test basis?

A. Test analysis B. Test implementation C. Test execution D. Test completion

Question 8

Which work product is testware?

A. A tax regulation used as the basis B. An executed application binary only C. A test charter created for an exploratory session D. A customer's business goal

Question 9

What is a principal benefit of bidirectional traceability?

A. It guarantees every requirement is correct B. It links requirements to tests and tests back to their justification C. It eliminates regression testing D. It proves no defects remain

Question 10

An exit criterion is unmet. What is the most accurate conclusion?

A. Release is technically impossible B. All tests must be deleted C. Stakeholders need the status and residual risk for a decision D. The test manager must hide the deviation

Question 11

What does the V-model chiefly illustrate?

A. Only developers perform component testing B. Links between development work products and corresponding test activities C. All testing occurs after coding D. Agile development cannot use test levels

Question 12

Which statement correctly compares iterative and incremental development?

A. They are synonyms B. Iterative refines through cycles; incremental adds pieces C. Incremental forbids regression testing D. Iterative delivers only once

Question 13

Which is a likely DevOps testing benefit?

A. All manual testing becomes unnecessary B. Rapid repeatable feedback through a pipeline C. Production monitoring is prohibited D. Configuration management is no longer needed

Question 14

Which is the best example of shift-left testing?

A. Reviewing acceptance criteria before coding B. Ignoring production feedback C. Running all tests only after release D. Moving testers to a different office

Question 15

Which level focuses on interactions between the system and an external courier service?

A. Component testing B. System integration testing C. Component integration testing only D. User acceptance testing only

Question 16

Which acceptance test most clearly addresses operational readiness?

A. Checking a pure calculation function B. Checking backup restoration and monitoring alerts C. Measuring statement coverage D. Reviewing a code naming rule

Question 17

A rounding defect was fixed. Re-running the original failing case is what?

A. Regression testing B. Confirmation testing C. Static testing D. Acceptance testing

Question 18

Testing invoice exports after the rounding fix is what?

A. Regression testing B. Debugging C. Inspection D. Only confirmation testing

Question 19

Which is a maintenance-testing trigger?

A. Database platform upgrade B. Writing the first project vision C. Hiring a tester unrelated to a change D. Reading the glossary

Question 20

What is impact analysis used for?

A. To calculate employee performance B. To identify areas and tests affected by a change C. To replace configuration management D. To guarantee a zero-risk release

Question 21

Which defect is especially suited to static testing?

A. A requirement contradicts another requirement B. A server slows only under peak load C. A race condition observed during execution D. A device fails under heat

Question 22

What occurs immediately after review initiation in the generic process?

A. Individual review B. Test execution C. Deployment D. Debugging

Question 23

Who is principally responsible for correcting accepted review defects?

A. Scribe B. Author C. Moderator D. Manager

Question 24

Which review type is characteristically led by the author?

A. Inspection B. Walkthrough C. Audit D. Formal technical inspection only

Question 25

Which review type normally has the highest formality?

A. Informal review B. Walkthrough C. Inspection D. Pair discussion

Question 26

Which factor most supports review success?

A. Evaluating the author rather than the product B. Clear objectives and adequate preparation time C. Reviewing very large documents in one sitting D. Using defect counts to punish authors

Question 27

A field accepts ages 18 through 65 inclusive. How many equivalence partitions are needed for the simple range model?

A. One B. Two C. Three D. Four

Question 28

Which set gives one representative from each age partition for 18 through 65 inclusive?

A. 18, 40, 65 B. 17, 40, 66 C. 18, 19, 20 D. 16, 17, 18

Question 29

Which is the 2-value BVA set for an inclusive integer range 1 through 6?

A. 1, 6 B. 0, 1, 6, 7 C. 0, 1, 2, 5, 6, 7 D. -1, 0, 7, 8

Question 30

Which is the 3-value BVA set for an inclusive integer range 8 through 20?

A. 7, 8, 20, 21 B. 8, 9, 19, 20 C. 7, 8, 9, 19, 20, 21 D. 6, 7, 8, 20, 21, 22

Question 31

When is decision table testing especially appropriate?

A. When combinations of conditions determine actions B. When only code statements matter C. When there are no business rules D. When testing typography only

Question 32

What does a dash in a simplified decision table mean?

A. The condition must be false B. The condition is irrelevant for that rule C. The rule is invalid D. The test failed

Question 33

A decision table contains eight feasible rules and six are tested. What is rule coverage?

A. 60% B. 65% C. 75% D. 80%

Question 34

Which model is best when the response to an event depends on previous events?

A. Equivalence partitions only B. State transition model C. Statement list D. Static-analysis rule

Question 35

A test visits every state. What can be concluded?

A. Every transition was necessarily covered B. No invalid transition exists C. State coverage may be complete but transition coverage may not be D. All paths were covered

Question 36

Which use-case element describes what must be true before the flow starts?

A. Postcondition B. Precondition C. Actor goal result D. Exception outcome only

Question 37

A program has 120 executable statements; 90 execute. What is statement coverage?

A. 25% B. 70% C. 75% D. 90%

Question 38

A flow graph has 10 branches; 7 execute. What is branch coverage?

A. 30% B. 70% C. 75% D. 143%

Question 39

Which coverage relationship is correct?

A. 100% statements always gives 100% branches B. 100% branches subsumes 100% statements for reachable code C. Coverage proves requirement correctness D. Branch coverage includes every path

Question 40

Why can 100% branch coverage still miss defects?

A. It does not ensure all data combinations or paths B. It means no statement was executed C. It is lower than 0% statement coverage D. It prevents assertions

Question 41

Which is an example of error guessing?

A. Testing duplicate submission because similar products had idempotency defects B. Selecting every decision-table rule mechanically C. Computing branch percentage only D. Following a mandated script without adaptation

Question 42

What distinguishes exploratory testing?

A. No objective or notes B. Simultaneous learning, design, and execution C. Only automated execution D. No tester skill is needed

Question 43

Which is a useful exploratory test charter?

A. Test everything until done B. Explore refund concurrency for duplicate postings during a 60-minute session C. Click randomly D. Prove the system has no defects

Question 44

In Given-When-Then, what does 'When' normally express?

A. Initial context B. The event or action C. The observable outcome D. The defect priority

Question 45

What is a key purpose of ATDD?

A. Derive acceptance tests collaboratively before implementation B. Replace every component test C. Delay clarification until execution D. Measure only code branches

Question 46

What perspectives are represented by the Three Amigos?

A. Business, development, and testing B. Only three testers C. Legal, payroll, and sales only D. Customer, regulator, and compiler

Question 47

Which is a project risk?

A. The system calculates tax incorrectly B. A security vulnerability exposes data C. The only performance specialist is unavailable D. The user interface is inaccessible

Question 48

Which is a product risk?

A. Supplier delivery is late B. Test budget is cut C. Database failover loses committed transactions D. A tester leaves the team

Question 49

Likelihood is 3 and impact is 4 on a defined multiplicative scale. What is the score?

A. 7 B. 12 C. 34 D. 75%

Question 50

How does risk-based testing use risk level?

A. To allocate testing intensity and priority B. To eliminate stakeholder judgement C. To avoid all low-risk testing D. To calculate branch coverage

Question 51

Which is a risk mitigation through testing?

A. Execute resilience tests against provider timeouts B. Hide the provider risk C. Delete the risk register D. Assume the supplier never fails

Question 52

Which estimation method relies primarily on historical measurements?

A. Metrics-based estimation B. Error guessing C. Exploratory testing D. Inspection

Question 53

What is a benefit of Wideband Delphi?

A. One manager dictates the estimate B. Experts estimate independently then discuss assumptions C. It guarantees exact duration D. It excludes uncertainty

Question 54

Why is duration not simply effort divided by staff?

A. Testing has dependencies and communication overhead B. Effort is never estimated C. People work with perfect interchangeability D. Parallel work is always impossible

Question 55

Which action is test control?

A. Observing that critical coverage is behind plan B. Reprioritising tests toward critical risks C. Recording the original schedule only D. Calculating yesterday's pass rate without action

Question 56

Which metric is most dangerous when presented without risk context?

A. A 98% pass rate B. The build identifier C. The report date D. The test owner

Question 57

What belongs in a test completion report?

A. Residual risks and evaluation against exit criteria B. Only the number of testers C. Unverified claims of zero defects D. Passwords for environments

Question 58

Which configuration information most improves defect reproducibility?

A. Exact build, environment, data snapshot, and flags B. The tester's favourite colour C. An approximate month D. Only the product name

Question 59

What is a baseline?

A. An approved configuration version under change control B. Any unsaved local file C. A failed test only D. A performance metric without context

Question 60

Which defect-report title is most useful?

A. It doesn't work B. Problem C. Checkout charges VAT twice when coupon and express delivery are selected D. Urgent!!!

Question 61

What is defect severity?

A. Urgency of fixing B. Degree of impact C. Age of the report D. Number of attached files

Question 62

A low-impact typo is on tomorrow's national campaign page. What is plausible?

A. Low severity and high priority B. High severity always means low priority C. Severity and priority must be identical D. It cannot be a defect

Question 63

A resolved defect fails its confirmation test. What state is most appropriate?

A. Closed B. Reopened C. Duplicate automatically D. Deferred automatically

Question 64

What is the goal of root cause analysis across defects?

A. Assign blame B. Reduce recurrence by addressing underlying causes C. Increase raw defect counts D. Avoid process change

Question 65

Which is a test-completion activity?

A. Archive reusable testware and record lessons B. Hide unresolved defects C. Discard all traceability D. Remove audit evidence without policy

Question 66

Which tool category primarily supports traceability, planning, and status?

A. Test management tool B. Load generator only C. Compiler only D. Screen reader only

Question 67

What can a static-analysis tool do?

A. Prove the complete system is correct B. Detect selected code patterns without executing the program C. Replace every review D. Simulate real user acceptance automatically

Question 68

Which is a realistic automation benefit?

A. Repeatable frequent regression feedback B. Permanent zero maintenance C. Elimination of test design D. Guaranteed defect-free releases

Question 69

Which is an automation risk?

A. Flaky tests train teams to ignore failures B. Fast deterministic feedback C. Version-controlled scripts D. Clear ownership

Question 70

What should happen first in tool selection?

A. Buy the market leader immediately B. Define the problem and success objectives C. Automate every existing manual step D. Ignore organisational skills

Question 71

Why use a pilot project?

A. To test representative fit before broad rollout B. To avoid defining success criteria C. To guarantee vendor claims D. To skip training

Question 72

A tool gives benefit 500 and costs 400. What is simple ROI?

A. 10% B. 20% C. 25% D. 125%

Question 73

Which cost is often forgotten in automation ROI?

A. Maintenance and failure triage B. Only licence cost C. Benefits D. Risk impact only

Question 74

Which test is usually the best first automation candidate?

A. A stable high-value regression check run often B. A one-off subjective usability interview C. An undefined process D. A feature being redesigned daily at the UI

Question 75

Which statement about the test pyramid is correct?

A. It mandates an exact universal ratio B. It generally favours many fast lower-level tests and fewer end-to-end tests C. It prohibits UI testing D. It applies only to waterfall

Question 76

A requirement says 'results appear quickly.' Which review finding is strongest?

A. The requirement is measurable B. The term quickly is ambiguous and needs a quantified criterion C. No testing is possible anywhere D. It is a code defect

Question 77

Which principle is illustrated by finding most defects in two modules?

A. Defects cluster B. Absence-of-defects fallacy C. Exhaustive testing D. Validation only

Question 78

Which principle applies when a technically correct product solves the wrong business problem?

A. Tests wear out B. Absence-of-defects fallacy C. Defects cluster D. Early testing only

Question 79

What is the strongest oracle for a tax calculation test?

A. A clearly stated applicable tax rule and independently calculated expected result B. The current program output C. A developer's guess D. No expected result

Question 80

Which example is validation?

A. Checking code conforms to a detailed interface specification B. Confirming the workflow enables nurses to administer medicine safely C. Counting statements D. Linting naming conventions

Question 81

Which example is verification?

A. Checking the implemented API response matches its specified schema B. Deciding users enjoy the product C. Choosing a business opportunity D. Predicting sales

Question 82

Which test activity creates executable scripts and organises suites?

A. Analysis B. Implementation C. Completion D. Monitoring only

Question 83

During execution, actual and expected results differ. What should happen first?

A. Automatically blame the developer B. Record and analyse the anomaly C. Change the expected result to pass D. Delete the test

Question 84

Which statement about independence is most accurate?

A. Independent testing always finds every defect B. Different perspectives can improve detection but collaboration remains necessary C. Authors can never test their work D. Only external organisations may test

Question 85

A tester finds a missing requirement during review. What has static testing detected directly?

A. A failure B. A defect C. A production incident D. A branch

Question 86

Which review role records anomalies and decisions?

A. Scribe B. Author C. Customer only D. Tool vendor

Question 87

Which statement about review metrics is best?

A. Use them to punish authors B. Use them carefully for process improvement C. Never collect any D. High defect count proves a bad reviewer

Question 88

For an input with valid values A, B, and C that produce different outcomes, how should EP treat them?

A. Always one valid partition B. Potentially separate partitions because behaviour differs C. All invalid D. Boundaries only

Question 89

A condition combination is impossible in production. How should a decision table handle it?

A. Treat it as a feasible rule automatically B. Identify it as infeasible and exclude it from feasible-rule coverage C. Mark every action D. Convert it to branch coverage

Question 90

What is an invalid transition?

A. An event not permitted from the current state B. Any transition into a valid state C. A covered branch D. An equivalence partition

Question 91

Which set best combines techniques for account lockout?

A. State transitions for attempts and BVA for password length B. Only statement counts C. Only a UI screenshot D. No model because security is involved

Question 92

A suite covers 18 of 20 identified risks. What is risk-item coverage?

A. 2% B. 10% C. 90% D. 110%

Question 93

How many more statements must execute to reach 90% of 50 statements if 42 currently execute?

A. 1 B. 2 C. 3 D. 8

Question 94

How many branches must execute for at least 80% coverage of 15 branches?

A. 8 B. 10 C. 12 D. 14

Question 95

Which prioritisation chooses the next test covering the most not-yet-covered items?

A. Additional-coverage prioritisation B. Random closure C. Severity assignment D. Debugging

Question 96

Why might a lower-risk setup test run before a high-risk end-to-end test?

A. Dependencies may require setup first B. Risk never affects order C. High-risk tests are forbidden D. The plan cannot change

Question 97

Which is an entry criterion?

A. Approved test environment is available B. Residual risk is accepted after testing C. Completion report is delivered D. All planned tests have passed

Question 98

Which is an exit criterion?

A. Testers have accounts before execution B. No open critical defects and target coverage achieved C. Requirements are distributed for review D. The build server exists

Question 99

Which statement about retrospectives is correct?

A. They assign blame for defects B. They identify concrete improvements and successful practices C. They replace defect reports D. They occur only after project cancellation

Question 100

Which result best indicates a trustworthy automation pilot?

A. Many scripts were written B. Defined goals for speed, flakiness, diagnostics, and maintenance were met C. The vendor liked the demo D. No one measured maintenance

Mock Examination Answer Key {.unnumbered}

Detailed Mock Examination Explanations {.unnumbered}

Question 1: B

Correct answer: B — Testing reduces uncertainty but cannot normally prove that no defects remain

Testing supplies evidence and reduces risk, but exhaustive testing and proof of defect absence are normally impossible. Coverage is limited to its defined items. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 2: C

Correct answer: C — Error

The human action or misunderstanding is an error. The wrong period in the requirement is a defect; incorrect retention during operation would be a failure. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 3: B

Correct answer: B — Auditing whether the review process is followed

QA is process-oriented. Auditing adherence to an agreed review process provides confidence in the process, while the other options evaluate the product. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 4: B

Correct answer: B — Debugging

Debugging analyses a failure, locates the defect, and removes it. Testing then confirms the fix and checks for regression. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 5: B

Correct answer: B — Exhaustive testing is impossible

Because every possible combination is normally infeasible, systematic and risk-based selection is necessary. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 6: A

Correct answer: A — Tests wear out

Unchanged tests become less effective at revealing new defect types. Review and extend the suite while retaining useful regression checks. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 7: A

Correct answer: A — Test analysis

Test analysis asks what should be tested and identifies test conditions. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 8: C

Correct answer: C — A test charter created for an exploratory session

A charter is produced during testing and is testware. Regulations and goals are normally part of the test basis. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 9: B

Correct answer: B — It links requirements to tests and tests back to their justification

Bidirectional links support coverage, impact analysis, audit, and explanation of why each test exists. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 10: C

Correct answer: C — Stakeholders need the status and residual risk for a decision

Exit criteria inform completion and release decisions. Authorised stakeholders may accept risk, but the deviation must be visible. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 11: B

Correct answer: B — Links between development work products and corresponding test activities

The V-model maps work products to test levels and supports early analysis and design. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 12: B

Correct answer: B — Iterative refines through cycles; incremental adds pieces

Iterations refine; increments add capability. A lifecycle can employ both. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 13: B

Correct answer: B — Rapid repeatable feedback through a pipeline

Pipelines can provide rapid, repeatable feedback. Human testing and CM remain important. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 14: A

Correct answer: A — Reviewing acceptance criteria before coding

Shift-left brings test activities earlier, such as reviewing and deriving tests before implementation. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 15: B

Correct answer: B — System integration testing

System integration testing targets interfaces between the system under test and external systems. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 16: B

Correct answer: B — Checking backup restoration and monitoring alerts

Operational acceptance includes backup, restore, monitoring, recovery, deployment, and support concerns. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 17: B

Correct answer: B — Confirmation testing

Confirmation testing checks that the specific defect has been fixed. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 18: A

Correct answer: A — Regression testing

It checks connected behaviour for unintended side effects, so it is regression testing. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 19: A

Correct answer: A — Database platform upgrade

Changes to the operational environment, including database upgrades, trigger maintenance testing. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 20: B

Correct answer: B — To identify areas and tests affected by a change

Impact analysis examines consequences and dependencies of a proposed or implemented change. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 21: A

Correct answer: A — A requirement contradicts another requirement

Reviews can directly detect inconsistency without executing software. The other failures normally need dynamic evidence. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 22: A

Correct answer: A — Individual review

After initiation and distribution, reviewers conduct individual review before communication and analysis. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 23: B

Correct answer: B — Author

The author performs rework. The moderator facilitates and the scribe records. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 24: B

Correct answer: B — Walkthrough

In a walkthrough, the author guides participants through the work product. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 25: C

Correct answer: C — Inspection

Inspection uses a defined process, roles, criteria, preparation, documented findings, and metrics. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 26: B

Correct answer: B — Clear objectives and adequate preparation time

Clear scope, preparation, trained participants, and psychological safety improve reviews. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 27: C

Correct answer: C — Three

There is one valid partition and two invalid partitions: below 18, 18-65, and above 65. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 28: B

Correct answer: B — 17, 40, 66

17 represents below range, 40 the valid range, and 66 above range. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 29: B

Correct answer: B — 0, 1, 6, 7

Two-value BVA uses each boundary value and the adjacent value across it: 0/1 and 6/7. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 30: C

Correct answer: C — 7, 8, 9, 19, 20, 21

Three-value BVA uses the boundary and immediate neighbours: 7,8,9 and 19,20,21. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 31: A

Correct answer: A — When combinations of conditions determine actions

Decision tables systematically model combinations of conditions and their outcomes. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 32: B

Correct answer: B — The condition is irrelevant for that rule

A dash is a don't-care entry: either condition value produces the same action in that rule. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 33: C

Correct answer: C — 75%

6 divided by 8 equals 0.75, or 75%. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 34: B

Correct answer: B — State transition model

State transition testing captures history through the current state. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 35: C

Correct answer: C — State coverage may be complete but transition coverage may not be

Multiple transitions can connect states; visiting all states does not ensure every transition was taken. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 36: B

Correct answer: B — Precondition

A precondition states necessary starting context. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 37: C

Correct answer: C — 75%

90/120 x 100 = 75%. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 38: B

Correct answer: B — 70%

7/10 x 100 = 70%. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 39: B

Correct answer: B — 100% branches subsumes 100% statements for reachable code

Taking every branch executes all reachable statements; the reverse is not guaranteed. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 40: A

Correct answer: A — It does not ensure all data combinations or paths

Branch coverage addresses structural outcomes, not every path, value, requirement, oracle, or missing feature. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 41: A

Correct answer: A — Testing duplicate submission because similar products had idempotency defects

Error guessing uses knowledge of past defects and likely failure modes. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 42: B

Correct answer: B — Simultaneous learning, design, and execution

Exploratory testing adapts design and execution as the tester learns; charters and notes add discipline. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 43: B

Correct answer: B — Explore refund concurrency for duplicate postings during a 60-minute session

It states a focused mission, risk, area, and time box. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 44: B

Correct answer: B — The event or action

Given is context, When is event, and Then is expected observable behaviour. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 45: A

Correct answer: A — Derive acceptance tests collaboratively before implementation

ATDD aligns perspectives using concrete acceptance examples before coding. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 46: A

Correct answer: A — Business, development, and testing

The name represents complementary business, development, and testing perspectives, not necessarily exactly three people. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 47: C

Correct answer: C — The only performance specialist is unavailable

Staff unavailability threatens delivery of the project. The other options are product risks. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 48: C

Correct answer: C — Database failover loses committed transactions

Loss of transactions is a quality risk in the product; other choices threaten project execution. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 49: B

Correct answer: B — 12

3 x 4 = 12 under the stated model. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 50: A

Correct answer: A — To allocate testing intensity and priority

Higher risks generally receive earlier or more rigorous testing while dependencies and context are considered. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 51: A

Correct answer: A — Execute resilience tests against provider timeouts

The tests reduce uncertainty and may reveal defects in timeout handling. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 52: A

Correct answer: A — Metrics-based estimation

Metrics-based estimation extrapolates from measured prior work adjusted for context. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 53: B

Correct answer: B — Experts estimate independently then discuss assumptions

Independent estimates reduce anchoring; discussion exposes assumptions and promotes convergence. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 54: A

Correct answer: A — Testing has dependencies and communication overhead

Dependencies, skills, environment limits, and coordination prevent linear scaling. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 55: B

Correct answer: B — Reprioritising tests toward critical risks

Control changes the plan or work in response to monitoring information. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 56: A

Correct answer: A — A 98% pass rate

A high pass rate can hide a catastrophic failed test or low-value test population. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 57: A

Correct answer: A — Residual risks and evaluation against exit criteria

Completion reporting summarises scope, deviations, outcomes, coverage, defects, residual risk, and criteria. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 58: A

Correct answer: A — Exact build, environment, data snapshot, and flags

Exact configuration lets others recreate the conditions that produced the result. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 59: A

Correct answer: A — An approved configuration version under change control

A baseline is an approved reference version changed through controlled procedures. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 60: C

Correct answer: C — Checkout charges VAT twice when coupon and express delivery are selected

The title identifies the affected behaviour and triggering condition concisely. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 61: B

Correct answer: B — Degree of impact

Severity classifies impact. Priority classifies urgency or order. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 62: A

Correct answer: A — Low severity and high priority

Functional impact can be low while deadline and visibility make the fix urgent. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 63: B

Correct answer: B — Reopened

The original failure persists, so the defect should return for investigation, usually as reopened. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 64: B

Correct answer: B — Reduce recurrence by addressing underlying causes

Root cause analysis looks beyond symptoms to preventive process or system improvements. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 65: A

Correct answer: A — Archive reusable testware and record lessons

Completion includes reporting, archiving/hand-over, environment closure, and lessons learned. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 66: A

Correct answer: A — Test management tool

Test management tools support plans, cases, links, execution status, and reporting. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 67: B

Correct answer: B — Detect selected code patterns without executing the program

Static analysis finds detectable patterns and rule violations without execution; interpretation remains necessary. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 68: A

Correct answer: A — Repeatable frequent regression feedback

Automation can provide consistent, frequent execution but requires design and maintenance. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 69: A

Correct answer: A — Flaky tests train teams to ignore failures

Noise undermines trust and can conceal real defects. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 70: B

Correct answer: B — Define the problem and success objectives

Selection begins with the need, users, constraints, and measurable goals. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 71: A

Correct answer: A — To test representative fit before broad rollout

A pilot produces evidence about technical, process, skill, cost, and maintenance fit. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 72: C

Correct answer: C — 25%

(500-400)/400 x 100 = 25%. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 73: A

Correct answer: A — Maintenance and failure triage

Ongoing maintenance, triage, training, infrastructure, and upgrades are material costs. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 74: A

Correct answer: A — A stable high-value regression check run often

Frequency, stability, value, and deterministic results support a strong automation case. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 75: B

Correct answer: B — It generally favours many fast lower-level tests and fewer end-to-end tests

The pyramid is a context-sensitive heuristic favouring fast, focused feedback. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 76: B

Correct answer: B — The term quickly is ambiguous and needs a quantified criterion

The non-measurable term prevents objective verification and should be clarified early. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 77: A

Correct answer: A — Defects cluster

Observed defects are frequently concentrated in a small part of the system. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 78: B

Correct answer: B — Absence-of-defects fallacy

Low defect count cannot compensate for failure to meet user and business needs. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 79: A

Correct answer: A — A clearly stated applicable tax rule and independently calculated expected result

Expected results should come from a trustworthy basis independent enough to detect an incorrect implementation. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 80: B

Correct answer: B — Confirming the workflow enables nurses to administer medicine safely

Validation examines fitness for intended use and stakeholder needs. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 81: A

Correct answer: A — Checking the implemented API response matches its specified schema

Verification checks conformance to specified requirements. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 82: B

Correct answer: B — Implementation

Implementation turns designed tests into executable procedures, scripts, data, and schedules. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 83: B

Correct answer: B — Record and analyse the anomaly

An anomaly may come from product, testware, data, environment, or expectation. Record and analyse it. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 84: B

Correct answer: B — Different perspectives can improve detection but collaboration remains necessary

Independence reduces some cognitive bias and brings perspective, but it has costs and does not replace collaboration. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 85: B

Correct answer: B — A defect

A missing or ambiguous requirement is a defect in a work product; no execution is needed. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 86: A

Correct answer: A — Scribe

The scribe records review findings, decisions, and actions. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 87: B

Correct answer: B — Use them carefully for process improvement

Metrics can reveal process patterns, but punitive use damages psychological safety and distorts behaviour. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 88: B

Correct answer: B — Potentially separate partitions because behaviour differs

Partitioning is based on expected treatment, not merely validity. Different outcomes imply distinct partitions. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 89: B

Correct answer: B — Identify it as infeasible and exclude it from feasible-rule coverage

Impossible combinations should be documented and not counted as feasible rules, assuming the model is correct. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 90: A

Correct answer: A — An event not permitted from the current state

State models define which events are valid in each state; invalid-transition tests challenge forbidden events. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 91: A

Correct answer: A — State transitions for attempts and BVA for password length

Different risks require complementary techniques. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 92: C

Correct answer: C — 90%

18/20 x 100 = 90%. The metric says nothing by itself about test depth. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 93: C

Correct answer: C — 3

90% of 50 is 45. Three additional previously unexecuted statements are required. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 94: C

Correct answer: C — 12

0.8 x 15 = 12 branches. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 95: A

Correct answer: A — Additional-coverage prioritisation

Additional-coverage prioritisation greedily increases new coverage with each selection. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 96: A

Correct answer: A — Dependencies may require setup first

Prerequisites and dependencies constrain execution order even under risk-based prioritisation. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 97: A

Correct answer: A — Approved test environment is available

Environment availability is a precondition to start. The others are more typical exit/completion concerns. Option B is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 98: B

Correct answer: B — No open critical defects and target coverage achieved

Defect status and target coverage are common measurable completion conditions. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 99: B

Correct answer: B — They identify concrete improvements and successful practices

Retrospectives support continuous improvement through evidence, actions, owners, and follow-up. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Question 100: B

Correct answer: B — Defined goals for speed, flakiness, diagnostics, and maintenance were met

Success must be evaluated against measurable outcomes, not output volume. Option A is not the best answer because it does not match the defined concept or the scenario's objective. Option C is not the best answer because it does not match the defined concept or the scenario's objective. Option D is not the best answer because it does not match the defined concept or the scenario's objective.

Last-Minute Revision Guide {.unnumbered}

This section is designed for the final days before the examination. It is deliberately compact, but it still explains the reasoning behind the high-yield distinctions.

Revision Page 1: The Testing Mindset

Testing evaluates quality and reduces uncertainty. It can reveal failures and defects but cannot prove a non-trivial system is defect-free. Always ask: What is the objective? What risk matters? What evidence would change a decision? Passing tests mean only that the tested conditions produced acceptable observed results.

Trap: “All planned tests passed” is not equivalent to “the product is correct.” The plan may be incomplete, the oracle wrong, the environment unrepresentative, or the requirements unsuitable.

Revision Page 2: Error, Defect, Failure, Root Cause

Human error creates or overlooks a defect in a work product. When activated under conditions, that defect may cause a failure. Root cause is deeper: why was the error likely or why did controls fail? Use this chain in scenario questions.

Trap: Static review directly finds a requirement defect without a failure.

Revision Page 3: Objectives and Principles

Objectives include evaluation, defect finding, coverage, risk reduction, compliance, verification, validation, decision information, and confidence. Memorise all seven principles and be able to recognise examples. The most confused principles are tests wear out versus defect clustering, and early testing versus shift-left. Shift-left is an approach supported by the early-testing principle.

Revision Page 4: Activities

Planning selects objectives and approach. Monitoring observes; control acts. Analysis finds what to test. Design specifies how. Implementation builds executable testware. Execution runs and compares. Completion reports, archives, hands over, and learns.

Trap: Creating automated scripts is implementation, even though design choices are involved.

Revision Page 5: Traceability and Roles

Trace from requirements/risks to conditions, cases, results, and defects; trace back from a test to its reason. Test management has leadership for the test process. Testing roles focus on engineering tasks. In whole-team contexts, roles can be distributed, but accountability and necessary skills remain.

Revision Page 6: Lifecycle Models

Sequential models make early static work crucial. The V-model links development work products to test levels. Iterative means refine repeatedly; incremental means add capability. Agile integrates testing into team work. DevOps combines development and operations with automation and rapid feedback. None eliminates independent thought, manual exploration, or later testing.

Revision Page 7: Test Levels

Component = isolated unit. Component integration = interfaces among internal components. System = full system capability. System integration = interfaces with external systems. Acceptance = stakeholder and operational readiness. Determine level from object and objective, not executor.

Revision Page 8: Test Types

Functional asks what. Non-functional asks how well. Black-box uses external specification. White-box uses internal structure. Confirmation checks the exact fix. Regression looks for unintended effects. The same test level can contain several test types.

Revision Page 9: Maintenance

Triggers include fixes, enhancements, migrations, platform changes, retirement, data conversion, and changed environment. Impact analysis identifies affected items and tests. Maintenance difficulty grows when documentation, architecture knowledge, traceability, and reusable testware are weak.

Revision Page 10: Static Testing

Static means no execution. Reviews use humans; static analysis uses tools. Static finds ambiguity, inconsistency, omission, duplication, standards deviations, and some code issues early. It complements dynamic testing.

Review order: plan, initiate, individual review, communicate/analyse, rework/report, follow-up. Author fixes. Moderator facilitates. Scribe records. Walkthrough is author-led. Inspection is most formal.

Revision Page 11: Equivalence Partitioning

Partition by expected common handling. Cover valid and invalid partitions. Representatives need not be boundaries. If valid enumerated values lead to different outcomes, they are separate partitions for that model.

Trap: {18,40,65} does not cover invalid partitions for age 18–65.

Revision Page 12: Boundary Value Analysis

Draw the range. For inclusive 18–65, 2-value is 17,18,65,66; 3-value is 17,18,19,64,65,66. Include boundaries between business bands, not just outer validation bounds.

Trap: Do not confuse “two-value” with “two tests total.” It is two values per boundary.

Revision Page 13: Decision Tables

Conditions above, actions below, rules in columns. Remove infeasible columns. Merge only when the differing condition cannot affect action; mark it -. Coverage generally concerns feasible rules. One test can represent each rule.

Revision Page 14: State Transitions

Current state + event determines next state and action. State coverage is weaker than transition coverage. Invalid-transition testing challenges forbidden events. Look for counters, lifecycle statuses, protocols, sessions, and history-dependent behaviour.

Revision Page 15: White-Box Coverage

Coverage = covered items / total items x 100. Branch coverage subsumes statement coverage for reachable code, but statement does not subsume branch. Neither proves requirement coverage, path coverage, data coverage, or correctness.

Round up when calculating the integer number of items needed to meet a target percentage.

Revision Page 16: Experience and Collaboration

Error guessing uses experience and defect taxonomies. Checklist testing uses maintained high-level reminders. Exploratory testing learns, designs, and executes together under a mission. ATDD creates acceptance tests collaboratively before coding. BDD expresses observable examples, often Given-When-Then. Three Amigos brings business, development, and test perspectives.

Revision Page 17: Risk and Estimation

Product risk threatens product quality; project risk threatens delivery. Risk level commonly combines likelihood and impact. Testing mitigates risk by reducing uncertainty and exposing defects; it cannot remove all risk. Metrics-based estimates use history; expert-based estimates use judgement. Include all test activities, not only execution.

Revision Page 18: Monitoring and Reporting

Monitoring compares actual with plan; control changes work. Pair every metric with purpose, trend, scope, and risk. Progress reports guide current work. Completion reports summarise achieved coverage, defects, deviations, residual risk, criteria, and lessons.

Revision Page 19: CM and Defects

Configuration management answers “exactly what produced this result?” Record versions of application, requirements, tests, data, environment, and flags. A defect report must be reproducible and decision-useful. Severity is impact; priority is urgency. A failed confirmation reopens the defect.

Revision Page 20: Tools

Tools support management, execution, static analysis, CI/CD, performance, data, services, and other activities. Benefits are repeatability, scale, speed, and information. Risks are unrealistic expectations, maintenance, flakiness, lock-in, insecure data, poor fit, and false confidence. Define the problem, evaluate fit, pilot, measure, then roll out.

Final Trap List

1. Testing does not prove absence of defects.
2. Debugging is not testing.
3. QA is process-oriented; testing is product-oriented quality control.
4. Analysis is “what”; design is “how”; implementation makes tests executable.
5. Exit criteria inform a decision; they do not mechanically make it.
6. Test level depends on object and objective, not the person's job title.
7. Confirmation checks a fix; regression checks side effects.
8. Static testing includes reviews and static analysis.
9. Walkthrough is author-led; inspection is most formal.
10. EP partitions are behaviour groups; BVA targets edges.
11. A decision-table dash is don't-care, not false.
12. All-state coverage is not all-transition coverage.
13. Branch coverage is stronger than statement coverage but still incomplete.
14. Exploratory testing is structured learning, not random clicking.
15. Product risk is not project risk.
16. Severity is not priority.
17. Monitoring observes; control acts.
18. More defect reports can mean more effective testing, not worse development alone.
19. Automation has continuing costs and does not replace judgement.
20. Read whether the question asks for the best, first, most likely, or least appropriate answer.

Final Exam Strategy Guide {.unnumbered}

Time Management

For 40 questions in 60 minutes, the average is 90 seconds per question. Use three passes:

1. First pass (about 35–40 minutes): answer straightforward questions immediately. Mark calculations or uncertain items and move on.
2. Second pass (about 15–20 minutes): solve flagged questions carefully, drawing partitions, tables, or calculations on permitted material.
3. Final pass (about 5 minutes): confirm every question has one answer, check negatives such as “NOT” or “least,” and revisit only where you have a concrete reason.

If you receive 75 minutes, keep the same discipline; allocate the extra time mainly to K3 calculations and review.

Elimination Technique

Read the stem before the options and identify the target concept. Eliminate statements that are absolute without justification (“always proves,” “eliminates all”), attach a correct fact to the wrong concept, reverse two terms, or fail the scenario's objective. Then compare remaining options against precise syllabus meaning.

Do not choose an answer merely because it is true in general. The exam asks for the best answer to the specific question.

Handling Calculations

Write the formula first. Identify numerator and denominator. For a required number of coverage items, multiply the target by total and round up to the next whole item. For BVA, draw a number line. For decision tables, count only feasible rules when the question defines them. For state transitions, list transitions rather than counting only states.

Handling Difficult Questions

Translate long scenarios into nouns and verbs: object, state, event, risk, objective, and requested decision. If two options remain, state why each could be wrong. Prefer the option matching the defined term and stated objective rather than adding assumptions.

Never leave an answer blank when there is no penalty for an incorrect choice. Mark your best option, flag it, and return later.

Reviewing Answers

Change an answer only when you identify a misread word, calculation error, or stronger conceptual reason. Anxiety alone is not evidence. Check that your selected option corresponds to the requested letter and that all questions are answered.

Common CTFL Mistakes

• Learning definitions without practising scenarios.
• Memorising sample answers instead of understanding distractors.
• Importing company-specific terminology into the exam.
• Ignoring invalid partitions and transitions.
• Confusing coverage percentage with quality.
• Assuming roles determine test levels.
• Treating tools as replacements for people and process.
• Spending too long on one question.
• Failing to notice qualifiers: best, first, most, least, primarily, or NOT.

Final Readiness Checklist

You are ready when you can:

• explain every bold term without notes;
• distinguish every pair in the confusion table;
• derive EP, 2-value BVA, 3-value BVA, decision-table, and state-transition tests;
• calculate statement and branch coverage accurately;
• score at least 80% on fresh practice, leaving margin above 65%;
• explain why each wrong option is wrong;
• complete official 40-question samples within your allowed time;
• identify your recurring error patterns and correct them.

Closing Note {.unnumbered}

Certification rewards precise vocabulary and disciplined application. Professional testing requires the same foundation plus curiosity, courage, empathy for users, technical skill, and clear communication. Use the exam preparation to build habits that remain useful after the certificate: question ambiguity early, select tests deliberately, trace evidence to risk, and report uncertainty honestly.