A learner colours every circle in a state diagram and announces that the system has been fully tested. All the named states have appeared, so the conclusion feels reasonable. Yet one route between them may never have been used, and an event that should be refused may never have been tried.
For ISTQB Certified Tester Foundation Level learning, distinguish the thing being counted before calculating coverage. States, valid transitions and valid-plus-invalid transition attempts are different coverage items. Trace each event from a known starting state, record what it should do, then compare the exercised items with the complete model. Visiting every state does not by itself exercise every valid transition.
This guide uses an original small workshop model rather than an official examination question. The aim is an explainable testing decision that survives a changed requirement. That is the learning standard developed in the Education parent guide: a familiar diagram becomes useful when its relationships can be reconstructed in unfamiliar work.
Find your next learning step
Trace original state models, distinguish states from transitions, test refusals and revise coverage when requirements change.
ROUTE 1 · CHAPTERS 1–3
Define the counting job
Choose the criterion, specify the system and build the table.
ROUTE 2 · CHAPTERS 4–6
Trace and cover valid routes
Track states, expose missing arrows and extend the path.
ROUTE 3 · CHAPTERS 7–9
Test and interpret
Check refusals, count distinct items and build useful expectations.
ROUTE 4 · CHAPTERS 10–12
Change and diagnose
Add a self-transition, select a model and repair the first gap.
ROUTE 5 · CHAPTERS 13–15
Check a fresh model
Try document states, resolve questions and retain the evidence boundary.
Full chapter index · Independent learning check · Education parent guide
Full chapter index
Define the counting job · Chapters 1–3
Trace and cover valid routes · Chapters 4–6
Test and interpret · Chapters 7–9
Change and diagnose · Chapters 10–12
Check a fresh model · Chapters 13–15
CHAPTER 1 OF 15 · Define the counting job
1. Read the coverage question before counting anything
The ISTQB CTFL syllabus v4.0.1, dated 15 September 2024 and checked on 23 October 2026, includes state transition testing in section 4.2.4. Its three coverage perspectives concern exercised states, exercised valid transitions, and valid transitions together with attempted invalid transitions. Use the current official syllabus for the exact qualification terminology.
A percentage becomes meaningful only after its denominator is named. Three exercised states out of three states says something different from two exercised transitions out of four valid transitions. Both calculations can describe one sequence correctly. The mistake begins when a learner uses the first result to answer the second question.
Imagine Tessa studying a diagram with three circles. She remembers that complete coverage means 100 percent, and counts three circles touched. Her arithmetic is sound. Her interpretation is incomplete because she has not asked which kind of coverage the task requests. The useful repair is to change the question, not assign more percentage exercises.
Another learner, Dev, names valid transitions correctly but counts every event in a long sequence as a new coverage item. Repeating the same arrow five times does not cover five distinct arrows. Dev needs to compare a sequence of executions with a set of distinct items. These two difficulties can lead to the same wrong answer for different reasons.
Write a short sentence before calculating: “I am counting distinct valid transitions in this model.” That sentence does not solve the problem, but it prevents a hidden switch between objects. Keep it beside the calculation until identifying the requested coverage item becomes an independent habit.
CHAPTER 2 OF 15 · Define the counting job
2. Define a small system completely enough to test
Our fictional workshop system tracks one task through three states: Queued, Active and Finished. It accepts four named event types: start, cancel, complete and reopen. There are no guard conditions, concurrent tasks, timing rules or hidden permissions in the initial model. Each example concerns one task whose initial state is known.
The four valid transitions are these. From Queued, start moves the task to Active. From Queued, cancel moves it to Finished. From Active, complete moves it to Finished. From Finished, reopen moves it to Queued. No other state-and-event pair is valid in this deliberately restricted system.
We also specify what an invalid event attempt must do: show a refusal message, leave the state unchanged and make no task-data change. This is an additional requirement of our fictional example. It is not a universal rule that every invalid event in every application must behave that way. A real system may require another response, which must be established before judging its behaviour.
The initial task begins in Queued. Tests may create a fresh task in that state as a documented reset. Moving to Active or Finished during setup requires the valid events just described; do not assume a tester can place a task directly into any state by wishful thinking. Setup affects whether the proposed sequence is executable.
Ask a partner to repeat the model in ordinary language. Which event is available from each state? What must remain unchanged after a refusal? If two readers give different answers, clarify the requirement before counting. A precise coverage calculation against two different models does not resolve the underlying disagreement.
CHAPTER 3 OF 15 · Define the counting job
3. Build the state table and name its empty positions
The table below records the same four valid routes. A destination names a valid transition. “Invalid” marks a state-and-event pair for which our stated refusal behaviour must be checked. The word is printed explicitly for readability; it represents the invalid positions that are often left blank in a conventional state table.
| Current state | start | cancel | complete | reopen |
|---|---|---|---|---|
| Queued | Active | Finished | Invalid | Invalid |
| Active | Invalid | Invalid | Finished | Invalid |
| Finished | Invalid | Invalid | Invalid | Queued |
There are three rows and four event columns, giving twelve state-and-event positions. Four are valid. Eight are invalid. These counts apply to the fully specified small table, not to every state model with three states. Another model might contain a different event set, guards or valid self-transitions and therefore a different denominator.
The table makes an omission visible. If a learner draws only the four permitted arrows, the drawing communicates the valid routes but may not prompt them to ask what happens when start is attempted from Finished. Reading the table row by row supplies that missing question without treating the diagram as wrong.
Do not invent an expected result merely because a table position is blank. In our case the refusal rule is explicit, so a test can check it. In an incomplete specification, the next action may be a requirement question. Absence of an arrow establishes neither a harmless no-op nor a particular error message on its own.
Keep the model beside the requirement and check them in both directions. Every valid rule should have its table position. Every destination in the table should have a supporting rule. This review can find a modelling error before any software is executed, which is a different kind of evidence from passing a dynamic test.
CHAPTER 4 OF 15 · Trace and cover valid routes
4. Trace a path one event at a time
Begin in Queued and apply start. The current state becomes Active. Apply complete next, and the state becomes Finished. The sequence can be written in words as Queued, start, Active, complete, Finished. Each event is interpreted in the state produced by the preceding event, not in the initial state forever.
This simple rule is easy to lose in a long list. A learner may read start, complete, cancel and assume all three are valid because each appears somewhere in the table. But after start and complete, the task is Finished. Cancel is invalid from Finished in our model. Event names alone do not determine validity.
Use a trace record with an initial state, event, expected next state and observed next state. Before executing, fill the expected result from the model. Afterwards, record what actually happened. If the application changes to an unexpected state, continuing as if the expected state had occurred would make subsequent interpretation unreliable.
For paper practice, move a token among three labelled boxes. Speak the event before moving it and justify the destination from the table. A silent route works too: mark the current box and write the event beside the next step. The learning goal is state-dependent interpretation, not speed, dexterity or a particular way of drawing arrows.
Stop after each step during early learning. Later, remove that support and trace a fresh sequence independently. The useful progression is from a visible current-state marker to an internal, checkable account of the state. Removing the table before the learner understands its relationships merely turns the exercise into a memory contest.
CHAPTER 5 OF 15 · Trace and cover valid routes
5. Show how all states can be exercised with missing arrows
Return to the sequence start, complete from a fresh Queued task. It exercises Queued as the starting state, Active after start, and Finished after complete. All three states have been exercised. Under the stated model, that is three out of three, or 100 percent all states coverage.
Now list the distinct valid transitions used. Queued by start to Active is one. Active by complete to Finished is another. The sequence has not used Queued by cancel to Finished or Finished by reopen to Queued. It has therefore exercised two of the four valid transitions, giving 50 percent valid transitions coverage.
The two answers are compatible. The path reached every named place but did not use every permitted route. Avoid explaining the difference only through a slogan about circles and arrows, because some representations use tables rather than drawings. The deeper distinction is between the possible conditions of the system and the permitted state changes triggered by events.
Try the shorter sequence cancel from Queued. It exercises Queued and Finished, so its all states coverage is two out of three. It exercises one of four valid transitions. Repeating cancel on fresh Queued tasks ten times increases the number of executions, but the distinct states and transition items covered remain the same.
A learner who can explain both cases has done more than memorise a definition. They can derive two different coverage reports from one trace and state why neither report alone describes all testing. Ask them to construct a third sequence with different results before showing another worked answer.
CHAPTER 6 OF 15 · Trace and cover valid routes
6. Extend the path to cover the missing valid transitions
One executable sequence from Queued is start, complete, reopen, cancel. The states are Queued, Active, Finished, Queued, Finished. It exercises each of our four valid transitions at least once. Distinct transition coverage is four out of four, or 100 percent, even though Queued and Finished each appear more than once.
The sequence does not require a fresh reset between its steps because reopen provides a valid route back to Queued. If that route did not exist, a different arrangement of test cases and setup might be needed. The feasibility of a coverage plan depends on the actual connectivity of the model, not just the number of arrows.
Label the four valid transitions with temporary identifiers if that helps: T1 for Queued-start-Active, T2 for Queued-cancel-Finished, T3 for Active-complete-Finished and T4 for Finished-reopen-Queued. The path exercises T1, T3, T4 and T2. Identifiers help compare sets, but the full source, event and destination must remain recoverable.
Do not interpret a proposed one-sequence solution as a proof that one test is always sufficient or optimal. Our small system happens to permit this connected route. Real tests also need expected outputs, data, setup and observation. A compact event sequence can be a useful design, but its length does not establish its adequacy for every purpose.
To check understanding, remove reopen from the model and ask the learner to rebuild the plan. The old sequence becomes invalid at that step. They must account for reset or fresh-task setup rather than quote the former solution. A changed model should change the reasoning, even if the familiar state names remain.
CHAPTER 7 OF 15 · Test and interpret
7. Test refusal separately from taking a permitted route
From a fresh Queued task, attempt complete. Our requirement says the attempt must be refused, the state must remain Queued and task data must remain unchanged. Observe all those outcomes. Merely seeing a message is insufficient if the application quietly changes the task to Finished behind it.
A useful test records the precondition, the single invalid attempt and the expected refusal behaviour. If the system unexpectedly changes state, stop and capture the failure rather than continuing to make several assumptions about its new condition. One failure can otherwise hide or distort the evidence from later steps.
There are eight invalid state-and-event pairs in our table. To prepare an Active task, execute start from Queued. To prepare a Finished task, use either start then complete or cancel, recording which setup was used. Then attempt the selected invalid event and check the specified response. Keep each invalid target identifiable.
The syllabus recommends isolating invalid transition attempts within test cases to reduce defect masking. Our teaching plan follows that principle by giving each refusal target its own controlled attempt. Setup may still use valid transitions. “One invalid target” does not mean that no other event can appear anywhere in the case.
An unchanged state after an invalid attempt is not automatically a valid self-transition. Validity comes from the requirement. A self-transition is a permitted transition whose destination equals its source; our refusal is a prohibited attempt that must be rejected. The visible state alone may look identical, so the expected message and data behaviour matter.
CHAPTER 8 OF 15 · Test and interpret
8. Count distinct coverage items without double counting
Use the original successful path start, complete as a starting suite. For all states coverage, the exercised set is Queued, Active and Finished. For valid transitions coverage, the exercised set contains only T1 and T3. For all transitions coverage in our full table, those two valid items are two of twelve valid-or-invalid positions.
If we then run start, complete, reopen, cancel successfully, all four valid items have been exercised across the suite. The union of the two runs contains four distinct valid transitions, not six. Counting the executions separately would overstate how much of the model has been addressed.
Add one isolated refusal test for each of the eight invalid positions. If each target is attempted and its specified result checked, the suite addresses all twelve positions. The coverage calculation is twelve out of twelve for this table. Describe the scope explicitly: it does not include every possible event sequence, timing condition or data value.
Record execution and outcome separately. A coverage report says which model items have been exercised or attempted. A test result says whether observed behaviour matched the expectation. A fully covered item can fail. Reporting 100 percent coverage without the failure status would hide the most useful information from the run.
Suppose seven invalid attempts pass and one unexpectedly changes data. The suite may still have attempted every required position, but the system has a recorded failure. The next decision is investigation and correction, followed by appropriate rechecking. It is not to recalculate coverage so the failure disappears from view.
CHAPTER 9 OF 15 · Test and interpret
9. Build an expected result that can expose a fault
Coverage also compresses ordering information. Consider two suites that each exercise T1, T2, T3 and T4. One may use the single connected sequence from chapter six. Another may use fresh tasks and shorter cases with different setup histories. Their distinct valid-transition coverage can be identical even though their execution records are different.
If a defect occurs only after reopening a task twice, neither suite's percentage tells you whether that history occurred. The model's individual-arrow criterion does not count that repeated sequence as a separate item. You would need an additional, explicitly justified test to investigate the history-dependent concern. Do not quietly rename valid-transition coverage as all-history coverage.
This matters when reading reports from another person. Ask what model and criterion produced the figure, then inspect the execution record if sequence matters to your question. A percentage is a summary of a particular set of observations. It cannot preserve every detail of those observations, and a reader should not expect it to answer questions the criterion never represented.
For a focused exercise, ask a learner to design two different event sequences with full valid coverage in the initial workshop model. One is start, complete, reopen, cancel. Another is cancel, reopen, start, complete, reopen. Both are executable from Queued and cover all four valid items. The second repeats reopen, but its additional execution does not increase a four-out-of-four result.
Now ask which sequence ends in Queued. The second does; the first ends in Finished. That distinction is visible in the trace but absent from the shared coverage percentage. It is a simple way to demonstrate what a summary retains and what it loses without introducing an advanced test technique prematurely.
A test should be capable of disagreeing with the implementation. If the expected destination is copied from whatever the application just displayed, a defect can become its own answer key. Establish the expectation from the agreed model before comparing it with actual behaviour. Keep requirement uncertainty separate from implementation evidence.
For Queued-start-Active, the expected state is Active. Our initial model says nothing about sending an email or recording an audit timestamp, so we cannot call their absence a failure without an additional requirement. For an invalid attempt, however, we explicitly require refusal, unchanged state and unchanged task data; those are legitimate checks.
Invent a possible fault for practice: cancel from Queued incorrectly moves the task to Active. The all-states path start, complete would not expose it because cancel is never used. The extended valid-transition path would exercise it and produce a mismatch. This is why the missing arrow has practical significance rather than being a technical counting nicety.
Now invent a different fault: complete from Queued wrongly finishes the task. Full valid-transition coverage alone would not attempt that invalid pair. The isolated refusal test would. The two faults justify different additions to the suite. Neither is evidence that every possible bug would be found after those additions.
Ask the learner to write a third fault and name a specific test that could expose it. If they can only say “test everything,” narrow the task to one source state and one event. A precise counterexample reveals whether the model is being used to design observations rather than merely to decorate a report.
CHAPTER 10 OF 15 · Change and diagnose
10. Revise the model when a requirement adds a self-transition
Change one requirement: from Active, a new event called pause-check is valid and leaves the task Active while recording a checkpoint. This is a genuine valid self-transition. It has an event, a specified action and a destination, even though the state name does not change. The original four events retain their earlier rules.
The valid-transition count is now five. The state count remains three. If the event column is added for every state, the complete table now has fifteen positions: three states multiplied by five events. With pause-check valid only from Active, there are five valid and ten invalid pairs under the revised requirement.
The earlier path start, complete, reopen, cancel still exercises four valid transitions, but it no longer gives full valid-transition coverage. Four out of five is 80 percent. A suitable revised path is start, pause-check, complete, reopen, cancel. It exercises all five valid items while reaching the same three states as before.
This change is an effective diagnosis. A learner counting only visible state changes may omit pause-check because no circle changes. Ask what evidence would show that the checkpoint action occurred exactly as required. The valid transition's purpose lies partly in its action, not merely in moving a token to another box.
Version the model and the test set together. A report of 100 percent against yesterday's four-transition model cannot silently stand for today's five-transition model. The guide to reading learning evidence carefully is useful here: identify what was actually observed and the conditions under which that observation supports a conclusion.
CHAPTER 11 OF 15 · Change and diagnose
11. Know when a decision table answers another question
State transition testing is useful when behaviour depends on the current state and sequence of events. A decision table can be useful when combinations of conditions determine an outcome. These concerns can interact, but the models do not automatically count the same things or answer interchangeable questions.
For instance, a rule may permit reopening only when a supervisor approves and a retention period has not expired. The simple reopen arrow now needs additional conditions. A separate condition-combination analysis can help investigate those rules. It does not remove the need to identify that reopen begins in Finished and leads to Queued when permitted.
The existing ISTQB CTFL decision-table guide develops that companion technique. Use it when the problem is the combination of conditions. Return to the current state model when the problem is which event is valid after earlier events have changed the system.
Avoid treating every event with conditions as one unqualified arrow. If two guards lead to different destinations or actions, the model and coverage interpretation need enough detail to distinguish them. Our original example deliberately excludes guards so that the state-versus-transition distinction is visible before adding another dimension.
A teacher can diagnose model selection by presenting two brief specifications without naming the technique. One describes combinations of account status and approval; the other describes a task moving through a lifecycle. Ask what must be remembered to predict the next response. The answer helps reveal whether the learner is choosing a model or matching a familiar keyword.
CHAPTER 12 OF 15 · Change and diagnose
12. Choose practice from the first unsupported decision
Preserve one unassisted attempt before giving feedback. If the learner starts counting circles only after hearing the word states, record that prompt rather than treating the answer as an independent choice. On the next task, change both the labels and the order of the questions. This makes the evidence more useful: it shows whether the learner can select the criterion without the teaching cue that previously supplied it.
Equally, avoid removing helpful access supports that are unrelated to the learning target. A larger-print table or a written trace can remain available while the learner chooses transitions independently. The point is to remove supplied reasoning, not to make the page harder to read or the exercise unnecessarily difficult to operate.
When a learner gets a coverage answer wrong, examine their trace before their final percentage. Did they start in the stated state? Did they interpret each event in the updated state? Did they identify distinct items? Did they use the denominator requested? Each failure points to a smaller and more useful repair.
If current-state tracking breaks, use a short two-event trace with a visible token. If the trace is sound but coverage is inflated, compare the execution list with a deduplicated item list. If counting is sound but the wrong criterion is chosen, provide the same trace with three differently worded coverage questions.
The Mathematics error-diagnosis guide gives a useful general principle: an error in advanced work does not automatically prove that all the foundations are missing. Here, a percentage error may actually be a representation error. Repeating arithmetic would leave the source of confusion untouched.
For an adult learner studying alongside work, keep one session small enough to complete its reasoning cycle. Define a model, trace a path, calculate one criterion, propose a missing test and change a rule. A completed cycle produces inspectable evidence. Reading ten more definitions may not reveal which step remains unstable.
A supporter can ask the learner to explain a test without supplying the next event. A teacher can withhold the coverage labels until the learner has named the objects being counted. A peer can deliberately repeat an arrow and ask whether the denominator changes. These roles support independent explanation rather than a race to the official vocabulary.
CHAPTER 13 OF 15 · Check a fresh model
13. Try a fresh model without the workshop labels
Our second original model tracks a document through Draft, Submitted and Reviewed. Its events are submit, withdraw, review and revise. The valid routes are Draft-submit-Submitted; Submitted-withdraw-Draft; Submitted-review-Reviewed; and Reviewed-revise-Draft. All other pairs are invalid and must be refused without changing state or document data.
Start in Draft. First consider submit, review. Name the states exercised and the valid transitions exercised. Then build an executable sequence that covers all four valid transitions. Finally, identify one invalid pair that the full valid-transition sequence does not attempt and explain its expected refusal result.
The short sequence exercises Draft, Submitted and Reviewed, giving all three states. It exercises only the submit and review routes, giving two of four valid transitions. The familiar distinction survives despite changed state names and a different practical setting. If you reached 100 percent for both, check whether you counted destinations instead of routes.
One full valid sequence is submit, withdraw, submit, review, revise. It repeats submit in order to reach the branch needed after withdrawing. The distinct valid set still contains four items, not five. From a fresh Draft document, review is an invalid target. Its expected result is the stipulated refusal with unchanged state and data.
Now add a valid save event from Draft back to Draft that updates the saved version. What changes? There are still three states, but five valid transitions. The old suite is incomplete for valid transitions until save is exercised. This final variation checks whether a self-transition is recognised by its rule and action rather than by a visible change of state name.
Does full state coverage prove full transition coverage?
No. In our first model, start then complete reaches all three states but exercises only two of four valid transitions. State coverage answers whether the states were exercised. It does not establish that every permitted route between them was exercised.
Is repeating a transition useless?
Repeating an already exercised transition does not add a new distinct coverage item for that criterion. It may still be necessary to reach another state, check a correction or investigate a particular condition. Separate the reason for the repetition from the coverage count it does or does not increase.
Is an unchanged state always a self-transition?
No. Our invalid attempts must leave the state unchanged after refusal. The revised pause-check event is permitted and performs a specified action while retaining the state. The requirement determines the difference; the identical destination label alone does not.
Does full transition coverage mean every path has been tested?
No. A path is a sequence, and repeated cycles can create many sequences from a small set of transitions. Our coverage calculations concern individual model items. They do not establish every ordering, repetition count, timing condition or data combination.
Can I use a model if the requirements are unclear?
Use it to expose the uncertainty, then seek clarification. Label assumptions instead of quietly converting them into expected behaviour. A well-organised test against an invented rule can still give a misleading judgement about the software.
CHAPTER 15 OF 15 · Check a fresh model
15. Keep the model, execution and conclusion connected
A useful record names the model version, initial state, event sequence, expected outcomes, actual outcomes and coverage criterion. It also states what lies outside the model. Our workshop excludes timing, concurrency, permissions and data-dependent guards; complete coverage of its twelve positions cannot support claims about those omitted concerns.
After a correction, recheck the failed behaviour and consider what related behaviour may have been affected. Keep those decisions explicit. The purpose of the learning model is to make choices traceable, not to suggest that a small coverage percentage can replace professional judgement about a real system's risks and requirements.
If you can only solve a diagram whose arrows are already numbered, remove the numbers and rebuild the item list. If you can solve it only while the teacher tracks the current state, shorten the path and take over that step. The next practice should target the support still doing the learner's work.
Sources and evidence boundaries
Qualification terminology was checked on 23 October 2026 against the official CTFL certification page and ISTQB CTFL syllabus v4.0.1, section 4.2.4. The syllabus is authored and copyrighted by ISTQB and its credited authors. Our task systems, requirements, faults, calculations and practice sequences are original teaching examples, not accredited course materials or official sample examination items.
These exercises do not predict an examination score or certify testing competence. Their evidence is narrower and useful: can the learner identify the requested item, derive an executable test, explain the expected result and revise the plan when a rule changes? Carry that question back to the Education parent guide when deciding whether the learning has travelled beyond the original diagram.