Write a reproducible bug report
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
The six-seat failure is now evidence, but "the app is broken" would leave a teammate unsure where to begin. A report should specify the version, starting state, exact actions and the difference between expected and actual results. You will use the supplied simulator so the report remains complete even if you cannot access a real product.
A useful report lets another person recreate the observation without guessing.
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
Give the report a factual title: "v1 rejects allowed six-seat request." Avoid guessing that a database, browser or particular developer caused the error.
- 2
State the environment and precondition: paper simulator v1; fresh form; no previous selection. Name the session used so someone can repeat the same state.
- 3
Write numbered actions: choose Cedar, enter 6, press Next. Record the actual rejection and expected Review screen containing Cedar and 6. Keep these in separate fields.
- 4
Include frequency from supplied repeats: the failure occurs on all three identical attempts. Record that five seats reaches Review in the same scenario; this nearby comparison narrows the symptom.
- 5
Explain impact: a request explicitly permitted by the contract cannot proceed. Attach no personal screenshots or credentials. Save a minimal evidence transcript and leave suspected cause labeled as a hypothesis.
See how it works.
Fictional report: Title: "Room Picker v1 rejects six-seat requests." Environment: paper simulator v1, English. Preconditions: fresh form. Steps: select Cedar; enter 6; press Next. Expected: Review shows Cedar and six seats. Actual: form displays "Choose fewer seats." Frequency: 3/3 supplied repeats. Comparison: entering 5 reaches Review. Impact: users cannot request the maximum permitted group size. Evidence: recorded inputs and messages from the supplied simulation. Hypothesis: the upper comparison may exclude equality. The hypothesis helps direct investigation, but the report remains valid even if the eventual cause is somewhere else.
Did you cover these?
- Version and starting state are present.
- Expected and actual results are separate.
- Impact and observed frequency are specific.
What to finish
One complete bug report with minimal reproduction and evidence.
Watch for this
Mixing guesses about the cause into the actual-result field.
How can I tell I understand it?
Another reader can reproduce the scenario using only the report.
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 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.