Isolate the cause with one change
See this course’s project requirements
Review the Room Picker simulation from initial contract through a verified rule repair.
Keep your working files in your own notebook or software. Save a private description, checklist, and work link in My Proof.
What to include
- Define scope and observable acceptance criteria.
- Record eight diverse cases with expected and observed outcomes.
- Write a minimal reproducible bug report with impact.
- Show a one-change repair experiment and relevant comparisons.
- Deliver retest evidence and a usability hypothesis with honest limits.
Review and revise
Use these criteria to check your work and choose what to improve.
- Coverage: cases represent relevant classes and boundaries.
- Reproducibility: state, steps and results are sufficient to repeat.
- Reasoning: the repair follows evidence and preserves valid behavior.
- Handoff: claims stay within the observed version and scope.
Want more background?
The idea in everyday life
Debugging can happen before you know a programming language. You can inspect the logic connecting input to output and test whether a small change explains the observation. The simulator exposes its validation rule, allowing you to compare it with the acceptance contract. The goal is an evidenced repair proposal, not uncontrolled changes to an unfamiliar real system.
Change one relevant factor while holding the rest of the case constant.
One step at a time.
Use the sample or information you have permission to use. Keep your work as you go. You can pause between steps.
- 1
Inspect the supplied v1 rule: selected session AND whole number AND seats >= 1 AND seats < 6. Compare each part with the acceptance criteria, looking for the smallest mismatch.
- 2
Write your possible explanation (hypothesis): < 6 means less than six, so it rejects six. Predict that <= 6, meaning less than or equal to six, will accept six and still reject seven.
- 3
Change only that comparison in your written v2 rule. Keep session selection, whole-number validation and the lower bound unchanged so the experiment isolates one factor.
- 4
Trace five, six and seven through both rules. Then check zero and 2.5 to make sure the other guards still reject them. Record predicted results before marking the proposed rule accepted.
- 5
Update the bug note with the causal evidence and repair. For real products, only an authorized owner should apply a change; your complete course deliverable is the validated written simulation.
See how it works.
Fictional v1 accepts a request only if all conditions hold: a session is selected; the count is a whole number; count >= 1; count < 6. With six, only the last condition is false. Version 2 changes that condition to count <= 6. Five passes both versions, six fails v1 and passes v2, and seven fails both. Zero remains below the lower bound, and 2.5 still fails the whole-number condition. This pattern supports the proposed cause and repair. Changing the upper bound to seven would accidentally accept an invalid case and would not match the contract.
Did you cover these?
- Only < becomes <= in the rule.
- Six passes and seven fails in v2.
- Zero and fractional inputs remain invalid.
What to finish
A one-change hypothesis test with before-and-after traces.
Watch for this
Removing all validation to make one failing input pass.
How can I tell I understand it?
Show both the repaired boundary and preserved invalid-input behavior.
Quick knowledge check
Answer all 3 questions. Get at least 2 right and the lesson completes automatically.
You’ll get an explanation for each answer. Signed in? Your results save to your account.
Pass the check. We’ll save the progress.
Answer all 3 questions above and get at least 2 right. You can review the explanations and try again.
Go to the knowledge checkTools, templates, and lesson sources
Tools and templates
Tools open in a new tab so you can keep your place here.
Sources and further reading
Explore the references behind this lesson.
Source & access notes · checked 2026-09-10
Read systematic testing and boundary discussion. Original reservation examples and questions do not reproduce the university exercises.
Access: Free public university reading; examples on the source page assume more programming experience. No enrollment, credit or certificate is needed for the adapted beginner concepts here.
Reuse: Linked for reference. Examples, activities and assessments here are original; free access alone does not grant permission to reuse source text or branding.
Source & access notes · checked 2026-09-10
Read testing scope, device differences and reporting sections; source is technical further reading, not a requirement to build a website.
Access: Free public reading; no account or certificate is required for this Life Starter course.
Reuse: Linked for reference. Examples, activities and assessments here are original; free access alone does not grant permission to reuse source text or branding.
Report a problem with this lesson
Tell us what went wrong. Please leave out personal information and private project contents.