Test an access rule from specification to regression report Skill Workbench · 2026-10-21 · Original fictional teaching material A three-part mini-course: turn a permission contract into expected results, diagnose failed checks, then verify a fix without losing regression coverage. Download a checked test portfolio. For someone who can read a small table and wants to practise software testing. No coding, account or real system access is needed. - Translate a written rule into a deterministic expected result. - Separate an observed result from the test oracle and identify failed checks. - Re-run changed and unchanged cases after a fix, then write a traceable handoff. CASE CONTRACT 1. Check whether the document exists first. A missing document must return not_found, regardless of role. 2. For an existing document, archived documents return deny for every role. 3. For an active document, an admin may edit any owner’s document. An editor may edit only a document they own. A viewer may not edit. 4. Compare the observed result with the expected result. An allowed operation is not automatically a passing test: the contract may require deny. These are exercise rules, not a security design for a real application. 1. Build the expected-result table Apply the rule in the stated order before looking at what the software did. Testing begins with a promise about behavior. Here the promise is a small document-editing contract, not a complete security design. The inputs are role, ownership relationship and document state. The output is one of three explicit strings. Write the expected output from the contract before examining the observed output, or an implementation mistake can quietly become your assumed rule. Some rules override others. A missing document is checked first, so even an admin receives not_found. If the document exists but is archived, it receives deny before any role is considered. Only an active document reaches the role and ownership check. An admin may edit; an editor may edit only their own document; a viewer may not edit. This ordering is a decision procedure you can explain and reproduce. A useful test varies one relevant condition at a time. Comparing an editor’s own active document with another owner’s active document isolates ownership. Comparing an admin’s active document with an archived one tests the archive override. Do not confuse a denied operation with a failed test: deny is a passing result when it matches the contract. The table you produce is a test oracle for this exercise. The strings in this exercise deliberately distinguish missing from denied. A real product could specify a different response for privacy or security reasons. That would require a different oracle; it is not a reason to silently substitute your preferred policy here. If the contract were ambiguous, record the ambiguity before treating either interpretation as a verified result. Worked example: the override wins Input: role=admin, owner_relation=other, document_state=archived. The document exists, so the first rule does not apply. It is archived, so stop at the second rule and expect deny. Do not continue to the admin allowance. If a build returns allow, the test fails even though the user is an admin. Apply the same contract to these four independent inputs. No observed result is supplied yet; you are constructing the oracle. Build the oracle case_id | role | owner_relation | document_state P01 | editor | own | active P02 | editor | other | active P03 | admin | other | missing P04 | viewer | own | archived YOUR EXERCISE P01 expected result: __________________ P02 expected result: __________________ P03 expected result: __________________ P04 expected result: __________________ Your explanation: Explain the order of the checks using P03 and P04. Write enough detail that another tester could reproduce your reasoning. FEEDBACK AND WORKED SOLUTION P01=allow, P02=deny, P03=not_found, P04=deny. P03 tests the missing-document override. P04 is denied at the archive step; the viewer restriction would also deny an active document, but it is not the first applicable rule here. P01 expected result → allow. The document is active and belongs to this editor. P02 expected result → deny. An editor’s allowance does not extend to another owner’s document. P03 expected result → not_found. Check existence before applying the admin allowance. P04 expected result → deny. Archive status produces deny before the viewer role is evaluated. TRANSFER QUESTION Before moving on, identify a pair of inputs that differs only in ownership. That pair helps you explain what the ownership condition changes. 2. Diagnose the baseline build Compare the oracle with observations and preserve the evidence for every mismatch. You now have a contract and a method for deriving expected results. The next table adds observed results from a fictional staging build. Keep both columns. A failing check is a disagreement between expected and observed behavior; an empty field is missing work, not an implied deny or a passing case. Calculate each expected result independently, then compare the two values. A defect report should contain the case ID, relevant inputs, expected output, observed output and the rule that explains the difference. “Access is broken” is harder to investigate than a report that identifies the exact ownership or archive branch. Keep the passing checks too, because a fix may disturb them. Several symptoms may share a cause, but the table does not prove their internal cause. T02 and T04 both return allow incorrectly; this is not evidence that the same code path produced them. Report what the records establish and label any proposed cause as a hypothesis. Likewise, do not invent severity, customer impact or a release decision that requires information outside this case. Use the feedback to correct your oracle if needed, then write a short developer handoff. The automatic checker can compare the fixed fields and defect IDs. It cannot assess whether your explanation is persuasive, complete or suitable for a real release. The downloadable portfolio keeps the explanation explicitly ungraded so a future reviewer can distinguish the two. Worked example: a denied operation can pass T03 is a viewer editing their own active document. The oracle is deny and the observed value is deny, so this test passes. T02 is an editor editing another owner’s active document: expected deny, observed allow. That row fails. The defect is the mismatch, not the presence of the word deny. Use the already published baseline case below. Reusing this case inside a learning sequence does not create another occupational page or another distinct dataset. Observed staging checks check_id | role | owner_relation | document_state | observed T01 | editor | own | active | allow T02 | editor | other | active | allow T03 | viewer | own | active | deny T04 | admin | other | archived | allow T05 | admin | other | active | allow T06 | viewer | other | missing | deny T07 | editor | own | archived | deny T08 | admin | other | missing | not_found YOUR EXERCISE Expected result for T01: __________________ Expected result for T02: __________________ Expected result for T03: __________________ Expected result for T04: __________________ Expected result for T05: __________________ Expected result for T06: __________________ Expected result for T07: __________________ Expected result for T08: __________________ Failed check IDs: __________________ Your explanation: Name the failing checks, explain the rule each violates and propose one follow-up regression check. Your writing is included in the export but is not automatically graded. FEEDBACK AND WORKED SOLUTION The expected sequence is allow, deny, deny, deny, allow, not_found, deny, not_found. T02, T04 and T06 disagree with the observations. A useful handoff separates these three defects rather than reporting only “three tests failed.” Keep the full eight-row report so the passing cases can be re-run after a fix. Expected result for T01 → allow. An editor can edit their own active document. Expected result for T02 → deny. An editor cannot edit another owner’s document. Expected result for T03 → deny. A viewer remains read-only, even for their own document. Expected result for T04 → deny. Archive status takes precedence over the admin role. Expected result for T05 → allow. An admin can edit an existing active document belonging to another owner. Expected result for T06 → not_found. Existence is checked first: missing returns not_found, not deny. Expected result for T07 → deny. An archived document is read-only for an editor. Expected result for T08 → not_found. Missing returns not_found even for an admin. Failed check IDs → T02, T04, T06. Compare every observed value with its contract result. T02 permits another owner’s edit, T04 permits an archived edit, and T06 reports the wrong missing-document result. TRANSFER QUESTION Choose one failed row and state the smallest change in inputs that would test the neighboring allowed or denied behavior. 3. Verify a fix with neighboring cases Check the old failures and nearby passing behavior before writing the final report. A change that fixes a failed example can introduce a new mistake. Re-running only the original failing rows is therefore a weak verification strategy. Retest those rows and include neighboring cases that the fix could affect. You are looking for both the intended repair and accidental widening or narrowing of access. The next table is a new post-fix fixture, not another view of the baseline data. R01 revisits the other-owner editor case, R02 the archived admin case and R03 the missing-document response. R04 guards an editor’s own active document. R05 guards a viewer’s own active document, while R06 guards a valid admin edit. Together they keep the contract’s distinctions visible. Derive expectations from the same contract, not from a note that says “fixed.” A changed observed value is only useful when it now agrees with the rule. If R05 permits a viewer’s edit, the new build still has a reproducible failure even if the three original failures are repaired. Report the remaining mismatch and the evidence supporting it. Your final portfolio combines all three stages. Include the rule-order explanation, the baseline defect handoff and the post-fix review. After changing any answer, check that stage again before downloading; an old score must not describe new work. Passing this fixed exercise demonstrates agreement with its fixtures, not comprehensive testing of a product or professional certification. Worked example: “fixed” is not the oracle R01 is editor/other/active with observed deny. The rule still expects deny, so the original ownership symptom is repaired in this row. This says nothing about a viewer. R05 must be checked separately rather than inferred from R01’s success. Compare these post-fix observations against the original contract. Give the remaining failed check IDs and the number of checks that pass. Post-fix regression checks case_id | role | owner_relation | document_state | observed R01 | editor | other | active | deny R02 | admin | other | archived | deny R03 | viewer | other | missing | not_found R04 | editor | own | active | allow R05 | viewer | own | active | allow R06 | admin | other | active | allow YOUR EXERCISE Remaining failed check IDs: __________________ Number of passing checks: __________________ R05 expected result: __________________ What does this evidence support?: __________________ Your explanation: Write the post-fix handoff: what is repaired in the supplied rows, what remains wrong, and which input/rule justifies your conclusion. FEEDBACK AND WORKED SOLUTION Expected R01–R06: deny, deny, not_found, allow, deny, allow. Only R05 differs from its observation. Five checks pass, but the review still records a viewer-edit defect. This is a bounded report about these six checks, not a declaration that the application is otherwise secure. Remaining failed check IDs → R05. R05 allows a viewer to edit an active document. All other observed results match the contract. Number of passing checks → 5. Six checks were executed; R05 is the sole mismatch, so five pass. R05 expected result → deny. A viewer cannot edit, including a document they own. What does this evidence support? → remaining-defect. The fixed fixture provides enough evidence to identify one remaining mismatch. It does not support closing the review as fully passing. TRANSFER QUESTION Suggest one additional case that changes only a single condition from R05. State its expected result and explain what regression it would catch. PORTFOLIO REVIEW Keep all three exercise records and explanations. Fixed checks can be scored; explanations are ungraded. Do not infer occupational certification. SOURCE O*NET 15-1252.00 task 21669 · 08/2025 · Develop or direct software system testing or validation procedures, programming, or documentation. O*NET 15-1252.00 task 21670 · 08/2025 · Modify existing software to correct errors, adapt it to new hardware, or upgrade interfaces and improve performance. https://www.onetonline.org/link/summary/15-1252.00 O*NET 31.0, USDOL/ETA, CC BY 4.0. Skill Workbench authored the teaching and fictional practice; no endorsement.