ISTQB Chapter 4 – Test Analysis and Design

All learning objectives

4.1 Test Techniques Overview

FL-4.1.1K2Distinguish black-box, white-box, and experience-based test techniques

4.2 Black-box Test Techniques

FL-4.2.1K3Apply Equivalence Partitioning (EP) to derive test cases

FL-4.2.2K3Apply Boundary Value Analysis (BVA) to derive test cases

FL-4.2.3K3Apply Decision Table Testing to derive test cases

FL-4.2.4K3Apply State Transition Testing to derive test cases

4.3 White-box Test Techniques

FL-4.3.1K2Explain statement testing and how to measure statement coverage

FL-4.3.2K2Explain branch testing and how to measure branch coverage

FL-4.3.3K2Explain the value of white-box testing

4.4 Experience-based Techniques

FL-4.4.1K2Explain error guessing

FL-4.4.2K2Explain exploratory testing

FL-4.4.3K2Explain checklist-based testing

4.5 Collaboration-based Approaches

FL-4.5.1K2Explain collaborative user story writing

FL-4.5.2K2Explain acceptance criteria and their formats

FL-4.5.3K3Apply ATDD to derive test cases from acceptance criteria

K-level legend

Level	Verb	What the exam asks
K2	Understand / Explain	"Which statement BEST describes…?"
K3	Apply / Use	Scenario — derive test cases, calculate coverage

⚠️ Most of 4.2 is K3 — the exam gives you a scenario and asks you to apply the technique. Practice with examples!

4.1 Test Techniques Overview

Three families of test techniques

Black-box

Specification-based. Based on external behaviour — no knowledge of internal code needed.

Techniques: EP, BVA, Decision Table, State Transition

White-box

Structure-based. Based on internal code structure.

Techniques: Statement testing, Branch testing

Experience-based

Uses tester's knowledge & experience of defects and systems.

Techniques: Error Guessing, Exploratory, Checklist

All three are complementary — used together they provide better coverage than any one alone.

4.2 Black-box Test Techniques

4.2.1 Equivalence Partitioning (EP)

Divides input/output data into equivalence partitions — groups treated the same way by the system. If one value in a partition exposes a defect, all others in the group likely will too → test one value per partition is sufficient.

Partition properties:

Non-overlapping, non-empty
Can be continuous or discrete
Can be ordered or unordered
Can be finite or infinite

Types:

Valid: processed correctly per spec
Invalid: ignored or rejected

Applies to: inputs, outputs, config, internal values, time, interfaces

EP Coverage = (Partitions covered / Total partitions) × 100% Goal: at least one test case per partition (valid + invalid)

Multi-parameter: use Each Choice coverage

One test per partition per parameter — does not test all combinations (no Cartesian product).

Example — Age field (valid: 1–100)

Partition	Type	Test value
Age < 1	Invalid (below)	0 or -5
Age 1–100	Valid	50
Age > 100	Invalid (above)	101

3 partitions → 3 tests for 100% EP coverage

4.2.2 Boundary Value Analysis (BVA)

Tests the edges of equivalence partitions. Applies only to ordered partitions (min/max values defined). Developers frequently make off-by-one errors at boundaries.

2-value BVA (basic)

Coverage items per boundary: boundary value + closest neighbour in adjacent partition.

3-value BVA (rigorous)

Coverage items per boundary: boundary + both neighbours (one each side). Catches more defects.

2-value BVA Coverage = (Boundaries tested / Total boundaries) × 100%

3-value BVA Coverage = (Boundary items tested / Total boundary items) × 100% Each boundary = 3 items: value below, boundary, value above

Example — Valid partition: 1–100

BVA type	Lower boundary (1)	Upper boundary (100)	Total tests
2-value	1, 2	99, 100	4
3-value	0, 1, 2	99, 100, 101	6

Why 3-value catches more: If a dev writes if x = 10 instead of if x ≤ 10, testing x=9 (the value below) will expose the bug. 2-value misses this; 3-value catches it.

4.2.3 Decision Table Testing

Used for complex business rules — combinations of conditions leading to different actions. Each column = one rule (unique combination).

Structure

Rows: Conditions (top) + Actions (bottom)
Columns: Rules (each unique combination)

Condition notation:
T = True, F = False
– = Irrelevant (don't care)
N/A = Infeasible combination

Action notation:
X = Perform action, blank = don't

Types

Limited-entry: Boolean conditions only (T/F).

Extended-entry: Multi-values (ranges, partitions).

Full table: 2ⁿ rules for n conditions.

Simplify by: deleting infeasible columns, merging columns with identical outcomes.

Decision Table Coverage = (Feasible rules tested / Total feasible rules) × 100% Goal: exercise each feasible column (rule) at least once

Example — Loan approval (2 conditions)

Condition / Action	Rule 1	Rule 2	Rule 3	Rule 4
Income >50k?	T	T	F	F
Good credit?	T	F	T	F
Approve loan	✓
Reject loan		✓	✓	✓

4 rules, 4 test cases for 100% coverage. Rules 2–4 can be merged if desired.

Strength: Catches missed combinations and requirement gaps/contradictions. Weakness: Exponential growth with many conditions (2ⁿ) — use minimization or risk-based selection.

4.2.4 State Transition Testing

Models system behaviour via states and transitions. A transition is triggered by an event, may have a guard condition, and may produce an action.

Syntax: event [guard] / action — omit parts if not relevant

Coverage criteria (weakest → strongest)

Criterion	Coverage items	Formula	Guarantees	Use case
All States	States	(States visited / Total states) × 100%	—	Basic check
0-switch (Valid Transitions)	Single valid transitions	(Valid transitions exercised / Total valid transitions) × 100%	All states	Standard — most common
1-switch	Consecutive pairs A→B→C	(2-step paths covered / Total 2-step paths) × 100%	0-switch	More thorough
All Transitions	Valid + invalid transitions	(Valid+invalid exercised / Total transitions) × 100%	All states + 0-switch	Mission/safety-critical

Key: 100% valid transitions (0-switch) ⊇ 100% all states. 100% all transitions ⊇ 0-switch ⊇ all states.

Example — ATM State Table

State / Event	Insert Card	Enter PIN	Wrong PIN
Idle	→ Card Inserted	—	—
Card Inserted	—	→ PIN Entered	→ Card Inserted
PIN Entered	—	—	→ Card Inserted

Blank cells = invalid transitions (should be attempted in All Transitions coverage)

4.3 White-box Test Techniques

4.3.1 Statement Testing & Coverage

Coverage items = executable statements. Goal: design tests so every executable statement runs at least once.

Statement Coverage = (Statements exercised / Total executable statements) × 100% Example: 8 out of 10 statements executed → 80% statement coverage

What 100% means

Every executable statement has run at least once. Catches defects in those statements.

Limitations

• Misses data-dependent defects (e.g., division by zero only when denominator is 0)
• Does NOT guarantee all decision logic is tested
• Weakest white-box criterion

4.3.2 Branch Testing & Coverage

Coverage items = branches (control transfers in the control flow graph). A branch can be unconditional (straight-line) or conditional (if/else, switch, loop).

Branch Coverage = (Branches exercised / Total branches) × 100% Example: if (x > 0) → need one test with x>0 (true) AND one with x≤0 (false)

What 100% means

All true/false outcomes, loop paths, and switch cases are exercised. Stronger than statement coverage.

Limitations

• May miss defects requiring specific paths (path coverage)
• Still may miss data-dependent defects

Key fact: 100% branch coverage implies 100% statement coverage — but NOT vice versa. Branch coverage subsumes (is stronger than) statement coverage.

Example: if (x > 0) { A } else { B }

Test	Input	Branch taken
Test 1	x = 5	True branch → A
Test 2	x = -1	False branch → B

2 tests → 100% branch coverage (and 100% statement coverage)

4.3.3 Value of white-box testing

Strengths

Considers full code implementation
Finds defects even when specs are vague or outdated
Works for static testing (code reviews, pseudocode via control flow graphs)
Gives objective coverage metrics to add tests and build confidence

Weakness

Misses "defects of omission" — code doesn't implement a requirement that was never coded
Black-box lacks code coverage measures

Technique	Coverage focus	Subsumes statement?	Detects data defects?
Statement	Executable statements	—	No
Branch	Control transfers	Yes ✓	No

4.4 Experience-based Test Techniques

4.4.1 Error Guessing

Predict errors and defects based on past experience — app history, common developer mistakes, and knowledge of similar applications.

Common error areas to target:

Input: wrong parameters, null, empty
Output: bad format, wrong precision
Logic: missing cases, wrong conditions

Computation: wrong math, overflow
Interfaces: parameter mismatches
Data: bad initialisation, corruption

Approach: Build list of possible errors → design tests to expose them (fault attacks). Sources: tester experience, defect data, common failure knowledge.

4.4.2 Exploratory Testing

Design, run, and evaluate tests on-the-fly while simultaneously learning the application.

Session-based testing

Time-boxed sessions with a charter (objectives). Includes a debrief and session sheets for documentation.

Example: "1-hour session: Test login under load — note bugs, add tests live."

When to use

• Poor or vague specifications
• Time pressure
• Complementing formal techniques
• When experienced tester with domain knowledge is available

4.4.3 Checklist-based Testing

Use a checklist of test conditions to design and execute tests. Written as questions for easy yes/no checks.

Build checklists from:

Tester experience
User needs
Failure history and defect data
Known quality heuristics (e.g., Nielsen's 10 usability heuristics)

Maintenance rules:

Update regularly
Remove outdated items (devs learn from past mistakes)
Add new items from recent defects
Keep short
Avoid auto-checkable items and entry/exit criteria on checklist

Technique	Basis	Structure	Best when
Error Guessing	Past errors	Error lists	Known dev pitfalls
Exploratory	Learning on-fly	Time-boxed sessions with charter	Tight deadlines, vague specs
Checklist-based	Pre-defined items	Question lists	Quick coverage checks, consistency

4.5 Collaboration-based Test Approaches

Key difference from other techniques

Focus is on defect avoidance through team communication, rather than defect detection. Requires shared vision from business, development, and testing perspectives.

4.5.1 Collaborative User Story Writing

User story format: "As a [role], I want [goal], so that [business value]"

The 3 C's (Jeffries):

Card

Written description of the feature — fits on an index card.

Conversation

Verbal or documented explanation of usage — the shared understanding.

Confirmation

Acceptance criteria — how we know the story is done.

INVEST qualities (a good story is…)

Independent Negotiable Valuable Estimable Small Testable

If a story is hard to test → it needs more clarity, value definition, or decomposition.

4.5.2 Acceptance Criteria

Conditions that must be met for a user story to be accepted. They define the scope of the story and become the basis for acceptance tests.

What acceptance criteria should do:

Define the scope of the user story (what is included and what is not)
Reach consensus among all stakeholders (business, dev, test)
Describe positive scenarios (happy path) AND negative scenarios (error, invalid data)
Serve as basis for acceptance testing — become test conditions and test cases
Help with accurate planning and estimation

Two formats:

Scenario-oriented (Given/When/Then)

Used in BDD. Natural language describing a concrete scenario step-by-step.

Given the user is on the login page,
When valid credentials are entered,
Then the user is redirected to the home page.

Rule-oriented (bullet / table)

Lists conditions and expected outcomes.

If password <8 chars → show "Password too short"
If password 8–20 chars → accept and allow login

4.5.3 ATDD — Acceptance Test-Driven Development

Test-first approach where acceptance tests are written before the code. Tests act as executable requirements for a user story.

Steps in ATDD:

1. Specification workshop

Team (customer + dev + tester) analyzes and discusses user story and acceptance criteria. Ambiguities and defects in the story are clarified and fixed.

2. Create test cases

Based on acceptance criteria — they are examples of how the system should work.
Order: positive → negative → non-functional.

3. Automation & execution

If format supports a framework (e.g., Gherkin + Cucumber), devs automate tests as they implement the feature → executable acceptance tests.

How to write ATDD test cases:

Use natural language so stakeholders can understand
Each test case includes: preconditions, inputs, expected postconditions
Must cover all characteristics in the user story
Must NOT go beyond the story (no extra functionality)
Must NOT repeat the same characteristics (no duplicates)

Benefits of ATDD:

Clarifies requirements early (during the specification workshop)
Acts as living documentation (tests = examples of behaviour)
Improves collaboration between business, development, and testing
Supports continuous feedback when tests are automated and run frequently

📐 All formulas at a glance

Equivalence Partitioning

EP Coverage = (Partitions covered / Total partitions) × 100% Count valid + invalid partitions separately. One test per partition for 100% coverage.

Scenario	Partitions	Tests needed for 100%
Single field age 0–100	3 (invalid <0, valid 0–100, invalid >100)	3 tests: e.g. -1, 50, 101
Two fields (age + salary), 3 parts each	6 (use Each Choice — no combos)	6 tests minimum

Boundary Value Analysis

2-value BVA Coverage = (Boundaries tested / Total boundaries) × 100% Each boundary = 2 test values: boundary itself + closest neighbour in adjacent partition

3-value BVA Coverage = (Boundary items tested / Total boundary items) × 100% Each boundary = 3 test values: one below, the boundary, one above

Partition	Boundaries	2-value tests	3-value tests
Valid: 1–100	Lower=1, Upper=100	1, 2 and 99, 100 → 4 tests	0, 1, 2 and 99, 100, 101 → 6 tests
Valid: 18–65	Lower=18, Upper=65	18, 19 and 64, 65 → 4 tests	17, 18, 19 and 64, 65, 66 → 6 tests

Decision Table Testing

Decision Table Coverage = (Feasible rules tested / Total feasible rules) × 100% Full table has 2ⁿ rules for n conditions. Simplify by removing infeasible and merging identical outcome columns.

Conditions (n)	Max rules	Formula
1	2	2¹ = 2
2	4	2² = 4
3	8	2³ = 8
4	16	2⁴ = 16
n	2ⁿ	—

State Transition Testing

All States Coverage = (States visited / Total states) × 100% Weakest criterion — can visit all states without exercising all transitions

0-switch (Valid Transitions) Coverage = (Valid transitions exercised / Total valid transitions) × 100% Most common criterion — guarantees all states coverage. Each valid arrow exercised at least once.

All Transitions Coverage = (Valid + invalid transitions exercised/attempted / Total transitions) × 100% Strongest — also attempts invalid transitions. Minimum for safety-critical software.

Subsumption chain: All Transitions ⊇ 0-switch ⊇ All States

Statement Coverage (White-box)

Statement Coverage = (Statements exercised / Total executable statements) × 100% Weakest white-box criterion. 100% means every executable statement ran at least once.

Code has	Tests cover	Coverage
10 statements	8 statements	80%
10 statements	10 statements	100%

Branch Coverage (White-box)

Branch Coverage = (Branches exercised / Total branches) × 100% Stronger than statement coverage. 100% branch coverage implies 100% statement coverage.

Code element	Branches created	Tests needed for 100%
`if (x > 0) {...} else {...}`	2 (true, false)	2 tests
`if (a) {...} else if (b) {...} else {...}`	3	3 tests
`switch (x) { case 1: case 2: case 3: }`	3	3 tests

Exam rule: 100% branch coverage ⊇ 100% statement coverage. You can have 100% statement coverage without 100% branch coverage (e.g., only tested the true branch).

Quick comparison — all techniques

Technique	Type	Coverage formula	Subsumes
EP	Black-box	(Partitions covered / Total) × 100%	—
2-value BVA	Black-box	(Boundaries tested / Total boundaries) × 100%	EP (for ordered partitions)
3-value BVA	Black-box	(Boundary items / Total items) × 100%	2-value BVA
Decision Table	Black-box	(Feasible rules tested / Total feasible) × 100%	—
All States	Black-box	(States visited / Total states) × 100%	—
0-switch	Black-box	(Valid transitions / Total valid) × 100%	All States
All Transitions	Black-box	(All exercised / Total) × 100%	0-switch
Statement	White-box	(Statements exercised / Total) × 100%	—
Branch	White-box	(Branches exercised / Total) × 100%	Statement

All 18 keywords

Term	Definition
test technique	A procedure used to define test conditions, test cases, or test data
black-box test technique	Technique based on analysis of external behaviour — no knowledge of internal code needed (specification-based)
white-box test technique	Technique based on analysis of the internal structure/code of the test object (structure-based)
experience-based test technique	Technique based on the tester's knowledge, experience and intuition
equivalence partitioning	Black-box technique that divides data into partitions where all values are expected to be treated the same
boundary value analysis	Black-box technique that derives test cases by testing the boundary values of ordered equivalence partitions
decision table testing	Black-box technique using a table of conditions and actions to design test cases for complex business rules
state transition testing	Black-box technique that models system behaviour as states and transitions, deriving tests to cover them
statement coverage	% of executable statements exercised by test cases
branch coverage	% of branches in the control flow graph exercised by test cases
coverage	The degree to which specified coverage items have been exercised by a test suite
coverage item	An attribute or combination used as a basis for test coverage measurement (e.g., a statement, branch, partition)
error guessing	Experience-based technique predicting errors based on past knowledge and fault attacks
exploratory testing	Experience-based technique where test design, execution and learning happen simultaneously, often in time-boxed sessions
checklist-based testing	Experience-based technique using a pre-defined checklist of test conditions
collaboration-based test approach	Approach focused on defect avoidance through team communication — includes ATDD and user story writing
acceptance criteria	Conditions a user story must satisfy to be accepted; become the basis for acceptance tests
acceptance test-driven development (ATDD)	Test-first approach where acceptance tests are written before code; tests act as executable requirements

ISTQB Foundation Level — Chapter 4

4.1 Test Techniques Overview

4.2 Black-box Test Techniques

4.3 White-box Test Techniques

4.4 Experience-based Techniques

4.5 Collaboration-based Approaches

K-level legend

Three families of test techniques

Black-box

White-box

Experience-based

4.2.1 Equivalence Partitioning (EP)

4.2.2 Boundary Value Analysis (BVA)

2-value BVA (basic)

3-value BVA (rigorous)

4.2.3 Decision Table Testing

Structure

Types

4.2.4 State Transition Testing

4.3.1 Statement Testing & Coverage

What 100% means

Limitations

4.3.2 Branch Testing & Coverage

What 100% means

Limitations

4.3.3 Value of white-box testing

Strengths

Weakness

4.4.1 Error Guessing

4.4.2 Exploratory Testing

Session-based testing

When to use

4.4.3 Checklist-based Testing

Build checklists from:

Maintenance rules:

Key difference from other techniques

4.5.1 Collaborative User Story Writing

Card

Conversation

Confirmation

4.5.2 Acceptance Criteria

Scenario-oriented (Given/When/Then)

Rule-oriented (bullet / table)

4.5.3 ATDD — Acceptance Test-Driven Development

1. Specification workshop

2. Create test cases

3. Automation & execution

Equivalence Partitioning

Boundary Value Analysis

Decision Table Testing

State Transition Testing

Statement Coverage (White-box)

Branch Coverage (White-box)

Quick comparison — all techniques