ISTQB CTFL Chapter 4: Test Analysis and Design (Test Techniques with Worked Examples)

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.