← ISTQB Foundation: testing and quality decisions
07 / 8 · 60 MIN

Coverage: boundaries, rules, and states

Build cases from explicit rules and calculate coverage without confusing executions with observed behaviors.

Choosing the coverage item before the percentage

A percentage is meaningful only when the set of items to exercise is known. Items may be equivalence classes, boundary values, decision rules, transitions, or code branches. Ten executions of one case do not represent ten distinct items. In a form with two customer classes and three term classes, three cases can exercise each class individually without covering all six possible combinations. Record the selected criterion, identified items, and execution conditions. That list distinguishes class, combination, and expected-result coverage, preventing a favorable metric from hiding an important behavior still unobserved. The denominator should be explicit in the report.

Deriving boundaries from an inclusive integer rule

Our fictional batch accepts between 21 and 80 integer records. Values below 21, inside the range, and above 80 form three classes for this rule. For two-value BVA, use items 20,21,80,81: adjacent values on both sides of the boundaries. Suite 20,21,50,81 covers only three of those four items even though it has four executions. Value 50 can represent the valid class but does not replace boundary 80. Also specify each case’s expected result. Without knowing that 21 and 80 should be accepted, executing those values does not provide a useful oracle for detecting an incorrect inequality.

Demonstrating what a case can detect

Compare rule 21<=n<=80 with a faulty implementation using 21<n<=80. Both accept 50 and reject 20 and 81. Case 21 distinguishes the versions: it should be accepted, but the implementation rejects it. This lesson’s local model deliberately executes that faulty version to show the limitation of a suite using only interior values. This does not establish the effectiveness of every test in a real application. Other defects can affect types, formats, volume, concurrency, or unmodeled combinations. Use the example to justify case selection while keeping the experiment’s restricted scope visible to readers.

Representing conditions and outcomes in a table

Define three independent Booleans: A means an active account, S a valid signature, and D a repeated key. All eight combinations are feasible in this model. The fictional rule first rejects when A or S is false; when both are true, it returns the previous result if D is true and processes a new operation if D is false. This ordering is an exercise condition rather than a universal banking policy. Enumerate the eight rules before simplifying and assign an outcome to each. Repeating one rule does not cover another; six distinct rules out of eight represent 75% coverage of the complete table.

Visiting states and exercising transitions

The batch starts in READY. start leads to RUNNING; success leads from RUNNING to DONE; error leads from RUNNING to FAILED; retry leads from FAILED to RUNNING. There are four valid transitions. Sequences start-success and start-error, each after a reset to READY, visit every state but only three distinct transitions. retry is missing. To check the prohibition of retry in DONE, reach DONE through valid events and attempt that single invalid event. Check rejection and state preservation. Do not chain invalid events while assuming the first correctly established the state required for the second.

Reading structural coverage with explicit limits

Consider two independent IF statements, one for A and one for B, each with true and false branches. Cases (true,true) and (false,false) traverse all four branch outcomes. Combinations (true,false) and (false,true) remain unexecuted. Therefore, 100% branch coverage in this model does not imply every combination or establish that results were checked correctly. Relate coverage to risks and acceptance criteria. When recommending a release, explain which structure was observed and which relevant behaviors remain outside the experiment. Coverage guides further questions; it does not automatically turn a suite into proof that defects are absent.

IN PRACTICE

Calculate separately: {20,21,50,81} covers 3/4 boundaries; six distinct rules cover 6/8 combinations; start-success and start-error cover 3/4 transitions. All yield 75% but describe different gaps.

Common pitfalls

Counting repetitions as new coverage; using an interior value as a boundary; confusing states with transitions; generalizing branch coverage to every combination or absence of defects.

Related topics: Designing cases · Risk and release

Take this idea with you

Define the coverage item and expected outcome before calculating percentages. An identified gap informs the next test without itself proving that a defect exists.

Create account

Reference: ISTQB CTFL syllabus v4.0.1 · CTFL v4.0; syllabus v4.0.1 (2024-09-15)

ISTQB® is a registered trademark of International Software Testing Qualifications Board. bigsavant.com is an independent preparation platform and is not affiliated with, associated with, sponsored, authorised or endorsed by ISTQB. Content and questions are original, are not official exam questions, and completing our tests does not award or guarantee any certification. Names are used only to identify the subject. All other trademarks belong to their respective owners.