Test analysis and design
Chapter summary
Chapter 4 of the ISTQB Foundation Level syllabus is the largest chapter, with 390 minutes of training time and 11 of the 40 exam questions (27.5% of the exam). It covers the test techniques used to design test cases, grouped into four categories: black-box techniques, white-box techniques, experience-based techniques, and collaboration-based approaches.
This page covers the main concepts at a level that complements the full Chapter 4 guide.
Test technique categories
Black-box test techniques derive test cases from the test basis (requirements, specifications, user stories) without reference to how the system is built internally. White-box test techniques derive test cases from the internal structure of the system, such as its code. Experience-based techniques use tester knowledge and experience to design tests that complement the more systematic approaches. Collaboration-based approaches involve the whole team in defining expected behavior through user stories, acceptance criteria, and ATDD.
Black-box techniques
Equivalence partitioning divides input data into groups (partitions) where every value in a group is expected to be processed the same way. Testing one representative value from each partition is considered sufficient, because a defect that affects one value in a partition should affect all values in that partition. Partitions can be valid or invalid, and the technique applies to outputs and internal states as well as inputs.
Boundary value analysis builds on equivalence partitioning by testing the values at and immediately around the boundaries between partitions, where defects are more likely to occur. The two-value approach tests the boundary value and the adjacent value outside the boundary. The three-value approach tests the boundary value plus the values immediately on either side of it.
Decision table testing is used when a system's behavior depends on combinations of conditions. A decision table lists each combination of condition values and the expected action for that combination. Each column is a test case. This technique is particularly useful for systems with business rules involving multiple interacting conditions.
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 transitions, and the resulting actions. Coverage criteria for this technique range from testing all valid states and transitions to including invalid transitions.
All four black-box techniques have K3 learning objectives, meaning the exam will ask you to apply them to a scenario, not just define them.
White-box techniques
Statement testing considers whether every executable statement in the code has been exercised by at least one test. Statement coverage measures the percentage of statements exercised. Branch testing considers whether every decision outcome (branch) in the code has been exercised. Branch coverage measures the percentage of branches exercised. Achieving 100% branch coverage implies 100% statement coverage, but not the reverse.
Coverage measures what has been exercised. They do not prove that no defects remain, only that the covered paths have been tested.
Experience-based techniques
Error guessing uses tester knowledge of common mistakes, typical failure modes, and past defects to design tests likely to find problems that more systematic techniques might miss. It is often used to supplement other techniques rather than replace them.
Exploratory testing combines test design, execution, and evaluation simultaneously. The tester learns about the system as they test it, using what they discover to decide what to explore next. Exploratory testing is particularly useful when requirements are incomplete or when rapid feedback is needed.
Checklist-based testing uses a prepared list of conditions, attributes, or behaviors to check. The checklist can be built from experience, from domain knowledge, or from requirements, and it provides a repeatable baseline that can be maintained and improved over time.
Collaboration-based approaches
Collaborative user story writing involves testers, developers, and business representatives working together to write user stories that are testable, unambiguous, and appropriately scoped. Well-written user stories make acceptance criteria easier to define and acceptance testing easier to execute.
Acceptance criteria define the conditions a user story or feature must meet to be accepted. They can be written as statements, as rules, or in given-when-then format (as used in BDD). Clear acceptance criteria reduce ambiguity and serve as the basis for acceptance tests.
Acceptance test-driven development (ATDD) takes this further by writing acceptance tests from the acceptance criteria before development begins, using those tests as a shared definition of done.
Exam weight and K-levels
Chapter 4 contributes 11 questions to the exam (27.5%), the highest of any chapter. Four of the learning objectives are K3, all on black-box techniques. The white-box and experience-based objectives are K2. Plan to spend proportionally more time on Chapter 4 than any other chapter, and prioritize working through examples of equivalence partitioning and boundary value analysis. See the full Chapter 4 guide and the learning objectives page for the full breakdown.
Last reviewed: June 2026.