5. Decision tables and permission combinations

A decision table relates conditions to outcomes. For a private saved list, authentication and ownership are separate questions. A signed-in user may still lack access to another account. Listing combinations makes a missing branch visible before a tester chooses an API or browser tool.

Define the policy first. This lab returns 401 for an anonymous read, 403 for a foreign account and 200 for the owner. Other products may deliberately hide resource existence with 404; that requires a different documented oracle.

The four worked rows cover both boolean conditions. Ownership cannot authorize an anonymous request, so both anonymous rows expect 401. Only the authenticated-owner row succeeds. The table exposes whether a developer accidentally checked only one condition.

Conditions should describe facts established by the server, not claims accepted from a request body. A user-supplied owner flag is not authorization evidence. The API lesson later verifies the actual authenticated principal against the resource owner.

The weak table includes only the successful owner case. A service granting access to every signed-in account would pass it. Add the nearest meaningful denial, not another copy of the same success with a different display name.

Do not multiply every possible condition indiscriminately. Mark irrelevant conditions deliberately, explain impossible combinations and retain enough rows to distinguish the policy’s branches. A large table can still miss the one interaction that matters.

Write a decision table for deleting a private saved item. Use authenticated and owner conditions, with 401, 403 and 204 outcomes. Start with the authenticated owner, then add the foreign account and anonymous cases.

Give every combination a named row. Keep missing-resource behavior outside this first table and record it as a separate question. Four small cases are enough to develop the combination technique without creating an unreviewable matrix.

Step 1: Write the owner-success row. Step 2: Add anonymous and foreign-account denials.

The solution changes the success outcome to 204 while preserving both denial rules. Repeating an authenticated delete may also be idempotent, but that is a state-transition question rather than another authentication condition. Keep those concerns distinguishable in the test plan.

The domain verifier evaluates every row and checks that an ownership-bypassing variant is detected. Human review still checks that the table represents the intended policy. Exhausting a mistaken policy’s combinations does not make that policy correct.

In interviews, explain the conditions, outcomes and one faulty implementation that the table rejects. Clarify whether a condition is independent, irrelevant or impossible in the chosen scenario. Do not equate authentication with permission.

Next, examine state over time. A decision table describes combinations at one moment; repeated saves, removals and retries need a transition model as well.

Optional stretch — after the core task works: Add a separate missing-resource policy.

Computer practice: download the companion lab at https://applydjinn.com/typorithm/qa-lab-20261105.zip. Read its README, install the pinned tools and run the accepted examples before attempting a starter. The mobile reader preserves your reading and self-check progress; the local lab runs browser tests separately.