Free mini-course · 45 minutes · No account needed
Test an access rule from specification to regression report
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.
What you will make
A three-part test portfolio containing rule decisions, a baseline defect list and a post-fix regression review, with your own explanation beside the checked fields.
- 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.
The exercise contract
All records, policies and outcomes in this course are fictional. The supplied contract determines the expected answers.
- Check whether the document exists first. A missing document must return not_found, regardless of role.
- For an existing document, archived documents return deny for every role.
- 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.
- 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.
Apply the rule in the stated order before looking at what the software did.
1. Build the expected-result table
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.
Try it yourself
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 |
Numbers use the units in each label. Blank answers are incomplete. ID lists can use commas, spaces or semicolons.
Read this exercise’s 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.
Apply the idea
Before moving on, identify a pair of inputs that differs only in ownership. That pair helps you explain what the ownership condition changes.
Compare the oracle with observations and preserve the evidence for every mismatch.
2. Diagnose the baseline build
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.
Try it yourself
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 |
Numbers use the units in each label. Blank answers are incomplete. ID lists can use commas, spaces or semicolons.
Read this exercise’s 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.
Apply the idea
Choose one failed row and state the smallest change in inputs that would test the neighboring allowed or denied behavior.
Check the old failures and nearby passing behavior before writing the final report.
3. Verify a fix with neighboring cases
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.
Try it yourself
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 |
Numbers use the units in each label. Blank answers are incomplete. ID lists can use commas, spaces or semicolons.
Read this exercise’s 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.
Apply the idea
Suggest one additional case that changes only a single condition from R05. State its expected result and explain what regression it would catch.
Save your three-part portfolio
Check all three exercises and include an explanation for each. You may download a portfolio with mismatches for later review; it clearly records which checks passed. Editing an answer or explanation invalidates that exercise’s previous check.
Complete and check all three exercises to prepare your portfolio.
Inspect the portfolio before downloading
Your portfolio will appear here after each exercise has been checked.
Download before leaving. Course answers stay in this page and are cleared on refresh; they are not sent to a server or added to the older course progress tracker.
Source and scope
Occupational task context comes from the O*NET® 31.0 Database, USDOL/ETA, under CC BY 4.0. View the occupation.
Task 21669 · 08/2025 · Develop or direct software system testing or validation procedures, programming, or documentation.
Task 21670 · 08/2025 · Modify existing software to correct errors, adapt it to new hardware, or upgrade interfaces and improve performance.
Skill Workbench selected this context and authored the teaching, examples, practice rules, data and feedback. USDOL/ETA has not approved, endorsed or tested these additions. O*NET® is a trademark of USDOL/ETA. Matching the fixed checks does not certify occupational competence.