4.1 Technique Selection and Coverage

What a Test Technique Is

A test technique (also called a test design technique) is a systematic, repeatable way to derive and select tests. In the ISTQB Glossary it is defined as a procedure used to define test conditions, design test cases, and specify test data. The value of a technique is that two competent testers applying the same technique to the same test basis will produce broadly comparable tests — the process is engineered, not improvised.

CTFL v4.0 (2023) organises techniques into three categories, plus a supporting practice:

• Black-box techniques (also specification-based) derive tests from the documented or understood behaviour of the test object — requirements, user stories, models, specifications. The internal code is not examined.
• White-box techniques (also structure-based) derive tests from the internal structure: source code, control flow, architecture.
• Experience-based techniques draw on the tester's knowledge, skill, intuition, and defect history.
• Collaboration-based test design (e.g. ATDD) uses team conversation and examples to build the test basis itself, complementing the other three.

The exam frequently asks you to pick the category that fits a scenario, so internalise the trigger words: 'specification/requirement/range' → black-box; 'code/branch/statement coverage' → white-box; 'no documentation/likely defects/charter' → experience-based.

Test Conditions, Coverage Items, and Coverage

From the test basis a tester first identifies test conditions — testable aspects such as a function, requirement, quality characteristic, or structural element. Each technique then defines coverage items: the specific elements that must be exercised to satisfy a chosen coverage criterion. Coverage items differ by technique:

Coverage is then measured as a percentage:

Coverage % = (number of coverage items exercised
             ÷ total number of coverage items) × 100

For example, if a state model has 12 transitions and your tests trigger 9 of them, transition coverage is 9 ÷ 12 = 75%. Coverage is a measure of thoroughness, not of correctness — 100% statement coverage can still miss a defect, a point the exam loves to test.

Choosing a Technique

No single technique is universally best. The CTFL syllabus lists factors that drive selection:

• Type of component or system — a protocol stack suits state transition testing; a tax calculation suits decision tables.
• Risk and the cost of failure — higher risk justifies more rigorous, often combined, techniques.
• Test level — component testing often uses white-box; acceptance testing leans on black-box and collaboration-based design.
• Available test basis — rich specifications enable black-box; sparse documentation pushes toward experience-based.
• Tester knowledge and skills — error guessing relies on experienced testers.
• Available tools — coverage tools make white-box measurement practical.
• Time and budget — constraints favour high-value, low-effort techniques first.
• Software development lifecycle — iterative teams pair user stories with collaboration-based design.
• Expected defect types and regulatory/contractual standards — some standards mandate a coverage level.

A mature strategy combines techniques: equivalence partitioning to choose representative classes, boundary value analysis to harden the edges, decision tables for rule interactions, then exploratory testing to probe what the systematic tests assume away. The exam answer is almost never 'apply every technique' — it is 'apply the technique whose coverage items match the risk you are trying to retire.'

Test Analysis vs Test Design

The chapter title pairs two distinct activities, and CTFL v4.0 keeps them separate:

• Test analysis answers what to test. The team examines the test basis (requirements, user stories, models, code), evaluates it to identify test conditions, and in doing so also performs a kind of static testing — analysis often exposes defects in the basis itself, such as ambiguities, omissions, and contradictions. Each test condition should be traceable back to the basis element it comes from, so coverage and impact analysis stay possible.
• Test design answers how to test. The test conditions are elaborated into test cases, sets of test cases, and other testware (test data, test procedures), and the coverage items are identified. This is where the techniques in this chapter are applied to turn conditions into concrete, executable tests.

Both activities depend on a clear test basis and produce bidirectional traceability: from the basis to test conditions and cases, and back. Traceability lets a team report meaningful coverage ('we have covered 18 of 20 requirements'), assess the impact of a change, and demonstrate compliance in regulated contexts. A good test analyst therefore does more than churn out test cases — they read the basis critically, which is why test analysis is itself one of the cheapest places to find defects in the whole lifecycle.

Keep the two ideas distinct on the exam: analysis identifies conditions and may find basis defects; design produces the test cases, testware, and coverage items. In practice the two activities overlap and iterate — designing a concrete test case often surfaces a fresh question about the basis, which feeds back into analysis, so teams cycle between the two rather than running them strictly once in sequence.