Turn my testing notes into an engineering-ready bug report. Preserve facts, mark uncertainty, and do not invent reproduction steps, logs, or root causes. Product and feature: [PRODUCT AND FEATURE] Environment and account state: [ENVIRONMENT] Observed behavior and evidence: [OBSERVED BEHAVIOR] Expected behavior and source of expectation: [EXPECTED BEHAVIOR] Reproduction attempt and frequency: [REPRODUCTION DETAILS] Impact and known scope: [IMPACT AND SCOPE] Ask up to 3 clarifying questions only if a required input is missing. Then produce one bug report in this format: Title: specific symptom, condition, and affected area; no proposed fix. Summary: 2–3 sentences describing the user-visible failure and why it matters. Environment: device, OS, browser or app version, build, account permissions, locale, network, and feature flags only when supplied. Preconditions and test data: list exact states needed to reproduce. Steps to reproduce: numbered, minimal, deterministic, and one action per step. Actual result and expected result: separate sections; label inferred expectations and cite the supplied source. Evidence: logs, request IDs, screenshots, timestamps, error text, or video references exactly as supplied. Scope, severity, and priority: state affected users, frequency, workaround, data/security or revenue impact, and why the severity is appropriate. Acceptance checks: 3–5 observable checks, including the original path and one relevant boundary case. Add a “Questions / unknowns” section for missing facts and a “Possible investigation areas” section clearly labeled as hypotheses, not root cause. Before answering, check that another tester could reproduce the issue without guessing and that the title, steps, and actual result describe the same failure.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [PRODUCT AND FEATURE] | Name the product area, user flow, and release or feature involved. | Acme Payroll web app, employee CSV import during the “Map columns” step, release 4.18.2. |
| [ENVIRONMENT] | Provide the supplied device, browser or app version, build, account state, and configuration details. | Chrome 128 on macOS 14.6; staging; admin account; company timezone America/Chicago; feature flag bulk-import-v2 enabled. |
| [OBSERVED BEHAVIOR] | Describe what happened and include exact error text, timestamps, or evidence references. | Clicking Continue after mapping Start Date to start_date returns “Unable to save mapping.” Browser console shows POST /api/imports/812/mapping 500 at 10:14:32 CT. |
| [EXPECTED BEHAVIOR] | State what should happen and where that expectation comes from, such as a requirement or prior behavior. | The import should advance to validation; acceptance criterion IMP-24 says accepted date columns can be mapped and saved. |
| [REPRODUCTION DETAILS] | List the actions tried, required setup, frequency, and whether the issue is repeatable. | Upload employees-25.csv with Start Date formatted MM/DD/YYYY, map all required fields, then click Continue. Reproduced 3 of 3 times; not tested in other browsers. |
| [IMPACT AND SCOPE] | Describe who is affected, business or user impact, workarounds, and known unaffected cases. | Admins cannot finish this import path. They can use the legacy importer after disabling the flag; tested successfully with a file that has no Start Date column. |
How to use
- Paste raw test notes, including exact errors and the source for your expected behavior.
- Verify the generated steps use only actions you actually performed.
- Choose severity based on impact and workaround, then attach the referenced screenshots or logs in your tracker.
- Send this follow-up: “Create a concise Jira version and add a regression-test checklist for these acceptance checks: [ACCEPTANCE CHECKS].”
Variations
Jira bug ticket
Use this when the report must fit a concise issue-tracker format.
Write a concise Jira bug ticket from [TEST NOTES] for [PRODUCT AREA]. Use [SEVERITY POLICY] and [EXPECTED-BEHAVIOR SOURCE]. Include a precise title, environment, preconditions, minimal reproduction steps, actual versus expected result, attachment references, scope, workaround, severity rationale, and acceptance checks. Put uncertain facts under Questions. Do not invent a root cause or logs. Check that every acceptance check is testable and that the report contains enough setup to reproduce.
Production incident
Use this when the failure is live and responders need an initial incident record.
Create an initial production incident report for [INCIDENT] using [TIMELINE AND EVIDENCE], [AFFECTED SERVICES], [USER IMPACT], and [MITIGATION STATUS]. Produce a fact-only summary, detection method, timestamped timeline, scope, current customer impact, mitigations attempted, owner and communication needs, plus hypotheses clearly separated from confirmed facts. Include data-loss, security, and compliance questions if relevant. Do not assign blame or claim root cause. Check that timestamps include timezone and that every claim is traceable to supplied evidence.
Mobile app defect
Use this when device, OS, and app state are central to reproduction.
Write a mobile defect report for [FEATURE] from [DEVICE AND APP DETAILS], [ACCOUNT STATE], [STEPS], [ACTUAL RESULT], and [EXPECTED RESULT]. Include network state, permissions, locale, orientation, app build, and whether the app was fresh-installed or upgraded when supplied. Add a device matrix stating what has and has not been tested, plus observable acceptance checks for the original device and a likely boundary device. Do not infer cross-device impact. Check that the steps distinguish app actions from OS-level actions.
Tips
- A good title names the symptom and condition, such as “CSV mapping fails when Start Date is included,” rather than “Import broken.”
- Record the exact build, account permissions, feature flags, timezone, and test data because each can change the reproduction path.
- Separate severity from priority: severity describes impact, while priority reflects scheduling and business context.
- Do not call a suspected code path the root cause until it has been confirmed through investigation.
FAQ
Should a bug report include a proposed fix?
Usually keep the report focused on the failure and acceptance checks. A suspected cause can be recorded as a hypothesis without steering triage toward an unverified fix.
What if I cannot reproduce the issue?
Report the observed evidence, frequency, environment, and unknowns honestly. Do not create precise steps from guesswork.
How do I choose severity?
Use user impact, scope, data or security risk, revenue impact, and workaround availability. Follow your team’s severity policy where one exists.