ISTQB Foundation Level Chapter 4: Test Analysis and Design
Chapter summary
Chapter 4 is the largest chapter in the syllabus, with 390 minutes of training time, more than a third of the entire course. It covers the test techniques used to design test cases: black-box techniques that look at what a system should do without considering how it is built, white-box techniques that look at the internal structure of the code, experience-based techniques that draw on tester intuition and experience, and collaboration-based approaches that involve the whole team in defining tests. This guide covers all five areas, with black-box and white-box techniques covered in the most depth, since those carry the heaviest exam weight and the most hands-on application.
What this chapter covers
| Sub-topic | What to study |
|---|---|
| Test techniques overview | Black-box, white-box, and experience-based test technique categories |
| Black-box test techniques | Equivalence partitioning, boundary value analysis, decision table testing, and state transition testing |
| White-box test techniques | Statement testing, branch testing, coverage, and the value of white-box testing |
| Experience-based test techniques | Error guessing, exploratory testing, and checklist-based testing |
| Collaboration-based test approaches | Collaborative user story writing, acceptance criteria, and ATDD |
Test techniques overview
Before getting into specific techniques, the syllabus draws a high-level distinction between the categories of test technique:
- Black-box test techniques are based on an analysis of the test basis (requirements, specifications, user stories) without reference to the internal structure of the test object.
- White-box test techniques are based on the internal structure of the test object, such as its code or architecture.
- Experience-based test techniques use the knowledge and experience of testers to design tests, often to complement the more systematic techniques.
All test techniques are used during test analysis and test design (the activities from Chapter 1), and the choice of technique depends on factors like the type of system, regulatory standards, customer or contractual requirements, risk levels, and tester skill and experience.
Black-box test techniques
Black-box techniques derive test cases from the test basis without looking at the code. The syllabus covers four black-box techniques in Chapter 4.
Equivalence partitioning divides data into partitions, where every value in a partition is expected to be treated the same way by the system. The idea is that if one value from a partition finds a defect, other values from the same partition would likely find the same defect, so testing one representative value per partition is enough. Partitions can apply to valid and invalid inputs, as well as outputs, internal values, time-related values, and interface parameters. You are expected to be able to apply equivalence partitioning to derive test cases (a K3-level objective), which means the exam may give you a scenario and ask you to identify the partitions and an appropriate test case.
Boundary value analysis (BVA) builds on equivalence partitioning by focusing specifically on the boundaries between partitions, since defects are more likely to occur at boundaries than in the middle of a partition. The syllabus describes two variations:
- Two-value BVA tests the value exactly on a boundary and the adjacent value on the other side of that boundary. For a valid range of 18 to 120, this means testing 18 and 17 at the lower boundary, and 120 and 121 at the upper boundary.
- Three-value BVA tests the boundary value itself plus the values immediately on either side of it. For the same range, this means testing 17, 18, and 19 at the lower boundary, and 119, 120, and 121 at the upper boundary.
BVA is also a K3-level objective, so expect to apply it to a scenario, often in combination with equivalence partitioning, since the two techniques work well together.
Decision table testing is used when a system's behavior depends on combinations of conditions. A decision table lists conditions (inputs) and the actions (outputs) that result from each combination of those conditions. Each column in the table represents a unique combination of condition values and the resulting action, forming a test case. This technique is particularly useful for testing business rules where multiple factors interact, and it is also a K3-level objective.
State transition testing is used for systems whose behavior depends on their current state and the events that occur. A state transition diagram (or table) shows the valid states a system can be in, the events that trigger a transition from one state to another, and the resulting actions. The syllabus describes different levels of coverage for state transition testing:
- All-states coverage means every state in the diagram is visited by at least one test case.
- Valid-transitions coverage means every valid transition shown in the diagram is exercised by at least one test case.
- All-transitions coverage is more thorough, and includes testing invalid transitions (event and state combinations not shown in the diagram as valid) in addition to valid ones.
State transition testing is a K3-level objective as well, so expect application-style questions involving a state diagram or table.
White-box test techniques
White-box techniques look at the internal structure of the code, most commonly at the level of individual components.
Statement testing and statement coverage focuses on executing individual statements in the code. Statement coverage is measured as the percentage of executable statements that have been exercised by a test suite. This is a K3-level objective, meaning you may be asked to calculate statement coverage for a given piece of code and a given set of test cases, or to design a test case to achieve a certain level of coverage.
Branch testing and branch coverage focuses on the decision outcomes (branches) in the code, such as the true and false outcomes of an if statement. Branch coverage measures the percentage of branches that have been exercised. Achieving 100% branch coverage also guarantees 100% statement coverage, but the reverse is not true, since a statement can be reached without every branch leading to it being exercised. Like statement coverage, this is K3-level, so expect to calculate or design for branch coverage given code and test cases.
The value of white-box testing is that it can reveal things black-box testing cannot, such as code that exists but is never reached by any specified requirement (dead code), or hidden dependencies between components. White-box testing is also useful for verifying coverage achieved against coverage criteria, which is often required in safety-critical or regulated domains.
Experience-based test techniques
These techniques rely on the tester's knowledge, intuition, and experience, often to complement the more systematic black-box and white-box techniques rather than replace them.
Error guessing involves anticipating likely defects based on experience, knowledge of common mistakes, and understanding of how the system has failed in similar situations before. A tester might create a list of possible errors, defects, and failures based on this knowledge and design tests specifically to target them.
Exploratory testing is an approach where tests are designed, executed, logged, and evaluated more or less simultaneously, with the tester learning about the system as they go and using that knowledge to guide further testing. It is particularly useful when requirements are incomplete, when there is little time for more formal test design, or when testers have deep domain or technical knowledge to draw on.
Checklist-based testing involves testers designing and executing tests to cover items in a checklist, which might be based on experience, knowledge of the application, or general quality characteristics. Checklists need to be maintained over time, since items can become outdated as the system or its usage changes.
Collaboration-based test approaches
This final section of Chapter 4 covers techniques that bring testers, developers, and business representatives together to define tests collaboratively, often used in Agile contexts.
Collaborative user story writing often involves the whole team, including testers, contributing to writing user stories, helping ensure the stories are clear, testable, and complete from the start.
Acceptance criteria define the conditions that a piece of software must meet to be accepted by a user, customer, or other stakeholder. They are used to define the boundaries (scope) of a user story, to develop test cases that verify whether the story has been correctly implemented, and to enable the team to know when a story is done.
Acceptance test-driven development (ATDD) involves deriving tests from acceptance criteria before development begins, following the test-first approach introduced in Chapter 2. Tests are created collaboratively by testers, developers, and business representatives, which helps surface different perspectives and catch misunderstandings before code is written.
Chapter 4 at a glance
| Sub-topic | What it covers | Cognitive level |
|---|---|---|
| 4.1 Test techniques overview | Categories of technique: black-box, white-box, experience-based | K2 |
| 4.2.1 Equivalence partitioning | Dividing data into partitions treated the same way by the system | K3 |
| 4.2.2 Boundary value analysis | Testing values at and around partition boundaries (two-value and three-value) | K3 |
| 4.2.3 Decision table testing | Deriving test cases from combinations of conditions and actions | K3 |
| 4.2.4 State transition testing | Deriving test cases from states, events, and transitions, with varying coverage levels | K3 |
| 4.3.1 Statement testing and coverage | Measuring and achieving statement coverage | K3 |
| 4.3.2 Branch testing and coverage | Measuring and achieving branch coverage | K3 |
| 4.3.3 Value of white-box testing | What white-box testing reveals that black-box testing cannot | K2 |
| 4.4.1 Error guessing | Anticipating likely defects based on experience | K2 |
| 4.4.2 Exploratory testing | Simultaneous test design, execution, and learning | K2 |
| 4.4.3 Checklist-based testing | Testing guided by maintained checklists | K2 |
| 4.5.1 to 4.5.3 Collaboration-based approaches | Collaborative story writing, acceptance criteria, and ATDD | K2 |
| Exam weight | 11 questions | 27.5% of the exam |
Exam tip
11 of the 40 exam questions come from this chapter, making it 27.5% of the total exam and the heaviest chapter by a significant margin. If you only have limited study time left before the exam, prioritize this chapter. The test techniques covered here, including equivalence partitioning, boundary value analysis, decision tables, and others, show up repeatedly and require you to actually apply them, not just recognize them. For a full picture of how question weight is distributed across all six chapters, see the Exam Format and Passing Score page.
Beginner perspective
This was, without question, the chapter that took me the longest to get comfortable with, and that makes sense given it is the biggest chapter by a wide margin. The good news is that a lot of it builds on patterns you will recognize once you have worked through a few examples.
Equivalence partitioning and boundary value analysis felt abstract to me until I started drawing pictures. Literally sketching a number line with the valid range marked, then marking where the boundaries were, made the two-value and three-value distinction much clearer than reading the definitions alone.
Decision tables took a bit of trial and error. My first attempts at building one from scratch were messy because I tried to list every possible combination of conditions before thinking about which ones were actually meaningful. Working through a few official sample exam questions helped me see how decision tables are usually presented on the exam, which is often smaller and more constrained than I expected.
Statement and branch coverage were more mechanical once I slowed down and actually traced through code line by line with a pencil, marking which lines and which branches a given test case would hit. Trying to do it in my head led to mistakes. Writing it out did not.
The experience-based and collaboration-based sections at the end felt like a bit of a breather after the technical density of black-box and white-box techniques. They are conceptually simpler, but do not skip them. They are still examinable, and a few questions on the exam will draw from this material.
Common misunderstandings
- Thinking equivalence partitioning means testing every value in a partition. The whole point is that one representative value per partition is enough, since values within a partition are expected to behave the same way.
- Confusing two-value and three-value BVA. Two-value tests the boundary and one adjacent value (two values per boundary). Three-value tests the boundary plus one value on each side (three values per boundary).
- Assuming 100% statement coverage means 100% branch coverage. It does not. A statement can be reached without every branch leading into it being exercised. The reverse is true: 100% branch coverage guarantees 100% statement coverage.
- Treating state transition testing as only about valid paths. All-transitions coverage specifically includes testing invalid transitions, meaning event and state combinations that should not normally happen.
- Viewing experience-based techniques as less rigorous or less valuable than black-box and white-box techniques. They are a different kind of tool, useful for different situations, especially when requirements are thin or time is short.
- Assuming acceptance criteria and acceptance tests are the same thing. Acceptance criteria define the conditions for a story to be accepted. Acceptance tests are derived from those criteria to verify whether the conditions have been met.
Last reviewed: June 2026.