Task management · Practical guide
Bug Report Template: Reproduction Steps, Severity and Evidence
By My First Task editorial team
Updated
The short answer
How to approach the work
A report title should describe the observed failure, such as 'Checkout button remains disabled after valid address entry.' Separate severity, the impact of the problem, from priority, the order in which the team chooses to address it. Reproducibility can be intermittent; report that honestly and include the conditions you observed. Screenshots and logs help, but remove credentials, personal details and private customer data. One report should describe one coherent problem so its resolution can be tested clearly.
A practical sequence
- Write a title describing the failed behavior and where it occurs.
- Record browser, device, environment and relevant version.
- List prerequisites and numbered reproduction steps.
- Separate expected behavior from actual behavior.
- Describe affected users, frequency and any safe workaround.
- Attach redacted evidence and agree severity, priority and review ownership.
Illustrative scenario · not customer research
Worked example
In a sample staging checkout, the reporter opens a cart, selects delivery and enters a valid address. The expected result is an enabled Continue button; the actual result is that the button remains disabled in the tested browser. The report includes the test environment and a redacted recording. It does not claim every shopper is affected because only one setup was tested. The team checks whether the issue blocks release, then links the investigation and fix work back to the report. Acceptance includes repeating the steps after the change.
Bug report checklist
Adapt this starting point to your own project. Examples describe a planning practice, not an automated app workflow.
| Field | Example or prompt |
|---|---|
| Title | [Action] fails under [condition]. |
| Environment | [Browser/device/version] in [test environment]. |
| Reproduction | 1. [setup] 2. [action] 3. [observe]. |
| Expected / actual | Expected [behavior]; observed [behavior]. |
| Impact | [Affected workflow], [observed frequency], [workaround]. |
| Evidence | [Redacted screenshot/log] and [reviewer]. |
Common mistakes to avoid
- Using 'doesn't work' without expected and actual behavior.
- Declaring a root cause before investigating it.
- Uploading sensitive production data as debugging evidence.
Try the method with your own inputs
Questions answered
What is the difference between severity and priority?
How do I report an intermittent bug?
Should every bug become a task?
Apply it in a shared workspace
Keep the agreed owner, completion criteria and important decisions with the work. Explore the relevant My First Task feature.
Research context is available in our source library. The worked example above is an editorial illustration.
Continue learning
How to Write a Task Description: Template and Examples
A useful task description states the result, why it matters, who owns it and how completion will be checked. Add the inputs, constraints and relevant links so the next person can act without reconstructing the request from chat.
ExploreAcceptance Criteria Examples: A Practical Writing Guide
Acceptance criteria are observable conditions a particular work item must satisfy before it is accepted. Write them around behavior and evidence, including important failure cases. A definition of done sets broader quality expectations across work items.
ExploreHow to Assign Tasks: Ownership, Deadlines and Follow-Up
Assign a task by agreeing the outcome, accountable owner, required inputs, finish condition and realistic timing. Check the person's capacity and authority before treating the assignment as an accepted commitment.
ExploreTurn the plan into shared work
Give each next action an owner, a completion condition and a realistic date. My First Task brings tasks, boards, project workflows and issue tracking into one workspace.