Overview
Test Analysis and Design is where you learn to derive test cases rather than describe testing. It opens by distinguishing the three families of techniques: black-box (from specifications), white-box (from internal structure) and experience-based (from tester knowledge). The four black-box techniques, equivalence partitioning (EP), boundary value analysis (BVA), decision table testing and state transition testing, are each tested at K3, so you must be able to identify coverage items and calculate coverage from a short specification.
The chapter then explains statement and branch testing and why branch coverage subsumes statement coverage, the value and limits of white-box testing, and the three experience-based techniques: error guessing, exploratory testing and checklist-based testing. It closes with collaboration-based approaches: writing user stories together, writing acceptance criteria in scenario-oriented or rule-oriented formats, and deriving test cases with acceptance test-driven development (ATDD). It is the detailed version of the test design activity introduced in Chapter 1.
How it's tested
Chapter 4 mixes six K2 questions with five K3 application questions. K3 items give a short specification, a state diagram, a decision table or a user story and ask for the minimum number of test cases, the set of test values that achieves full coverage, the coverage percentage reached, or the test case that a technique would produce. K2 items ask you to explain or classify techniques.
-
Count or choose test values
A specification with ranges or rules, and you identify partitions, boundary values or decision table columns, then pick the minimum set of tests or calculate coverage achieved.
-
Trace a state model
A state diagram or table and a set of test cases, and you work out which states and transitions are covered or which test sequence achieves valid transitions coverage.
-
Which technique fits
A situation such as missing specifications and tight time, a known history of defects, or a need for objective code coverage, and you choose exploratory testing, error guessing or a white-box technique.
A field accepts whole numbers 1 to 100. Asked for the test values that achieve 100% 2-value BVA coverage, list the boundary values of each ordered partition: 0 (top of the lower invalid partition), 1, 100 and 101 (bottom of the upper invalid partition). Two-value BVA tests each boundary value and its closest neighbor in the adjacent partition, so {0, 1, 100, 101} is the minimal set. Options containing 2 or 99 belong to 3-value BVA.
Syllabus sections 5
Official syllabus sections from the ISTQB outline, in outline order.
4.1 Test Techniques OverviewBlack-box, white-box and experience-based techniques and what each is based on.
- What it means
- Test techniques support test analysis (what to test) and test design (how to test) by helping define test conditions, coverage items and test data systematically. Black-box techniques are based on analysis of the specified behavior of the test object without reference to its internal structure. White-box techniques are based on analysis of the test object's internal structure and processing. Experience-based techniques use the knowledge and experience of testers.
- What to understand
- Black-box test cases stay valid if the implementation changes but the required behavior does not, and they can detect gaps between requirements and implementation. White-box test cases can only be created after design or implementation exists, because they depend on how the software is built. Experience-based techniques complement the others and can find defects they miss, but their effectiveness depends heavily on the tester's skills.
- How it shows up
- A K2 question describes where the test cases come from (a requirement, the code, a tester's knowledge of past failures) and asks which category of technique is being used.
- Common confusion
- Labeling a technique by who performs it rather than by its basis; a developer can use black-box techniques, and a tester can use white-box ones.
4.2 Black-Box Test TechniquesEquivalence partitioning, boundary value analysis, decision table testing and state transition testing at K3.
- What it means
- Equivalence partitioning divides data into partitions whose elements are expected to be processed the same way; partitions must be non-empty and must not overlap, and the coverage items are the partitions, both valid and invalid. Boundary value analysis applies only to ordered partitions: 2-value BVA tests each boundary value and its closest neighbor in the adjacent partition, while 3-value BVA tests each boundary value and both its neighbors. Decision table testing models combinations of conditions and resulting actions, with each column (rule) a coverage item. State transition testing models states, events, guard conditions and actions, and uses all states, valid transitions (0-switch) or all transitions coverage.
- What to understand
- For EP with several sets of partitions, the simplest criterion is each choice coverage: every partition from every set is exercised at least once, so the minimum test count is the size of the largest set, not the sum or product. Three-value BVA is more rigorous and can catch defects 2-value misses, such as "x <= 10" coded as "x = 10", which the extra 3-value test value 9 reveals. In decision tables, coverage items are the columns containing feasible combinations, and a table can be minimized by removing infeasible columns and merging columns where a condition does not affect the outcome. In state transition testing, test only one invalid transition per test case to avoid fault masking, and remember the subsumption chain: all transitions coverage includes valid transitions coverage, which includes all states coverage.
- How it shows up
- K3 questions give a range or rule and ask for the minimum number of tests or the correct set of values for 100% coverage, or give a state diagram and a set of test sequences and ask for the coverage achieved.
- Common confusion
- Adding or multiplying partitions across independent inputs for each choice coverage, when each test can exercise one partition from every set at once.
4.3 White-Box Test TechniquesStatement testing, branch testing and the value of white-box testing.
- What it means
- In statement testing the coverage items are executable statements, and statement coverage is the number of statements exercised divided by the total executable statements, as a percentage. In branch testing the coverage items are branches, the transfers of control between nodes in the control flow graph, both conditional (the true and false outcomes of an if, each case of a switch, the decision to exit or continue a loop) and unconditional (straight-line code).
- What to understand
- Achieving 100% branch coverage achieves 100% statement coverage, but not the reverse, because an if without an else can have all statements executed without the false outcome being taken. Even 100% coverage does not guarantee that data-dependent defects, such as division by zero, are found. White-box testing considers the whole implementation, so it can find defects even when the specification is vague or outdated, and it gives an objective coverage measure; its weakness is that it cannot detect missing requirements, because it only tests what was implemented. It can also be used statically, for example in dry runs of code or pseudocode.
- How it shows up
- K2 questions ask which statement about statement and branch coverage is true, or describe code with an if and no else and ask why one test can reach 100% statement but not 100% branch coverage.
- Common confusion
- Believing 100% statement coverage implies 100% branch coverage, or that 100% branch coverage means the code is defect-free.
4.4 Experience-based Test TechniquesError guessing, exploratory testing and checklist-based testing.
- What it means
- Error guessing anticipates errors, defects and failures from the tester's knowledge of how the application behaved in the past, the errors developers tend to make and failures seen in similar applications, covering areas such as input, output, logic, computation, interfaces and data. A methodical form is a fault attack, where the tester creates or acquires a list of possible errors, defects and failures and designs tests to expose them. Exploratory testing designs, executes and evaluates tests at the same time while learning about the test object, often session-based with a time-box, a test charter and a debriefing.
- What to understand
- Exploratory testing is most useful when specifications are few or inadequate or under significant time pressure, and to complement formal techniques; it works best with experienced, curious, analytical testers and can incorporate other techniques such as EP. Checklist-based testing designs and runs tests to cover conditions from a checklist built from experience and knowledge of how software fails; items are often phrased as questions, should be checked separately and directly, and should not duplicate automated checks, entry or exit criteria, or be too general. High-level checklists bring variability, which can increase coverage but reduces repeatability.
- How it shows up
- K2 questions describe a situation, such as new testers needing consistent guidance without detailed test cases or a tester working from a time-boxed charter, and ask which technique applies.
- Common confusion
- Treating exploratory testing as unstructured ad hoc testing; session-based exploratory testing uses charters, time-boxes and debriefs.
4.5 Collaboration-based Test ApproachesCollaborative user story writing, acceptance criteria and acceptance test-driven development (ATDD).
- What it means
- User stories are written collaboratively by business representatives, developers and testers and have three critical aspects, the 3 Cs: Card (the medium), Conversation (how the story will be used) and Confirmation (acceptance criteria). A common format is "As a [role], I want [goal], so that [business value]", and good stories meet INVEST: Independent, Negotiable, Valuable, Estimable, Small and Testable. Acceptance criteria are the conditions an implementation must meet to be accepted; they define scope, build consensus, describe positive and negative scenarios, support acceptance testing and planning.
- What to understand
- Acceptance criteria are usually scenario-oriented (for example the Given/When/Then format used in BDD) or rule-oriented (for example a bullet-point verification list or a tabulated input-output mapping). ATDD is a test-first approach: in a specification workshop the team analyzes the story and acceptance criteria and resolves ambiguities, then writes test cases based on the acceptance criteria, typically positive cases first, then negative cases and non-functional characteristics. Test cases must cover all characteristics of the story without going beyond it, and no two should describe the same characteristic; captured in an automation framework's format, they become executable requirements.
- How it shows up
- A K3 question gives a user story and acceptance criteria and asks which test case is derived correctly with ATDD, or which proposed test goes beyond the story's scope.
- Common confusion
- Writing ATDD test cases that test behavior not described in the user story or its acceptance criteria; ATDD tests must stay within the story.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Each choice coverage
The simplest coverage criterion when there are several sets of partitions: test cases must exercise each partition from each set at least once, without considering combinations.
- Remember
- The minimum number of test cases equals the number of partitions in the largest set, because one test can cover a partition from every set at once.
- Tested as
- K3 minimum-test-count questions with two or more inputs.
- Trap
- Adding the partition counts (or multiplying them) instead of taking the largest set.
-
EP coverage
Coverage items in equivalence partitioning are the partitions, valid and invalid, and coverage is the number of partitions exercised by at least one value divided by the total number of identified partitions.
- Remember
- Partitions must be non-empty and must not overlap, and invalid partitions count as coverage items.
- Tested as
- K3 questions asking which test set achieves 100% EP coverage.
- Trap
- Forgetting the invalid partitions when counting.
-
2-value boundary value analysis
For each boundary value there are two coverage items: the boundary value itself and its closest neighbor belonging to the adjacent partition.
- Remember
- For a valid range 1 to 100 of whole numbers, 2-value BVA needs 0, 1, 100 and 101.
- Tested as
- K3 test-value selection questions.
- Trap
- Including values from inside the partition, such as 2 or 99, which belong to 3-value BVA.
-
3-value boundary value analysis
For each boundary value there are three coverage items: the boundary value and both of its neighbors.
- Remember
- It is more rigorous than 2-value BVA and can find defects 2-value misses, such as "if (x <= 10)" wrongly coded as "if (x = 10)", which the value 9 exposes.
- Tested as
- K3 questions on test values and on which variant detects a given defect.
- Trap
- Applying BVA to unordered partitions such as a list of colors; BVA applies only to ordered partitions.
-
Decision table coverage
The coverage items are the columns (rules) containing feasible combinations of conditions, and coverage is the number of exercised columns divided by the total number of feasible columns.
- Remember
- A full table has a column for every combination (2 to the power n for n Boolean conditions), reduced by removing infeasible combinations and merging columns whose outcome does not depend on a condition, marked "-".
- Tested as
- K3 questions asking how many test cases a minimized table needs.
- Trap
- Counting infeasible combinations as coverage items.
-
State transition coverage criteria
All states coverage (every state visited), valid transitions coverage, also called 0-switch coverage (every valid transition exercised), and all transitions coverage (every valid transition exercised and every invalid transition attempted).
- Remember
- Full all transitions coverage guarantees full valid transitions coverage, which guarantees full all states coverage; all transitions coverage should be the minimum for mission- and safety-critical software.
- Tested as
- K3 questions with a state diagram and test sequences.
- Trap
- Assuming visiting every state exercises every transition.
-
Invalid transitions and fault masking
Invalid transitions are the empty cells of a state table: events that should have no effect in a given state.
- Remember
- Test only one invalid transition per test case so that one failure cannot hide another.
- Tested as
- Questions on designing all transitions coverage tests.
- Trap
- Chaining several invalid events in one test case to save time.
-
Statement coverage
The percentage of executable statements exercised by the tests.
- Remember
- 100% statement coverage does not guarantee that every decision outcome has been tested.
- Tested as
- K2 explain statement testing.
- Trap
- Thinking 100% statement coverage means the code is fully tested.
-
Branch coverage
The percentage of branches, conditional and unconditional transfers of control in the control flow graph, exercised by the tests.
- Remember
- Branch coverage subsumes statement coverage: 100% branch coverage gives 100% statement coverage, not the reverse.
- Tested as
- K2 explain branch testing and compare with statement testing.
- Trap
- Forgetting the false outcome of an if statement that has no else part.
-
Value and limits of white-box testing
White-box testing considers the entire implementation and gives an objective coverage measure, which helps add tests where coverage is low.
- Remember
- It cannot find defects of omission, requirements that were never implemented, and black-box testing alone cannot measure code coverage.
- Tested as
- K2 explain the value of white-box testing.
- Trap
- Claiming white-box testing finds missing functionality.
-
Session-based exploratory testing
Exploratory testing conducted in a defined time-box, guided by a test charter containing test objectives, and followed by a debriefing.
- Remember
- Exploratory testing is useful when specifications are few or inadequate or time pressure is high, and to complement formal techniques.
- Tested as
- K2 explain exploratory testing.
- Trap
- Describing it as testing without any structure or documentation.
-
Acceptance criteria formats
Scenario-oriented (such as Given/When/Then, used in BDD) and rule-oriented (such as a bullet-point verification list or tabulated input-output mapping).
- Remember
- Other formats are allowed if they are well-defined and unambiguous.
- Tested as
- K2 classify the options for writing acceptance criteria.
- Trap
- Calling Given/When/Then rule-oriented.
-
INVEST and the 3 Cs
Good user stories are Independent, Negotiable, Valuable, Estimable, Small and Testable; every story has a Card, a Conversation and a Confirmation.
- Remember
- If stakeholders cannot say how to test a story, it may be unclear, not valuable, or they may need help with testing.
- Tested as
- K2 questions on collaborative user story writing.
- Trap
- Treating Confirmation as sign-off rather than the acceptance criteria.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
2-value BVA vs. 3-value BVA
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| 2-value BVA | Each boundary value plus its closest neighbor in the adjacent partition | Fewer tests; for 1 to 100 the values are 0, 1, 100, 101 | Adding inner neighbors such as 2 and 99 |
| 3-value BVA | Each boundary value plus both of its neighbors | More rigorous; for 1 to 100 the values are 0, 1, 2, 99, 100, 101 | Thinking it adds nothing over 2-value BVA |
All states vs. valid transitions vs. all transitions coverage
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| All states coverage | Every state is visited | Weakest; can be met without exercising every transition | Equating it with full transition coverage |
| Valid transitions (0-switch) coverage | Every valid single transition is exercised | Full coverage also guarantees all states coverage | Forgetting transitions with guard conditions count separately |
| All transitions coverage | Every valid transition is exercised and every invalid transition is attempted | Strongest; recommended minimum for mission- and safety-critical software | Testing several invalid transitions in one test case |
Statement coverage vs. branch coverage
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Statement coverage | Executable statements exercised divided by total executable statements | Can reach 100% without testing every decision outcome | Assuming it implies branch coverage |
| Branch coverage | Branches exercised divided by total branches, conditional and unconditional | Subsumes statement coverage | Assuming 100% means no defects remain |
Error guessing vs. exploratory testing vs. checklist-based testing
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Error guessing | Anticipating errors, defects and failures from knowledge of past problems | Driven by a list of likely mistakes, systematized as fault attacks | Thinking it is random guessing |
| Exploratory testing | Simultaneous test design, execution and evaluation while learning | Often time-boxed sessions guided by a charter and debriefed | Thinking it cannot be planned or documented |
| Checklist-based testing | Tests designed to cover conditions in an experience-based checklist | Gives consistency and guidance when detailed test cases are absent | Putting automated checks or exit criteria on the checklist |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Multiplying partitions
- What candidates pick
- The product or sum of partition counts as the minimum number of test cases for EP coverage of two inputs.
- Why it looks right
- Combining every option feels thorough, and decision tables do use combinations.
- Why it's wrong
- Each choice coverage only requires every partition of every set to be exercised once, so one test covers a partition from each set and the minimum is the largest set's count.
Clue to watch for The question says "minimum number of test cases" for EP or each choice coverage.
-
Inner neighbors in 2-value BVA
- What candidates pick
- A set such as {1, 2, 99, 100} for 2-value BVA of the range 1 to 100.
- Why it looks right
- It stays inside the valid range and looks like testing the edges.
- Why it's wrong
- 2-value BVA pairs each boundary value with its closest neighbor in the adjacent partition, so the invalid neighbors 0 and 101 are required and 2 and 99 are not.
Clue to watch for The question names 2-value BVA and the range has invalid partitions on both sides.
-
States equal transitions
- What candidates pick
- "The tests achieve 100% valid transitions coverage" because every state has been visited.
- Why it looks right
- Visiting every state seems to require using every path.
- Why it's wrong
- A model can have several transitions into the same state; all states coverage is weaker than valid transitions coverage.
Clue to watch for The diagram has more transitions than states, or a self-transition.
-
Statement implies branch
- What candidates pick
- "Achieving 100% statement coverage guarantees 100% branch coverage."
- Why it looks right
- Executing every line sounds like executing every path.
- Why it's wrong
- An if without an else can be fully executed with only the true outcome; branch coverage subsumes statement coverage, not the other way round.
Clue to watch for Code with an if that has no else branch.
-
White-box finds omissions
- What candidates pick
- White-box testing as the best way to find a requirement that was never implemented.
- Why it looks right
- White-box testing examines the whole implementation thoroughly.
- Why it's wrong
- White-box tests are derived from what was implemented, so they cannot reveal missing functionality; black-box tests from the requirements can.
Clue to watch for The stem describes missing or unimplemented functionality.
-
Exploratory equals unplanned
- What candidates pick
- "Exploratory testing cannot be managed or measured."
- Why it looks right
- It is often contrasted with scripted testing.
- Why it's wrong
- Session-based exploratory testing uses a time-box, a test charter with objectives and a debriefing, and it can include formal techniques such as EP.
Clue to watch for The scenario mentions a charter, a session or a debrief.
-
ATDD beyond scope
- What candidates pick
- A test case that checks behavior not mentioned in the story or its acceptance criteria.
- Why it looks right
- It looks like thorough, defensive testing.
- Why it's wrong
- ATDD test cases must cover all characteristics of the user story but must not go beyond it, and no two test cases should describe the same characteristic.
Clue to watch for One option introduces a rule, field or limit absent from the acceptance criteria.
Answer framework
For a Chapter 4 K3 question, follow these steps and write the working down rather than calculating in your head.
- Identify the technique and coverage criterion the question names, such as 2-value BVA, each choice, valid transitions or decision table coverage.
- List the coverage items explicitly: every partition including invalid ones, every boundary value, every feasible column, or every state and transition.
- Check each item against the rules: partitions non-overlapping, BVA only on ordered partitions, infeasible columns removed, one invalid transition per test.
- Map each proposed test value or sequence to the items it covers, ticking them off on your list.
- Count covered items against total items for a coverage percentage, or find the smallest set that ticks every item, before reading the options.
Practice question
Want more like this? The ISTQB CTFL practice test has questions for every domain.
Checklist
0 of 16
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Spend most of your Chapter 4 time on 4.2, because the four black-box techniques supply four of the chapter's five K3 questions. Work them in order: equivalence partitioning first, then boundary value analysis (which builds on partitions), then decision tables, then state transitions. For each, do at least ten small exercises on paper, writing out every coverage item before choosing an answer.
Next, cover 4.5, since ATDD is the fifth K3 objective: practice reading a user story with acceptance criteria and spotting which test case is correctly derived and which strays outside the story. Then learn 4.3 with one small code fragment that has an if without an else, so the statement versus branch difference is concrete, and finish with the K2 material in 4.1 and 4.4.
Candidates commonly underestimate the counting conventions: invalid partitions are coverage items, BVA needs ordered partitions, infeasible decision table columns do not count, and only one invalid transition belongs in each test. Afterward, do timed sets of mixed K3 questions, allowing about three minutes each, and review every miss by redoing the coverage-item list. Then move to Chapter 5, where coverage feeds prioritization and exit criteria.
FAQ
How many CTFL questions come from Test Analysis and Design?
The official exam structure allocates 11 of the 40 questions to Chapter 4, six at K2 and five at K3, which is 27.5% of the exam and the largest share of any chapter.
Which techniques are tested at K3?
Equivalence partitioning, boundary value analysis, decision table testing, state transition testing and acceptance test-driven development are the K3 learning objectives. Statement and branch testing and the experience-based techniques are K2.
What is the difference between 2-value and 3-value BVA?
Two-value BVA tests each boundary value and its closest neighbor in the adjacent partition. Three-value BVA tests each boundary value and both of its neighbors, which takes more tests but can find defects that 2-value BVA misses.
Does 100% statement coverage mean 100% branch coverage?
No. Branch coverage subsumes statement coverage, so 100% branch coverage gives 100% statement coverage, but 100% statement coverage can be reached without exercising every decision outcome, such as the false side of an if with no else.
Do I need to calculate white-box coverage on the exam?
The white-box learning objectives are K2, so questions focus on explaining statement and branch testing and their relationship rather than heavy calculation. You should still be comfortable working out which outcomes a short code fragment's tests exercise.
How long should I study Chapter 4?
As a planning estimate, about 9 to 13 hours of a 40-hour plan, most of it on hands-on exercises. The syllabus allocates 390 minutes of training time to this chapter, more than any other.
How does Chapter 4 connect to the rest of the syllabus?
It details the test design activity from Chapter 1, provides the techniques behind the black-box and white-box test types in Chapter 2, and feeds coverage metrics, coverage-based prioritization and exit criteria in Chapter 5.
Other Quality Management certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 4 knowledge
You have just worked through the counting rules for equivalence partitioning, boundary values, decision tables and state transitions, plus coverage and ATDD. Check that you can apply them accurately within about three minutes per question.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the ISTQB CTFL AI tutor Get any concept explained your way