Bug Report Follow-Up Questions: Copyable Templates

Read the original report before sending a checklist. If someone already provided a recording, inspect it before asking them to repeat the same work. Summarize the failed task in their language. 'The filtered download contains no rows' is more useful than asking whether an internal service timed out; the latter asks the reporter to confirm an untested diagnosis.

Choose one or two questions based on the gap. When the sequence is unclear, ask what happened immediately before the failure. When the behavior differs between setups, ask for the relevant version, device, or role. When impact is unclear, ask which task is blocked and whether any safe workaround succeeds. Save unrelated questions until they become necessary.

Ask about the last observed attempt before requesting another. Do not ask someone to repeat a destructive action, submit another payment, or expose real customer data just to improve a report. The investigator should arrange a safe test where appropriate. An unknown detail can remain unknown while the team investigates other evidence.

Replace the brackets and delete unnecessary questions before sending. Say what the answer will help distinguish, without implying that one explanation is already proven. Let the reporter describe the result in plain language; exact error wording is useful when available, but they do not need to identify the failing code.

Give evidence an appropriate destination. A cropped screenshot with sample values may be enough. If private evidence is needed, use the established support route and request only the relevant portion. Keep internal account references in the issue record rather than a public board comment. Never ask for a password or authentication token.

An unsuccessful reproduction attempt describes what happened under the conditions you checked. It does not disprove the reporter's observation. Record the exact steps, test build, setup, and actual result, then compare those conditions with the report. A test on a newer build may not answer what happened on the reported version.

Keep confirmed matches separate from differences and unknowns. Change one relevant condition at a time when practical, noting why it matters. For example, a successful unfiltered download does not test a failure that occurs only with an active date filter. Link each attempt to the original report so another investigator can see what remains untested.

Keep this record in the internal issue system. Assign a next action such as checking a known setup difference or reviewing permitted diagnostics. If the report is deferred, record the reason and a reopening trigger. Avoid marking it fixed merely because a local attempt succeeded or the reporter did not reply.

This fictional exchange concerns an imaginary reporting app. A customer says the CSV is empty and provides a browser version. The investigator exports an unfiltered report successfully. Instead of concluding that export works, they notice that the customer's screenshot shows a date filter. Their attempt did not match the reported conditions.

The follow-up asks whether rows appeared before export and whether the downloaded file contains a header. The customer confirms both. In a sample workspace, the investigator then reproduces a header-only file with the date filter active. This narrows the failing condition; it does not prove a backend cause or establish how many customers are affected.

Update the internal issue with the new sequence and actual result. Preserve the unsuccessful unfiltered attempt as a comparison, label the filter relationship as observed, and leave the cause unconfirmed. The next action is an investigation on the matching test setup, followed by a retest once a candidate fix is available.