Write a Bug Report Another Person Can Reproduce

“The system failed” tells a support team that someone needs help, but it does not reveal what to investigate. A useful bug report connects one observable problem to a starting condition, a sequence of actions, and a result. Another person should be able to repeat the attempt or understand what evidence is still missing.

You do not need to diagnose the code. Describe what happened accurately, explain the business impact, and preserve enough context for the team to investigate without asking you to reconstruct everything later.

Separate the observation from the explanation

A report such as “Saving a draft shows an error and leaves the status unchanged” describes behavior. “The database is broken” proposes a cause. Keep hypotheses in a separate note until someone verifies them.

Mozilla's bug-writing guidelines emphasize clear reproduction steps and separate actual and expected results. The same structure is useful for business applications, even when the people reporting problems are not developers.

Report one primary problem per ticket. If a second symptom might be related, link it and explain the connection rather than combining unrelated issues into a long message that cannot be closed cleanly.

Copy this report structure

• Title: the action, affected area, and visible failure.
• Environment: production or test, application version, browser or device, and operating system.
• Time: when the problem occurred, including the time zone.
• Starting conditions: role, relevant record state, and whether the user was online.
• Steps: numbered actions with the exact control names and input needed to repeat them.
• Expected result: the agreed behavior and its requirement or workflow reference when available.
• Actual result: what appeared, what changed, and the exact error text.
• Frequency: how many controlled attempts failed, or that recurrence is currently unknown.
• Impact and workaround: the blocked business action and any verified alternative.
• Evidence: safe record references, a focused screenshot, and an approved log or request reference if available.

Leave unknown fields marked unknown. Inventing a version, affected-user count, or cause makes the report less reliable. Never add passwords, session tokens, payment details, or unnecessary customer information to make it look more complete.

Example: a draft cannot be saved

The following example is fictional and uses a test environment:

Title: Editing a service note prevents saving an existing draft. Environment: Test portal, build TEST-42, desktop browser and operating-system versions attached in the test record. Time: Recorded with zone in the ticket. Starting condition: Operator role, synthetic request DEMO-17, status Draft, online.

1. Open DEMO-17 from My requests.
2. Select Edit note and replace the text with “Gate access confirmed.”
3. Select Save draft once.

Expected: The note is saved, the request stays Draft, and reopening it shows the new text. Actual: “Unable to save” appears; reopening shows the previous text. Frequency: Both of two controlled test attempts failed. Impact: The operator cannot retain the updated note. Workaround: None verified. Evidence: Redacted screenshot and test request reference attached.

This gives the developer a starting point without claiming why saving failed. If the failure cannot be reproduced elsewhere, the environment and record state still provide useful leads.

Capture evidence without creating another problem

Prefer a cropped screenshot of the relevant control and error. Check the address bar, background windows, notifications, and visible record fields before sharing it. Follow the team's approved support channel for any material that requires restricted handling.

Do not repeatedly retry an action that may charge, send, delete, or create records just to improve the report. Record the uncertain outcome and let the responsible team check the destination first. Reproduction involving business effects belongs in a controlled environment.

If you cannot reproduce the issue, report that honestly. Include the last known successful action, approximate occurrence time, and any visible reference. An intermittent problem can still deserve investigation; it simply has a different evidence limit.

Close the report with a focused retest

When a correction is available, repeat the original steps on the identified version. Check the expected saved state after reopening, then test the nearest relevant variation, such as saving without changing the note. Record the result and any remaining issue.

Contact Dynelink to define a reporting and retest workflow that helps your team turn vague software complaints into reproducible, actionable work.