ISTQB

ISTQB CTFL › Sample paper 3 (40 questions) Syllabus v4.0.1 · updated 3 Nov 2026

Chapter 1: Fundamentals of Testing

Chapter 2: Testing Throughout the SDLC

Chapter 3: Static Testing

Chapter 4: Test Analysis and Design

Chapter 5: Managing the Test Activities

Chapter 6: Test Tools

How did you do?

Answer key

Count one point per correct answer. 26 or more out of 40 is a pass (65%). Aim for 32 or more before you book the real exam.

This paper: 40 questions (8 × K1, 24 × K2, 8 × K3).

ISTQB CTFL › Sample paper 2 (40 questions) Syllabus v4.0.1 · updated 3 Nov 2026

Chapter 1: Fundamentals of Testing

Chapter 2: Testing Throughout the SDLC

Chapter 3: Static Testing

Chapter 4: Test Analysis and Design

Chapter 5: Managing the Test Activities

Chapter 6: Test Tools

How did you do?

Answer key

Count one point per correct answer. 26 or more out of 40 is a pass (65%). Aim for 32 or more before you book the real exam.

This paper: 40 questions (8 × K1, 24 × K2, 8 × K3).

ISTQB CTFL › Sample paper 1 (40 questions) Syllabus v4.0.1 · updated 3 Nov 2026

Chapter 1: Fundamentals of Testing

Chapter 2: Testing Throughout the SDLC

Chapter 3: Static Testing

Chapter 4: Test Analysis and Design

Chapter 5: Managing the Test Activities

Chapter 6: Test Tools

How did you do?

Answer key

Count one point per correct answer. 26 or more out of 40 is a pass (65%). Aim for 32 or more before you book the real exam.

This paper: 40 questions (8 × K1, 24 × K2, 8 × K3).

ISTQB CTFL › 6. Test Tools Syllabus v4.0.1 · updated 3 Nov 2026

Keyword to remember (K1): test automation.

6.1 Tool support for testing (K2)

Tools support many test activities. The syllabus lists these categories:

6.2 Benefits and risks of test automation (K1)

Buying a tool does not guarantee success. Every tool needs effort to introduce, maintain and train people on, and its risks must be analysed and mitigated.

Learning objectives checklist

You have finished the study material. Now test yourself with Sample paper 1, a full 40-question paper in the real exam split.

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

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

5.1 Test planning

5.1.1 Purpose and content of a test plan (K2)

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

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

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

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

5.1.3 Entry criteria and exit criteria (K2)

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

5.1.4 Estimation techniques (K3)

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

Worked example: three-point estimation

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

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

Worked example: extrapolation

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

5.1.5 Test case prioritization (K3)

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

Two constraints override pure priority:

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

Worked example

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

5.1.6 Test pyramid (K1)

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

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

5.1.7 Testing quadrants (K2)

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

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

5.2 Risk management

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

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

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

5.2.1 Risk definition and attributes (K1)

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

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

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

5.2.2 Project risks and product risks (K2)

5.2.3 Product risk analysis (K2)

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

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

Results of product risk analysis are used to:

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

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

5.2.4 Product risk control (K2)

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

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

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

Ways to mitigate product risk by testing:

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

5.3 Test monitoring, test control and test completion

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

Examples of control directives:

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

5.3.1 Metrics used in testing (K1)

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

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

5.3.3 Communicating the status of testing (K2)

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

5.4 Configuration management (K2)

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

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

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

5.5 Defect management (K3)

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

Defect reports aim to:

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

A defect report from dynamic testing typically includes:

Learning objectives checklist

Next: Chapter 6: Test Tools.

ISTQB CTFL › 4. Test Analysis and Design Syllabus v4.0.1 · updated 3 Nov 2026

Keywords to remember (K1): acceptance criteria, acceptance test-driven development, black-box test technique, boundary value analysis, branch coverage, checklist-based testing, collaboration-based test approach, coverage, coverage item, decision table testing, equivalence partitioning, error guessing, experience-based test technique, exploratory testing, state transition testing, statement coverage, test technique, white-box test technique.

4.1 Test techniques overview (K2)

Test techniques help testers decide what to test (test analysis) and how to test (test design). They produce a small but sufficient set of test cases in a systematic way, and help identify test conditions, coverage items and test data.

The syllabus groups techniques into three families:

A fourth group, collaboration-based approaches (section 4.5), focuses on avoiding defects through collaboration and communication.

4.2 Black-box test techniques

4.2.1 Equivalence partitioning (K3)

Equivalence partitioning (EP) splits data into partitions whose members are expected to be processed the same way. If one value in a partition reveals a defect, any other value in it should too, so one test per partition is enough.

Rules from the syllabus:

• Partitions can be found for inputs, outputs, configuration items, internal values, time values and interface parameters.
• They can be continuous or discrete, ordered or unordered, finite or infinite.
• Partitions must not overlap and must not be empty.
• Valid partitions hold values that should be processed; invalid partitions hold values that should be rejected or ignored (teams may define these slightly differently).
• Coverage items = partitions, including invalid ones.
• EP coverage = partitions exercised ÷ partitions identified × 100%.

Worked example 1: a single input

A loyalty program gives 1 point per ₹100 for orders of ₹100 to ₹10,000 (whole rupees). Orders below ₹100 earn no points, and orders above ₹10,000 need manager approval.

Four test cases give 100% EP coverage. If only 50, 2,500 and 15,000 were tested, coverage would be 3 ÷ 4 = 75%.

Worked example 2: several inputs and Each Choice coverage

When a test item has several sets of partitions, the simplest criterion is Each Choice coverage: every partition of every set is exercised at least once, without caring about combinations.

Checkout: payment method {card, UPI, net banking} and delivery {standard, express}.

Three tests cover all 3 + 2 = 5 partitions. The minimum for Each Choice is the size of the largest set, here 3.

4.2.2 Boundary value analysis (K3)

Boundary value analysis (BVA) tests the edges of ordered partitions, because developers often misplace or forget boundaries (for example writing < instead of ≤). The boundary values are the minimum and maximum of each partition, including invalid partitions.

3-value BVA is more rigorous. For example, if x ≤ 10 is wrongly coded as x = 10, the 2-value tests 10 and 11 both behave correctly, but the 3-value test 9 exposes the defect.

Worked example: password length

A password must be 8 to 16 characters long.

Partitions: ≤ 7 (invalid), 8 to 16 (valid), ≥ 17 (invalid). Boundary values: 7, 8, 16, 17.

How the 3-value set is built: for 7 → 6, 7, 8; for 8 → 7, 8, 9; for 16 → 15, 16, 17; for 17 → 16, 17, 18. Duplicates are removed, leaving 8 values.

4.2.3 Decision table testing (K3)

Decision tables test requirements where combinations of conditions lead to different actions, such as business rules.

• Conditions and actions are the rows; each column is a decision rule (one combination).
• Limited-entry tables use only true/false; extended-entry tables allow ranges, partitions or multiple values.
• Notation: T = true, F = false, – = irrelevant, N/A = infeasible; for actions X = happens, blank = does not happen.
• A full table has a column for every combination: with n Boolean conditions, 2ⁿ columns.
• Columns with infeasible combinations can be deleted, and columns where a condition does not matter can be merged (minimisation algorithms are out of scope).
• Coverage items = feasible columns. Coverage = columns exercised ÷ feasible columns.

Strengths: systematic, finds missing combinations, and reveals gaps and contradictions in requirements. Weakness: the number of rules grows exponentially, so large tables may need minimisation or a risk-based selection.

Worked example: delivery and discount rules

Free delivery if the customer is a member OR the order is over ₹999. An extra 5% discount only if the customer is a member AND pays online.

Three conditions → 2³ = 8 rules, all feasible, so 100% decision table coverage needs 8 test cases. If a test suite exercised only R1, R4 and R8, coverage would be 3 ÷ 8 = 37.5%.

Merging example: R7 and R8 have the same actions and differ only in C3, so they could be merged into one column “F, F, –”.

4.2.4 State transition testing (K3)

A state diagram models a system’s states and the valid transitions between them. A transition is triggered by an event, may have a guard condition, and may cause an action: written as event [guard] / action. A state table shows the same model as a grid (states × events); empty cells are invalid transitions, which the diagram does not show.

Three coverage criteria:

Test only one invalid transition per test case to avoid defect masking (one defect hiding another).

Worked example: article publishing workflow

States: Draft, In review, Approved, Published. Valid transitions:

State table (blank = invalid):

• All states: one test, submit → approve → publish, visits all 4 states.
• Valid transitions: that test misses reject. One longer test, submit → reject → submit → approve → publish, covers all 4 valid transitions.
• All transitions: 4 × 4 = 16 cells, of which 12 are invalid. Each invalid transition needs its own test case, so you need at least 12 test cases; the valid transitions can be covered inside them on the way to each invalid attempt.

4.3 White-box test techniques

4.3.1 Statement testing and statement coverage (K2)

Coverage items = executable statements. Statement coverage = statements exercised ÷ executable statements.

100% statement coverage means every statement ran at least once, so any statement with a defect was executed. But it does not guarantee finding every defect (for example a division by zero that only fails for one value), and it does not ensure all decision logic was tested.

4.3.2 Branch testing and branch coverage (K2)

A branch is a transfer of control between two nodes in the control flow graph: either unconditional (straight-line) or conditional (a decision outcome, such as true/false of an if, a case, or exiting or continuing a loop).

Coverage items = branches. Branch coverage = branches exercised ÷ total branches.

Branch coverage subsumes statement coverage: 100% branch coverage always gives 100% statement coverage, but not the other way round. Even 100% branch coverage may miss defects that need a specific path.

Worked example

1  read amount
2  if amount > 1000 then
3      discount = amount * 0.1
4  end if
5  print amount - discount

• One test with amount = 1500 executes every statement → 100% statement coverage. But it only takes the true outcome of the decision; the false branch (skipping line 3) is never exercised, so branch coverage is below 100%.
• Adding a test with amount = 500 takes the false branch → 100% branch coverage with 2 tests.
• Notice the defect the second test reveals: when the false branch runs, discount was never initialised. Statement coverage alone missed it.

4.3.3 The value of white-box testing (K2)

4.4 Experience-based test techniques

4.4.1 Error guessing (K2)

The tester anticipates errors, defects and failures using knowledge of how the application behaved before, the mistakes developers tend to make, and failures in similar applications. Typical problem areas: input (valid input rejected, missing parameters), output (wrong format or result), logic (missing cases, wrong operator), computation, interfaces (parameter mismatch) and data (wrong initialisation or type).

Fault attacks are a structured way to do error guessing: build a list of likely errors, defects and failures, then design tests to expose them.

Example list for a date field: 29 February in a non-leap year, 31 April, an empty value, a year with two digits, a date far in the future, a date in another format.

4.4.2 Exploratory testing (K2)

Tests are designed, executed and evaluated at the same time while the tester learns about the test object. Often organised as session-based testing:

• A fixed time box (for example 60 minutes)
• A test charter with the test objectives to guide the session
• Test session sheets to note steps and discoveries
• A debriefing with stakeholders afterwards

Most useful when specifications are poor or there is time pressure, and as a complement to formal techniques. It works best with experienced testers who have domain knowledge, analytical skill, curiosity and creativity, and it can use other techniques such as EP inside a session.

Example charter: “Explore the coupon feature with expired, stacked and case-varied codes to discover pricing errors.”

4.4.3 Checklist-based testing (K2)

The tester designs and runs tests to cover conditions from a checklist, built from experience, knowledge of what matters to users, or an understanding of why software fails.

Good checklists:

• Phrase items as questions that can be checked separately and directly.
• Do not include items that can be checked automatically, items better used as entry or exit criteria, or items that are too general.
• Are updated regularly from defect analysis, because items wear out as developers learn to avoid those errors, while staying reasonably short.

They support functional and non-functional testing (for example usability heuristics). High-level checklists give some consistency without detailed test cases, with more variability: potentially greater coverage but less repeatability.

4.5 Collaboration-based test approaches

These approaches aim at defect avoidance through collaboration and communication, not only defect detection.

4.5.1 Collaborative user story writing (K2)

A user story describes a feature valuable to a user or purchaser. It has three critical aspects, the 3 C’s:

Common format: “As a [role], I want [goal], so that [business value]”, followed by the acceptance criteria. Business, development and testing write it together, using techniques such as brainstorming and mind mapping, to get a shared vision.

Good stories follow INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable. If a stakeholder cannot say how to test a story, it may be unclear, may not be valuable to them, or they may just need help with testing.

4.5.2 Acceptance criteria (K2)

Acceptance criteria are the conditions an implementation must meet to be accepted by stakeholders; they can be seen as the test conditions for the story. They usually come out of the Conversation.

They are used to: define the scope of the story, reach consensus among stakeholders, describe positive and negative scenarios, serve as the basis for acceptance testing, and allow accurate planning and estimation.

Teams may use other formats as long as the criteria are well-defined and unambiguous.

4.5.3 Acceptance test-driven development (ATDD) (K3)

ATDD is a test-first approach: test cases are written before the story is implemented, by people with different perspectives (customers, developers, testers).

1. Specification workshop: analyse, discuss and write the user story and its acceptance criteria; resolve gaps and ambiguities.
2. Create test cases from the acceptance criteria (as a team or by the tester). These are examples of how the software works. Techniques from 4.2 to 4.4 can be used.
3. Order: positive tests first, then negative tests, then non-functional characteristics.
4. Write tests in language stakeholders understand: preconditions, inputs and postconditions.
5. Tests must cover all characteristics of the story, must not go beyond it, and no two tests should describe the same characteristic.
6. In a format an automation framework supports, developers can automate them as they build the feature, making them executable requirements.

Worked example

Story: As a shopper, I want to save items for later, so that I can buy them another day. Acceptance criteria: (1) a “Save for later” button moves an item from the cart to a saved list; (2) saved items stay after logout and login; (3) a saved item that goes out of stock shows “Out of stock” and cannot be moved back to the cart.

A test such as “the saved list loads in under 1 second” would be a non-functional test that comes after these, and only if it is part of the story’s acceptance criteria. A test for “share the saved list by email” would go beyond the story and should not be included.

Learning objectives checklist

Next: Chapter 5: Managing the Test Activities.

ISTQB CTFL › 3. Static Testing Syllabus v4.0.1 · updated 3 Nov 2026

Keywords to remember (K1): anomaly, dynamic testing, formal review, informal review, inspection, review, static analysis, static testing, technical review, walkthrough.

3.1 Static testing basics

In static testing the software is not executed. Work products such as code, specifications or architecture documents are examined either manually (reviews) or with tools (static analysis). The objectives include improving quality, detecting defects and assessing characteristics such as readability, completeness, correctness, testability and consistency. Static testing supports both verification and validation.

In Agile teams, testers, business representatives (product owner, business analyst) and developers work together in example mapping, collaborative user story writing and backlog refinement to make sure user stories meet criteria such as the Definition of Ready. Testers ask questions that expose gaps, so stories end up complete, understandable and with testable acceptance criteria.

Static analysis finds problems before dynamic testing, often with less effort because no test cases are needed. It is usually tool-based and often runs inside CI pipelines. Besides code defects, it evaluates maintainability and security. Spell checkers and readability tools are also static analysis tools.

3.1.1 Work products examinable by static testing (K1)

Almost any work product can be statically tested: requirement specifications, source code, test plans, test cases, product backlog items, test charters, project documentation, contracts and models.

Not suitable: work products that are hard for people to interpret and that should not be analysed by tools, for example third-party executable code (for legal reasons).

3.1.2 Value of static testing (K2)

• Finds defects in the earliest phases of the SDLC (early testing principle).
• Finds defects that dynamic testing cannot, such as unreachable code, design patterns not implemented as intended, and defects in non-executable work products.
• Evaluates quality and builds confidence in work products; stakeholders can check that requirements describe their real needs.
• Creates a shared understanding and better communication among stakeholders, so a wide variety of stakeholders should take part.
• Reviews cost effort, but overall project cost is usually much lower than without reviews, because less time is spent fixing defects later.
• Static analysis finds some code defects more efficiently than dynamic testing, leading to fewer defects and less development effort overall.

3.1.3 Static testing vs dynamic testing (K2)

They complement each other and share objectives, but they differ:

Defects that are easier or cheaper to find with static testing:

3.2 Feedback and review process

3.2.1 Benefits of early and frequent stakeholder feedback (K1)

Early and frequent feedback surfaces quality problems early. Without it, the product may not match what stakeholders originally wanted or want now, leading to costly rework, missed deadlines, blame games and even project failure.

Frequent feedback prevents misunderstandings about requirements, makes sure requirement changes are understood and implemented sooner, helps the team understand what it is building, and lets it focus on the features with the most value and the biggest effect on identified risks.

3.2.2 Review process activities (K2)

The ISO/IEC 20246 standard describes a generic review process that teams tailor. More formal reviews perform more of the tasks. Large work products may need several passes through the process.

3.2.3 Roles and responsibilities in reviews (K1)

3.2.4 Review types (K2)

The right level of formality depends on the SDLC, process maturity, criticality and complexity of the work product, legal or regulatory needs and the need for an audit trail. The same work product can be reviewed several times, first informally and later formally.

3.2.5 Success factors for reviews (K1)

• Clear objectives and measurable exit criteria; evaluating the participants must never be an objective.
• Choose the right review type for the objectives, work product, participants and context.
• Review small chunks so reviewers stay focused.
• Give feedback to stakeholders and authors so they can improve.
• Give participants enough time to prepare.
• Management support for the review process.
• Make reviews part of the organisation’s culture, promoting learning and process improvement.
• Train all participants in their roles.
• Facilitate meetings.

Learning objectives checklist

Next: Chapter 4: Test Analysis and Design.

ISTQB CTFL › 2. Testing Throughout the SDLC Syllabus v4.0.1 · updated 3 Nov 2026

Keywords to remember (K1): acceptance testing, black-box testing, component integration testing, component testing, confirmation testing, functional testing, integration testing, maintenance testing, non-functional testing, regression testing, shift left, system integration testing, system testing, test level, test object, test type, white-box testing.

2.1 Testing in the context of an SDLC

An SDLC model is a high-level picture of how software development is organised: which phases and activities exist and how they relate in logic and time.

On top of these models, teams use more detailed methods and Agile practices such as ATDD, BDD, domain-driven design (DDD), Extreme Programming (XP), feature-driven development (FDD), Kanban, Lean IT, Scrum and TDD.

2.1.1 Impact of the SDLC on testing (K2)

Testing must fit the chosen SDLC. The SDLC affects:

• the scope and timing of test activities (test levels and test types),
• the level of detail of test documentation,
• the choice of test techniques and test approach,
• the extent of test automation, and
• the role and responsibilities of the tester.

2.1.2 Good testing practices for every SDLC (K1)

Whatever the lifecycle:

1. Every development activity has a matching test activity, so everything is subject to quality control.
2. Each test level has its own specific objectives, so testing is thorough without being redundant.
3. Test analysis and design for a level starts during the matching development phase (early testing).
4. Testers review work products as soon as drafts exist, which supports shift left.

2.1.3 Testing as a driver for development: TDD, ATDD and BDD (K1)

In these test-first approaches, tests are written before the code and guide development. All three apply early testing, follow shift left and support iterative development. The tests often stay as automated tests to protect future changes and refactoring.

Example BDD scenario:

Given a registered customer with ₹500 in their wallet When they buy an item costing ₹200 using the wallet Then the wallet balance shows ₹300

2.1.4 DevOps and testing (K2)

DevOps brings development (including testing) and operations together around common goals. It needs a cultural shift and promotes team autonomy, fast feedback, integrated toolchains and practices such as continuous integration (CI) and continuous delivery (CD), delivered through a DevOps pipeline.

2.1.5 Shift left (K2)

Shift left is another name for the principle of early testing: do testing earlier in the SDLC instead of waiting for code or integration. It does not mean that later testing can be skipped.

Good shift-left practices:

• Testers review specifications, finding ambiguities, gaps and inconsistencies.
• Write test cases before the code and run the code in a test harness while it is being written.
• Use CI, and better still CD, for fast feedback with automated component tests on every commit.
• Run static analysis on source code before dynamic testing, or automatically in the pipeline.
• Start non-functional testing at the component level where possible, instead of waiting for a complete system.

Shift left may cost extra training, effort and money early, but it is expected to save more later. Stakeholders must buy into it.

2.1.6 Retrospectives and process improvement (K2)

A retrospective is a meeting, often at the end of an iteration, release or project (or whenever needed), where the whole team (testers, developers, architects, product owner, business analysts) discusses:

• What went well and should be kept?
• What did not go well and could be improved?
• How do we apply the improvements and keep the successes?

Results are recorded, normally in the test completion report, and actions must be followed up.

Benefits for testing: more effective and efficient testing, better testware, team bonding and learning, a better test basis (requirements gaps get fixed), and better cooperation between development and testing.

2.2 Test levels and test types

A test level is a group of test activities organised and managed together, for software at a given stage, from single components to whole systems or systems of systems. Each test level is an instance of the test process. A test type is a group of test activities aimed at specific quality characteristics; most test types can be done at every test level.

In sequential models, the exit criteria of one level are often part of the entry criteria for the next. In iterative models this may not apply, and levels can overlap in time.

2.2.1 The five test levels (K2)

Forms of acceptance testing: user acceptance testing (UAT), operational acceptance testing, contractual and regulatory acceptance testing, alpha testing and beta testing.

Test levels are told apart by their test object, test objectives, test basis, defects and failures, and approach and responsibilities.

Example for an online food-delivery app:

• Component test: the function that calculates the delivery fee.
• Component integration test: the cart service correctly passes items to the pricing service.
• System test: a customer can search, order, pay and track an order end to end, and the app responds within 2 seconds.
• System integration test: the app talks correctly to the payment gateway and the maps API.
• Acceptance test: restaurant owners and customers confirm the app supports their real workflow.

2.2.2 The four test types (K2)

The ISO/IEC 25010 non-functional quality characteristics listed in the syllabus:

• Performance efficiency
• Compatibility
• Usability (also called interaction capability)
• Reliability
• Security
• Maintainability
• Portability (also called flexibility)
• Safety

Non-functional testing can start early (in reviews or component testing). Many non-functional tests reuse functional tests but add a constraint, for example “the search must return results in under 1 second”. Finding non-functional defects late can seriously threaten a project, and some tests need special environments such as a usability lab.

All four test types can be applied at all test levels, with a different focus at each level.

2.2.3 Confirmation testing and regression testing (K2)

Both are needed at every test level where defects are fixed or changes are made. In CI and DevOps, automated regression tests should be part of the pipeline.

2.3 Maintenance testing (K2)

Once software is in operation, changes keep coming. Maintenance can be corrective, adaptive (to changes in the environment) or aimed at improving performance or maintainability. Releases can be planned or unplanned (hot fixes).

Maintenance testing checks both that the change works and that the unchanged parts (usually most of the system) still work. Impact analysis can be done before a change to decide whether to make it at all.

The scope of maintenance testing depends on:

• the risk of the change,
• the size of the existing system, and
• the size of the change.

Learning objectives checklist

Next: Chapter 3: Static Testing.

ISTQB CTFL › 1. Fundamentals of Testing Syllabus v4.0.1 · updated 3 Nov 2026

Keywords to remember (K1): coverage, debugging, defect, error, failure, quality, quality assurance, root cause, test analysis, test basis, test case, test completion, test condition, test control, test data, test design, test execution, test implementation, test monitoring, test object, test objective, test planning, test procedure, test process, test result, testing, testware, traceability, validation, verification.

1.1 What is testing?

Software testing is a set of activities to find defects and evaluate the quality of software work products. Whatever is being tested is called the test object: a piece of code, a whole system, a requirement document or a user story.

Two misconceptions appear in exam questions again and again:

1. “Testing is just running tests.” Running the software is only one activity. Testing also includes planning, analysing requirements, designing test cases, reviewing documents, reporting and learning lessons.
2. “Testing only checks that the system meets the specification.” That is verification. Testing also includes validation: checking that the system meets users’ and stakeholders’ real needs in its operational environment.

Testing can be static (no execution: reviews and static analysis, see chapter 3) or dynamic (the software is executed, see chapter 4). It is also a managed activity that needs planning, estimating, monitoring and control (chapter 5), and it uses tools (chapter 6). Above all, testing is an intellectual activity that needs specialist knowledge, analytical skill, critical thinking and systems thinking.

1.1.1 Test objectives (K1)

Typical objectives of testing:

• Evaluating work products such as requirements, user stories, designs and code
• Causing failures and finding defects
• Ensuring the required coverage of a test object
• Reducing the risk of inadequate software quality
• Verifying that specified requirements are fulfilled
• Verifying compliance with contractual, legal and regulatory requirements
• Providing information so stakeholders can make informed decisions
• Building confidence in the quality of the test object
• Validating that the test object is complete and works as stakeholders expect

The objectives change with the context: the work product, the test level, the risks, the SDLC, and business factors such as time to market. For example, component testing mainly aims to find defects early, while acceptance testing mainly aims to build confidence and support a release decision.

1.1.2 Testing and debugging (K2)

Testing and debugging are separate activities done for different reasons.

When a dynamic test triggers a failure, debugging usually involves three steps: reproduce the failure, diagnose it (find the defect), and fix the defect. Afterwards, confirmation testing checks that the fix worked, ideally run by the person who ran the original test, and regression testing checks that the fix did not break anything else.

When static testing finds a defect (for example, a reviewer spots a wrong formula in a design document), debugging is simply removing it. There is no failure to reproduce or diagnose, because nothing was executed.

1.2 Why is testing necessary?

Testing is a form of quality control. It helps the team reach the agreed objectives within scope, time, quality and budget constraints. Testing is not only the test team’s job: anyone on the project can use testing skills.

1.2.1 Testing’s contributions to success (K2)

• Detects defects cost-effectively. Defects can then be removed by debugging, so testing contributes indirectly to better quality.
• Evaluates quality directly at each stage of the SDLC, giving data for decisions such as “can we release?”.
• Represents users indirectly. Testers bring the users’ view into the project, which is cheaper and more practical than involving many real users throughout development.
• Meets contractual, legal or regulatory needs, for example safety standards in medical or automotive software.

Example: an online banking team tests the funds-transfer feature before release. The tests find that transfers over ₹1,00,000 are rounded wrongly. Fixing this before go-live avoids financial loss and reputational damage, which shows testing’s value.

1.2.2 Testing and quality assurance (K1)

People often use “testing” and “QA” as if they meant the same thing. They do not.

1.2.3 Errors, defects, failures and root causes (K2)

This chain appears in almost every exam:

Root cause → error (mistake) → defect (fault, bug) → failure

• A human error (mistake) happens because of time pressure, complexity, tiredness or lack of training.
• The error produces a defect in a work product: in code, a requirement, a test script or even a build file.
• If defective code is executed, it may cause a failure: the system does something it should not do, or does not do something it should.
• The root cause is the fundamental reason the problem occurred, found through root cause analysis. Removing it prevents similar defects in future.

Example: a developer was given an unclear requirement (root cause), misunderstood the GST rule (error), and coded 18% instead of 12% (defect). A customer sees the wrong tax on an invoice (failure).

Important details:

• Not every defect causes a failure. Some only fail under specific conditions; some never fail.
• Failures can also be caused by environmental conditions, such as radiation or electromagnetic fields damaging firmware, without any human error in the code.
• Defects in early work products (requirements, designs), if not found, often lead to defects in later ones.

1.3 The seven testing principles (K2)

1.4 Test activities, testware and test roles

1.4.1 Test activities and tasks (K2)

A test process is a set of test activities. The activities often look sequential, but in practice they are iterative and overlap, and they are tailored to the project.

1.4.2 Test process in context (K2)

Testing is part of the organisation’s development process and is funded to meet business needs, so how you test depends on the context:

• Stakeholders: needs, expectations, willingness to cooperate
• Team members: skills, experience, availability, training needs
• Business domain: criticality, risks, market needs, legal regulations
• Technical factors: type of software, architecture, technology
• Project constraints: scope, time, budget, resources
• Organisational factors: structure, policies, practices
• SDLC: engineering practices and development methods
• Tools: availability, usability, compliance

These factors shape the test strategy, the techniques used, the degree of automation, the required coverage, the level of detail in testware and the reporting.

1.4.3 Testware (K2)

Testware is the set of work products created by the test activities. Configuration management (chapter 5) keeps it consistent.

A risk register lists the risks with their likelihood, impact and mitigation.

1.4.4 Traceability between the test basis and testware (K2)

Traceability means keeping links between test basis items (requirements, user stories, risks), the testware for them (test conditions, test cases), the test results and the defects.

Why it matters:

• Coverage evaluation: tracing test cases to requirements shows which requirements are tested.
• Residual risk: tracing test results to risks shows how much risk remains.
• Impact analysis: when a requirement changes, you know which tests to update.
• Audits and IT governance: you can prove what was tested.
• Clear reporting: progress and completion reports can show status per requirement, which business stakeholders understand.

1.4.5 Roles in testing (K2)

The syllabus describes two principal roles:

These are roles, not job titles. A team leader, test manager or development manager can play the test management role, and in Agile teams some management tasks are handled by the team itself. One person can hold both roles at the same time.

1.5 Essential skills and good practices in testing

1.5.1 Generic skills required for testing (K2)

Testers often bring bad news, and people tend to blame the messenger. Confirmation bias makes it hard for authors to accept information that challenges what they believe. So testers should communicate defects constructively: describe facts, focus on the product rather than the person, and explain the impact.

1.5.2 Whole team approach (K1)

The whole team approach comes from Extreme Programming (XP). Any team member with the right skills can do any task, and everyone is responsible for quality. The team shares a workspace (physical or virtual).

Advantages:

• Better team dynamics, communication and collaboration
• Synergy from combining different skill sets
• Testers help business representatives write acceptance tests and agree test strategy and automation with developers
• Testing knowledge spreads across the team

It is not always appropriate: safety-critical systems, for example, may need a high level of independent testing.

1.5.3 Independence of testing (K2)

Independence makes testers more effective at finding defects because the tester’s cognitive biases differ from the author’s. It does not replace familiarity: developers can efficiently find many defects in their own code.

Most projects use several levels: developers do component and component integration testing, a test team does system and system integration testing, and business representatives do acceptance testing.

Learning objectives checklist

Next: Chapter 2: Testing Throughout the SDLC, or follow the preparation guide study plan.

ISTQB CTFL › Preparation guide and study plan Syllabus v4.0.1 · updated 3 Nov 2026

How the exam is written

Every exam question is mapped to one learning objective (LO) in the syllabus, and ISTQB fixes how many questions come from each chapter and at which knowledge level. That makes the exam predictable:

• The syllabus is the only source. If your company, a blog or a video uses a term differently, the exam follows the syllabus and the ISTQB Glossary.
• Keywords are K1-examinable. Every keyword listed at the start of a chapter can appear in a “which statement is true” question.
• K3 questions are calculations or scenarios. There are exactly 8, all from chapters 4 and 5.
• Wrong options are usually true statements about a different concept. You must know which concept a statement belongs to, not just whether it sounds right.

Your study toolkit

1. The official CTFL v4.0.1 syllabus (free PDF on istqb.org). Read it at least twice. It is about 60 pages of examinable text.
2. Our chapter notes (links in the course menu), which explain each section in plain language with examples.
3. The ISTQB Glossary for exact definitions. Look up every keyword you are not sure about.
4. Our three sample papers plus official sample exams A to D. Do them timed, then study every explanation, including for the questions you got right.
5. A one-page “formula sheet” you make yourself: EP and BVA rules, decision-table coverage, state-transition coverage, three-point estimation, the seven principles, review roles and review types.

4-week study plan (1 to 1.5 hours a day)

2-week fast-track plan (3 to 4 hours a day)

The 8 K3 skills you must practise

These are the only “apply” learning objectives. Each is worth practising until you can do it in under 3 minutes.

1. Equivalence partitioning (FL-4.2.1)

A form accepts an age from 18 to 60 (whole numbers). Partitions: below 18 (invalid), 18 to 60 (valid), above 60 (invalid). One value from each partition gives 100% EP coverage with 3 test cases, for example 10, 35 and 75. Invalid partitions count as coverage items too.

2. Boundary value analysis (FL-4.2.2)

Same field. The boundary values are the minimum and maximum of every partition: 17, 18, 60 and 61.

• 2-value BVA: each boundary value plus its closest neighbour in the adjacent partition. The set is {17, 18, 60, 61}, so 4 test values.
• 3-value BVA: each boundary value plus both neighbours. For 17: 16, 17, 18. For 18: 17, 18, 19. For 60: 59, 60, 61. For 61: 60, 61, 62. Removing duplicates gives {16, 17, 18, 19, 59, 60, 61, 62}, so 8 test values.

3. Decision table testing (FL-4.2.3)

A shop gives free delivery if the customer is a member or the order is over ₹999, and an extra 5% discount only if the customer is a member and pays online. With three Boolean conditions there are 2 × 2 × 2 = 8 columns in the full table. Coverage items are the feasible columns, so 100% coverage needs 8 test cases (fewer only if columns are merged or infeasible).

4. State transition testing (FL-4.2.4)

A login screen has states Ready, Locked and Logged in. Learn the three coverage criteria:

• All states coverage: every state visited at least once.
• Valid transitions (0-switch) coverage: every valid transition exercised. Most common criterion.
• All transitions coverage: every valid transition exercised and every invalid transition attempted, one invalid transition per test case.

Full valid-transitions coverage guarantees full all-states coverage, and all-transitions coverage guarantees both.

5. ATDD (FL-4.5.3)

Given a user story and its acceptance criteria, pick the test case that checks a criterion, with positive cases first, then negative and non-functional ones. Each test must be understandable by business stakeholders.

6. Estimation (FL-5.1.4)

Three-point estimation: E = (a + 4m + b) / 6 and SD = (b − a) / 6. Example: optimistic a = 4, most likely m = 6, pessimistic b = 14 person-days gives E = (4 + 24 + 14) / 6 = 7, SD = 10 / 6 ≈ 1.67, so 7 ± 1.67 person-days.

Ratio estimation: if a past project had a development-to-test ratio of 5:2 and the new development effort is 500 person-days, the test effort is 500 × 2 / 5 = 200 person-days.

7. Test case prioritization (FL-5.1.5)

Order by risk, coverage (or additional coverage) or requirement priority, but a test that another test depends on must run first, even if its own priority is lower. Exam questions almost always hide one dependency.

8. Defect report (FL-5.5.1)

Know what a good report contains: unique ID, title and short summary, date, author, test object and environment, context (test case, test activity, SDLC phase), description with steps to reproduce, expected and actual results, severity, priority, status, and references such as the test case. Questions ask which information is missing or which report is best.

How to read a question

1. Read the last line first. It tells you what is asked: “BEST”, “MOST likely”, “NOT”, “FIRST”.
2. Underline the qualifier. “Which is NOT a benefit of…” flips the logic. One missed “NOT” costs a mark.
3. Name the concept. Before reading the options, say which LO the question tests. Then each option is either about that concept or a distractor about a neighbouring one.
4. Eliminate absolutes. Options with “always”, “never”, “guarantees” or “proves” are usually wrong (“testing proves there are no defects” breaks principle 1).
5. Choose the syllabus answer, not your company’s answer. If two options are both true in real life, pick the one the syllabus states.
6. Show your working on K3 questions. Use the scratch paper or on-screen notes and write the partitions, boundaries or table columns before choosing.

Time management

You have 60 minutes for 40 questions. Aim for about 1 minute on K1 and K2 questions and 3 minutes on K3 questions. Answer every question on the first pass, flag the ones you are unsure about, and use the last 10 minutes to review flags. Never leave a question blank.

Common traps

Exam-day checklist

• A valid government photo ID that matches your registration name exactly.
• For online exams: the Pearson VUE system test passed on the same computer and network, a quiet room, a clear desk, webcam and microphone working, other apps closed.
• For test centres: arrive 30 minutes early.
• Eat, hydrate and keep 5 minutes of slack in your schedule before check-in.
• During the exam: answer everything, flag doubts, review flags at the end.