Define expected behavior
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
A bug report needs a reason that the observed behavior is wrong. That reason may be a requirement, a documented convention or a user task. Our fictional Room Picker reserves practice workshop places without sending real bookings. You will evaluate a written product simulation, so software access, personal accounts and coding experience are unnecessary.
A test compares observed behavior with a stated expectation.
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
Create a test notebook for Room Picker v1. Copy its rules: accept whole-number seat requests from one through six, require a chosen session, and show a review screen before a practice confirmation.
- 2
Turn each rule into an observable statement. For example, entering six with a session selected should show a review screen with six seats, not immediately confirm or reject the request.
- 3
Define the exercise’s boundaries: only the supplied seat selection and review flow are tested. Payment, accounts and a real booking database do not exist in this practice scenario.
- 4
Write a simple environment label such as "paper simulator, v1, English." If using your own authorized demo, also record its actual browser and build, but keep this separate from the supplied evidence.
- 5
Create a pass/fail/pending column. A missing observation is pending, not passed. Save the acceptance criteria as the reference for selecting cases and judging the later simulated outputs.
See how it works.
Fictional acceptance contract: a request needs a selected session and an integer from 1 to 6. With valid input, the Next button opens Review, which repeats the session and seat count. Confirm then displays "Practice saved; no booking sent." Invalid input stays on the form and describes the problem without losing the selected session. A concrete criterion is: "Given session Cedar and seats=6, pressing Next shows Cedar and 6." This separates expected behavior from appearance. A blue button is not the success condition unless color itself is part of a specific requirement. The course tests only this supplied simulation.
Did you cover these?
- Integer range includes both endpoints.
- Review precedes confirmation.
- Evidence is labeled as a simulation or actual demo.
What to finish
A scoped test contract with observable acceptance criteria.
Watch for this
Calling personal preference a bug without explaining the violated task or requirement.
How can I tell I understand it?
Distinguish requirements, observations and untested scope.
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.