A learner can remember what a decision table is and still miss the one combination that reveals a faulty software rule. Preparing for ISTQB Certified Tester Foundation Level, or CTFL, therefore needs more than recognising the names of test techniques. You need to turn a requirement into conditions, expected actions and concrete tests, then explain exactly what those tests cover.
For CTFL decision-table practice, start with a precise rule, list its feasible condition combinations, determine the required action for each, and choose test data that exercise those combinations. Checking each condition once is insufficient when the result depends on how conditions occur together. A table also cannot resolve an unclear requirement by quietly inventing a policy.
This guide uses the CTFL v4.0 family and the official v4.0.1 syllabus dated 15 September 2024, checked on 23 October 2026. It develops one applied learning task within that qualification. It is not a complete certification course, an official sample paper, an endorsed training programme or evidence of professional competence by itself. Every workshop, person, rule, test result and later change below is an original fictional teaching example.
The Education parent guide explains the larger purpose: learning should remain usable when the surface changes. Here that means recognising a combination problem even after the words, table orientation or expected outcome change.
Find your next learning step
Build and check an original decision table, distinguish feasible from irrelevant conditions, and derive tests that expose a faulty rule.
ROUTE 1 · CHAPTERS 1–3
Read the decision
Identify the qualification task, rule and observable conditions.
ROUTE 2 · CHAPTERS 4–6
Construct and test
Enumerate combinations, interpret feasibility and derive concrete tests.
ROUTE 3 · CHAPTERS 7–9
Interpret the evidence
Calculate coverage, simplify carefully and expose a faulty shortcut.
ROUTE 4 · CHAPTERS 10–12
Revise the learning task
Adapt a changed rule, select techniques and practise deliberately.
ROUTE 5 · CHAPTERS 13–15
Check independent control
Try a new decision, answer useful questions and consult sources.
Full chapter index · Independent learning check · Education parent guide
Full chapter index
Read the decision · Chapters 1–3
Construct and test · Chapters 4–6
Interpret the evidence · Chapters 7–9
Revise the learning task · Chapters 10–12
Check independent control · Chapters 13–15
CHAPTER 1 OF 15 · Read the decision
1. Identify the learning move behind the terminology
A definition gives you a starting vocabulary. It does not yet show whether you can construct a test. A candidate might say that decision tables connect conditions and actions, then choose three examples that all produce the same outcome. Their memory is working; their coverage reasoning still needs attention.
The official CTFL overview links the current syllabus and sample materials. Within the syllabus, learning objective FL-4.2.3 requires applying decision table testing to derive test cases. The verb matters. Reading a completed table and making a defensible table from a requirement are different performances.
Try a small diagnosis before adding more study hours. Give the learner a short rule and ask which information changes the outcome. Then ask for one combination that should succeed and one that should not. Finally, change only one condition in the unsuccessful example. Can the learner predict whether the result should change, and explain why?
If they cannot identify the conditions, begin with requirement reading. If they identify conditions but omit combinations, work on systematic enumeration. If their combinations are complete but expected results are wrong, revisit the rule. If their table is right but their test data do not represent its values, teach the move from an abstract condition to an executable example.
This keeps feedback useful. “Study testing harder” gives little direction. “You treated a missing consent record as irrelevant whenever payment existed” identifies a repair. A later independent task can check that exact relationship without repeating the same story.
Our fictional community workshop uses three recorded conditions: the applicant is eligible for this workshop, the required consent is present, and payment is confirmed. Call these E, C and P. Each is either true or false in this deliberately simplified model.
The stipulated rule is ordered. If E is false, decline the booking. If E is true but C is false, request consent. If E and C are true but P is false, request payment. Confirm a booking only when all three are true. For this exercise, the system returns exactly one of these four outcomes.
The ordering removes an ambiguity. A person can lack both consent and payment. Our rule says to request consent first. Another real organisation might request both simultaneously, use a different sequence, or handle payment before accepting an application. None of those alternatives can be assumed from the words “consent and payment required”.
Maya, our fictional learner, initially writes “if payment is confirmed, confirm booking”. She has extracted a familiar administrative signal and promoted it into the whole rule. Reading the requirement aloud exposes the omission: payment is necessary for confirmation in this model, but payment alone is insufficient.
Before drawing, write a plain-language explanation of one difficult case. An ineligible applicant with consent and confirmed payment must still be declined under the stipulated rule. That sentence tests the precedence relationship. If the team disagrees about it, the next job is clarification, not faster table formatting.
Keep the model modest. We are not designing a real payment or safeguarding system. Refunds, age verification, record authenticity and operational permissions would require additional requirements. Their absence here is a boundary of the exercise, not permission to ignore them in practice.
A condition needs a meaning that test data can represent. “The applicant looks ready” is too vague for our model. “The eligibility flag is true under the supplied requirement” is testable within a controlled exercise. In real work, the source of that flag would also need investigation.
Distinguish a condition from the action it helps determine. Eligibility, consent and confirmed payment are inputs to this decision. Decline, request consent, request payment and confirm are expected outputs. Putting “booking confirmed” among the inputs would make the model circular unless a different requirement explicitly used an existing booking state.
Also distinguish confirmed payment from a button click. A learner who selects “Pay” has performed an action; the stipulated P condition concerns the resulting confirmation record. If the test setup contains only a payment attempt, it does not establish P as true. The example is about reading a defined status accurately, not offering payment-processing advice.
A useful preparation note gives each condition its short label, its plain meaning and how the fictional test setup will establish its value. For C, the note might say “required consent record present: yes or no”. It should not silently switch later to “parent has been contacted”. Those are different propositions.
Maya checks her vocabulary by describing one test without letters: the applicant is eligible, the required consent record is absent, and payment has been confirmed. She then predicts “request consent”. When she can move comfortably between the words and E=true, C=false, P=true, the notation is serving understanding.
If a word remains unclear, keep a question beside it. A table with an explicit unresolved definition is more useful than a tidy table built on three different private meanings of “confirmed”.
CHAPTER 4 OF 15 · Construct and test
4. Enumerate the combinations without relying on memory
Three independent Boolean conditions produce eight possible combinations: two choices for E, two for C and two for P, giving 2 × 2 × 2 = 8. In this exercise, all eight are feasible because the supplied model permits each record combination to exist.
Use a stable listing pattern. Hold E false while C and P vary through their four combinations, then hold E true while repeating the same C/P sequence. You are creating an accounting method. The pattern reduces the chance of forgetting an awkward combination simply because it does not resemble a successful booking.
The table below displays rules as rows for comfortable reading. Each row corresponds to one rule column in a conventional decision table. Changing the display orientation does not change the combinations or outcomes.
| Rule | E: eligible | C: consent present | P: payment confirmed | Required outcome |
|---|---|---|---|---|
| R1 | False | False | False | Decline |
| R2 | False | False | True | Decline |
| R3 | False | True | False | Decline |
| R4 | False | True | True | Decline |
| R5 | True | False | False | Request consent |
| R6 | True | False | True | Request consent |
| R7 | True | True | False | Request payment |
| R8 | True | True | True | Confirm |
Now verify the list independently. Each E value appears four times, each C value four times and each P value four times. More importantly, there are no repeated triples. Balanced counts alone are insufficient: a duplicated combination could conceal an omission while preserving attractive totals.
Ask Maya to locate E=true, C=false, P=true without starting at the top. She should identify R6 and explain its result from the requirement. A learner who can only recite rows in order may have memorised the display without controlling the relationship.
CHAPTER 5 OF 15 · Construct and test
5. Separate an irrelevant condition from an impossible combination
For R1 to R4, changing consent or payment does not change the required decline outcome because eligibility is false. Within this decision, C and P are irrelevant to that outcome. They are not necessarily irrelevant to every other process in the organisation.
An impossible combination is different. Suppose a separate, explicit system invariant said that a confirmed payment record could never exist without a consent record. That would make some combinations infeasible within the stated model. Our original requirement contains no such invariant, so Maya must not remove R2 or R6 merely because she finds them administratively unusual.
The CTFL syllabus v4.0.1, section 4.2.3, distinguishes irrelevant condition values, infeasible combinations and feasible rule coverage. Its formal framework supports this distinction. The workshop assumptions and examples are our own explanation of how the distinction affects a learner's choices.
Try a counter-question: where is the evidence that the combination cannot occur? “It should not happen” may describe a desired process, an expectation or a missing validation check. It does not automatically describe an enforced impossibility. A tester needs the requirement and system context to decide which meaning applies.
Maya marks the claim as a question instead of deleting a row. That preserves useful uncertainty. If clarification later establishes the invariant, she can revise the feasible set and explain the change. If it does not, the awkward combination remains a candidate for testing.
The educational habit is simple but powerful: unusual, irrelevant and impossible are three different descriptions. Choosing among them changes what you test, so choose from evidence rather than convenience.
CHAPTER 6 OF 15 · Construct and test
6. Derive concrete tests from the abstract rules
A rule row is not yet a complete test procedure. It says which condition combination matters and what outcome is required. The learner still needs a controlled setup, an action that invokes the decision and an observable result.
For R6, create a fictional applicant record whose eligibility is true, required consent is absent and payment confirmation is present. Invoke the booking decision. Expect a consent request and no confirmation. Record the actual returned outcome separately. Do not replace “actual” with the result you hoped to see.
For R4, create an ineligible record with consent and confirmed payment. Invoke the same decision and expect decline. This test is particularly useful against Maya's initial mistaken rule because the payment condition is true while eligibility is false. A familiar happy-path test would leave that error hidden.
The test data should differ only where intended. If the R6 record also has an unrelated account suspension that changes system behaviour, the observed result may no longer isolate the rule under study. In a real project, you would need to understand the other applicable requirements. In this small exercise, stipulate that no other decision rule intervenes.
Write enough detail for another learner to repeat the test without guessing. Avoid both extremes: “test payment” is underspecified, while a long story about an applicant's hobbies adds no relevant control. Name the record values, decision action and expected outcome.
For a paper exercise, mentally executing the rule is useful practice, but label it honestly. A predicted result is not evidence that actual software has run. Once the learner understands that boundary, they can discuss design and execution without confusing a completed worksheet with a completed test session.
CHAPTER 7 OF 15 · Interpret the evidence
7. Count coverage against the table you actually used
Suppose Maya executes R1, R5, R7 and R8 once each. On our full eight-rule table, she has exercised four of eight feasible rules: 4/8 = 50%. All four possible outcomes have appeared, but that is not the same coverage statement.
Suppose she instead executes R1 and R8. Every condition has appeared both false and true across those two tests. Yet six combinations remain unexercised. This is why “each condition was checked” cannot stand in for the combination coverage the task asks you to calculate.
The denominator belongs to a specific model. Keep the table version and the set of feasible rules visible beside the calculation. A percentage detached from those definitions can sound precise while answering a different question.
Coverage also concerns exercise, not success. If R6 runs and returns an incorrect confirmation, that rule has been exercised and a discrepancy observed. Describing it as “not covered because it failed” mixes coverage with correctness. You need both the execution account and the result account.
Similarly, a hundred repeated R8 tests do not create a hundred distinct rule combinations. They may have another purpose, such as checking repeated behaviour under specified circumstances, but they do not fill the missing rows of this table. Count unique exercised rules for this coverage calculation.
Maya repairs her study note by writing two sentences: “Four of eight feasible rules were exercised. All four expected outcome types were represented.” Both statements can be true together. Their separation is a useful sign that she understands what her numbers describe.
CHAPTER 8 OF 15 · Interpret the evidence
8. Use simplification without hiding what changed
Our eight rules can be described more compactly. E=false leads to decline regardless of C and P. E=true and C=false leads to a consent request regardless of P. The remaining two cases distinguish payment absent from payment confirmed when E and C are true.
That compact account contains four decision rules. A dash can represent a condition that does not affect a particular outcome, provided the meaning is declared. It must not mean “we forgot to decide” or “any value is convenient”. Formal minimisation algorithms are outside the CTFL Foundation syllabus scope; this example only makes an obvious outcome equivalence visible.
The compact and full displays support different explicit coverage denominators. Testing one representative for each compact rule does not mean you executed every triple in the expanded display. State which display and coverage criterion you are using. Avoid a percentage that changes meaning halfway through the explanation.
Maya compares R1 and R4. Both decline, but one has all false inputs and the other has consent and payment true. If a faulty implementation incorrectly lets payment override eligibility, R4 may expose it while R1 does not. A compact expected rule does not make every possible implementation error identical.
This is where educational judgement matters. For a specified exam question, answer the model and criterion actually supplied. For a real testing task, agree the scope, risks and additional tests with the responsible team. The smallest representation is not automatically the most informative practical test selection.
Keep the full table while learning. Once you can explain exactly which rows a compact rule represents, simplification becomes a tool for clarity instead of a way to lose the difficult cases.
CHAPTER 9 OF 15 · Interpret the evidence
9. Make the faulty rule visible through a counterexample
Imagine the fictional software contains this fault: if payment is confirmed, it returns “confirm”, even when eligibility or consent is missing. This is a stipulated fault for learning, not a claim about a real system.
R8 passes because all conditions are true. R7 also behaves as expected if the implementation requests payment when P is false. A learner testing only those two cases may feel reassured. Their tests have not examined the misplaced priority.
R4 provides a direct counterexample. Its input has E=false and P=true. The requirement says decline; the faulty implementation confirms. R6 provides another: E=true, C=false, P=true should request consent, but the faulty implementation again confirms.
Ask why these tests matter before running them. “They are negative tests” is a broad label. The sharper explanation is that they separate confirmed payment from the other necessary conditions. They expose the particular mistaken implication “payment confirmed therefore booking confirmed”.
A useful discrepancy note names the setup, expected result, actual result and relevant rule. It can say: “Under R6, an eligible record with absent consent and confirmed payment returned confirm instead of request consent.” That account gives another person a reproducible problem without guessing its cause.
Do not claim to know the code fault merely from one wrong output. Our exercise stipulated the implementation error to teach counterexample selection. In a real investigation, several causes could produce the same visible discrepancy. Report what was observed, then investigate explanations at the appropriate level.
Compare two faults that a happy path cannot separate
Imagine a second faulty implementation. It handles eligibility correctly, but once eligibility is true it ignores missing consent whenever payment is confirmed. R4 now returns decline, while R6 still returns an incorrect confirmation. The two faulty implementations agree on the successful R8 case but disagree on R4.
This gives Maya a sharper reason to preserve more than one awkward example. R8 establishes what happens when all requirements are satisfied. R4 investigates whether payment can override eligibility. R6 investigates whether payment can override consent for an eligible applicant. Their value comes from the relationship each separates, not from their position in the grid.
Write the predictions before revealing the fictional outcomes. If Maya sees R4 decline and R6 confirm, which stipulated fault is consistent with that pattern? The second fault fits. The first does not, because it would also confirm R4. That reasoning is conditional on the two candidate explanations we supplied. It does not establish that those are the only possible causes in real software.
Now introduce a third possibility: the test setup accidentally included a consent record. The apparent R6 execution would no longer represent R6. Before arguing about implementation behaviour, inspect the actual setup. This illustrates why a test account needs evidence of its inputs as well as a screenshot of its output.
The learner can organise these possibilities without becoming a developer. They can ask whether the intended combination was created, whether the decision was invoked and whether the observed result matches the requirement. More technical investigation can follow when appropriate. Clear observation helps the next person investigate; an overconfident diagnosis can send them in the wrong direction.
CHAPTER 10 OF 15 · Revise the learning task
10. Change the requirement and revise the model
Now add a new fictional requirement: applicants with an approved fee waiver do not need confirmed payment. Let W represent an approved waiver. Consent and eligibility are still required. Confirmation now needs E and C and either P or W.
The old eight-row table is no longer a full account because it has no waiver condition. With four independent Boolean conditions, a full enumeration would contain sixteen combinations before any justified removal or simplification. Writing “waivers accepted” in the margin does not update the test model.
Consider E=true, C=true, P=false, W=true. Under the new rule, confirmation is required. Under the old rule, the same first three values led to a payment request. This case makes the changed relationship observable.
Now consider E=true, C=false, P=false, W=true. A waiver does not replace consent. The expected result remains a consent request. The learner who memorised “waiver means confirm” has repeated Maya's original mistake with a new administrative signal.
Ask which old tests still help and which new combinations are necessary. You need not throw away every earlier example. Some still exercise unchanged relationships, but their setup must now specify the waiver value. Others must be added to examine the newly permitted path.
This is changed-context transfer within the same model. The learner retains the method—define, enumerate, determine, derive, check—while revising the content. They do not preserve an obsolete answer because it once belonged to a correct table.
CHAPTER 11 OF 15 · Revise the learning task
11. Recognise when another technique answers the better question
A decision table is useful for combinations of conditions and outcomes. It is not a universal replacement for every testing technique. The job comes first; the diagram follows.
If the question concerns exactly where an age threshold changes eligibility, numerical boundary work may be useful. Our table assumes that E has already been determined. It does not by itself show whether ages just below, at and above the threshold are classified correctly.
If the question concerns what happens after a booking moves from requested to confirmed to cancelled, the history and permitted transitions matter. A snapshot of E, C and P may not capture that sequence. You would need a model that represents the relevant states and events.
If the question concerns correcting one defect without disturbing previously valid behaviour, the Additional Mathematics guide to rechecking corrected work offers an educational analogy to confirmation and regression. It does not teach CTFL decision-table derivation, and the analogy should not be mistaken for a software qualification.
These distinctions improve study choices. A learner can be weak at modelling combinations while being perfectly capable of checking numerical boundaries. Naming the specific task avoids restarting every chapter because one answer was wrong.
For the wider professional context, the Software Development guide explains the wider job of building and maintaining a useful product. This article's immediate task remains narrower: explaining and testing the conditions of one decision. A tidy table is useful evidence of that skill, not a complete account of software quality.
The existing Cambridge AS Computer Science guide to choosing test data develops normal, abnormal and boundary cases under its own syllabus. Use it for that qualification’s test-data task. Here the additional CTFL task is to account systematically for feasible combinations of several conditions, rather than substitute a few boundary values for a decision table.
CHAPTER 12 OF 15 · Revise the learning task
12. Build a study session that produces a new capability
Begin with a rule the learner can understand without specialist business knowledge. Ask them to underline inputs and circle outcome words. Have them explain one awkward case before they draw a table. This prevents the grid from hiding a reading problem.
Next, build the complete feasible set together. The teacher can model the first few combinations, then reduce prompts. Ask the learner how they know the list is complete. An answer such as “it looks finished” signals that systematic enumeration still needs work.
Then ask for two concrete test cases and a coverage calculation. Change the executed set and calculate again. Include one failed execution so that the learner must separate “exercised” from “passed”. The arithmetic is straightforward; interpreting the count is the real learning task.
Finish with a delayed fresh example. Replace workshop bookings with a fictional document-release rule using reviewer approval, required attachment and publication permission. Preserve the combination structure but change the wording. If the learner needs the original table beside them, offer support and record which step still depends on it.
For parents supporting an adult or older student, ask for the reasoning rather than an official pass prediction. For teachers and study partners, keep model answers hidden until the learner has committed to an explanation. For the learner, record the first uncertain decision, not only the final correct option.
The Bukit Timah guide to prerequisite and method diagnosis illustrates a useful general distinction: missing knowledge and choosing the wrong operation call for different repairs. Apply that diagnostic habit without pretending that mathematics practice and professional software testing are interchangeable.
A short study record can preserve these distinctions in three ordinary sentences. Name the first uncertain move, describe the repair and state the fresh check. For example: “I omitted the paid-but-ineligible case. I rebuilt the combination list using a fixed enumeration pattern. I then found all four combinations in a new two-condition document rule without looking at the workshop table.” That is a learning account, not a promised examination outcome.
If the fresh task fails, keep the successful part visible. Maya might enumerate accurately but misread the new priority order. Repeating enumeration drills would miss the new problem. Ask her to explain which sentence authorises the expected result, then change the task's wording again. The next practice should answer the question raised by the evidence you actually have.
CHAPTER 13 OF 15 · Check independent control
13. Try a fresh decision without the workshop labels
Here is an original independent learning check. A fictional study club releases a document only when the requester is authorised and the document has completed review. If authorisation is absent, deny release. If authorisation is present but review is incomplete, return “await review”. Otherwise release it.
Name the two conditions A and R. List the four combinations before reading further. Then identify which pair of tests would show both true and false values for each condition while leaving combinations untested. Finally, choose a case that could expose a faulty rule saying “review complete means release”.
The complete combinations are false/false, false/true, true/false and true/true. Their expected outcomes are deny, deny, await review and release. A test using false/false and another using true/true exercises both values of both conditions but only two of the four combinations.
False/true is the important counterexample to the stipulated faulty rule. Review is complete, but authorisation is absent, so release must be denied. Explaining that relationship matters more than reproducing the letters in the same order as this paragraph.
Now change the fictional rule: a document marked public can be released without requester authorisation, but review must still be complete. What new condition is needed? Which earlier denial can now become release? Which earlier denial remains denial when review is incomplete? Write the revised requirement before attempting a revised table.
If your answer changes consistently with the new public-status condition, you are beginning to control the method. If you simply add another outcome word to the old grid, return to the distinction between conditions and actions. This check has no official score or certification meaning.
Does every condition need its own separate test?
Not in the sense of testing each input once and assuming combinations are covered. One test assigns values to several conditions together. The relevant coverage question concerns the feasible decision rules in the stated table. Match the question's criterion rather than inventing a universal test count.
Can I delete combinations that would be unusual in normal use?
Only with a justified model boundary or explicit infeasibility. An unusual record might be exactly where an implementation error appears. Keep the evidence for any removed combination visible. If the requirement is silent, identify the uncertainty instead of deciding the policy yourself.
Is one test per outcome enough?
It may show that each outcome can occur, but it need not exercise every feasible combination. Our four-outcome workshop has eight full-table rules. State the coverage measure before presenting a percentage. Outcome variety and combination coverage are related observations, not identical ones.
Does full decision-table coverage prove the software is correct?
No. It describes the exercised rules of a specified model. The requirements might be incomplete, other behaviours may matter, and a test's concrete data may not represent every relevant case. A coverage account is useful precisely when its scope remains visible.
Should I memorise the official sample answers?
Use official materials to understand the reasoning and expected task level. Then practise with a changed requirement and explain why the derived tests change. Recognising a familiar answer is weaker evidence of readiness than applying the method to an appropriate unfamiliar example.
Does completing this guide mean I am ready for the whole CTFL exam?
No. Decision-table derivation is one part of a larger syllabus. Check the current official materials and your examination provider's arrangements. This guide helps you locate and repair a specific learning gap; it does not assess the rest of your preparation.
CHAPTER 15 OF 15 · Check independent control
15. Carry the method into the next learning task
Before closing your notes, choose one requirement you can explain in ordinary language. Write the conditions, their meanings, the feasible combinations and the required outcomes. Derive a concrete test that could reveal an attractive but incorrect shortcut.
Then hand your account to another learner. Ask them to explain one row and identify the source of its expected result. If they need to guess a definition, improve the account. If they disagree with the requirement itself, preserve that distinction: a disputed policy and a badly implemented policy require different conversations.
The Singapore English guide to performance on unfamiliar topics offers a complementary reading route when the difficulty begins with understanding a new brief. Reading accurately supports testing, but it does not replace the technical model or professional responsibilities.
The gold standard here is a learner who can say what was tested, why it mattered, what happened and what remains unknown. That account survives a changed story because it rests on relationships rather than a remembered arrangement of boxes.
Sources and evidence boundaries
The ISTQB CTFL overview and its linked Foundation Level syllabus v4.0.1, particularly FL-4.2.3 and section 4.2.3, were checked on 23 October 2026. ISTQB and the syllabus authors are acknowledged for the qualification framework and formal terminology. All tables, workshop rules, document-release examples and teaching sequences here are original explanatory material. No official examination item, measured improvement, professional accreditation or employment outcome is claimed.