Practice Task

Practice: Turn a messy bug report into reproduction steps

Convert a vague user complaint into a bug ticket an engineer can try to reproduce.

Practice typeRealistic client scenario · no cash reward
SubmissionsOpen practice; every contributor can submit their own version
Review outcomePass: +25 Trust Points. Revision or not passed: no points until fixed.
Current statusOpen
Practice boundaryRead the exercise here; submit and revise in the task room

The brief is not the submission area

This page gives the customer scenario, source material, deliverables, review criteria, and suggested format. Formal practice submissions, files, revision notes, and review outcomes belong in the task room so each attempt is auditable.

Exercise brief

Use this page to understand the scenario, assumptions, source material, deliverables, and pass/fail criteria before working.

Task room

Submit the completed result, upload supporting files, send clarification messages, and resubmit a new version if revision is requested.

Reusable practice

There is no participant quota. Multiple contributors can submit, and each version is reviewed against the same criteria.

Review record

Outcomes are pass, revision needed, or not passed. Only a passing version earns Trust Points or case-review eligibility.

Client Scenario

What problem are you solving?

A user report is unclear, but engineering needs environment, steps, expected result, actual result, missing evidence, and follow-up questions before debugging.

System Context

Use these assumptions

Assume the user used Chrome on a task-submission page. You have no backend logs and no screenshots. Work only from the user text and clearly mark assumptions.

Source Material

Base your work only on this material

User report: Yesterday in Chrome, after I submitted a task the page froze. I pressed back and edited the form again, and later I did not know whether it saved. I think it happened twice, but I do not remember the exact time.
Deliverables

What to submit

  • Bug title
  • Environment section
  • Known facts
  • Reproduction-step hypotheses
  • Expected result
  • Actual result
  • Missing evidence
  • Screenshots or logs to request
Review Criteria

What makes a result pass review

  • Separate known facts from assumptions
  • Do not invent details the user did not provide
  • Make reproduction steps specific enough for an engineer to attempt
  • List follow-up questions for the user
Submission Format

Recommended format

  • Submit a standard bug ticket
  • Do not submit fix code