Guide
How to write a bug report with useful screenshots
A useful bug report pairs one observable failure with reproducible steps, expected and actual results, and a checked screenshot. Copy the blank template, then consult the optional completed example.
Copy the blank report template
Record a known starting state and numbered actions. Separate what you expected from what you observed. State the frequency you actually tested rather than calling an issue intermittent without evidence.
Download the blank bug report template# Bug report: [one observable problem]
Environment: [app version, browser version, OS, viewport and zoom]
Preconditions: [demo account state and sample data]
Steps to reproduce:
1. [first action]
2. [second action]
3. [action that triggers the failure]
Expected result: [specific observable outcome]
Actual result: [specific observable difference]
Frequency: [for example, 3 of 3 attempts]
Impact: [which task is blocked]
Attachment: [checked, redacted screenshot filename]
Annotation: [what the highlighted area demonstrates]
Sensitive-data review: [what was removed and export verification]
Start with a completed example
This report describes an intentionally disabled Export button in our example dashboard. It is a training example, not a customer incident or a claim about Captorify reliability.
Download the completed bug report# Bug report example: Export is disabled beside the displayed report
This is an example QA report, not a customer incident.
Environment: Example billing-dashboard image, 1200 x 760 pixels.
Preconditions: Open synthetic-dashboard.png. It is a static training image, not an interactive dashboard.
Steps to reproduce:
1. Read the displayed range, September 1-7.
2. Read the selected report label, Weekly billing summary.
3. Inspect the Export button beside the report.
Expected result in a working product: A report with an allowed date range can be exported.
Actual result: The demonstration intentionally shows a disabled Export button.
Frequency: Deterministic fixture; no production reliability claim.
Impact: Demonstrates how to document a blocked export with enough context.
Attachment: annotated-screenshot.png from the free annotation tool, generated from synthetic-dashboard.png. The qa-disabled-export-handoff.pdf orders that source, its annotation and an image of this completed fictional report as three pages.
Annotation: A red arrow points to the disabled Export control, and the text says “Export remains disabled.” The date range remains visible.
Sensitive-data review: All names, addresses and identifiers are fictional. The annotation is not redaction; replace or cover private fields in a real report.
Keep the trigger and result in view
The completed report starts from the 1200 × 760 fictional dashboard: the September 1-7 range and Weekly billing summary are visible, yet Export is disabled. The annotation-tool PNG points to that control and labels the actual result. The expected result belongs in the report text, because a still image cannot prove an attempted click.
All account details are invented. The annotation PNG does not redact them. For a real report, use a demo account or remove unnecessary identifiers before attaching the file.
Actual annotation-tool PNG with an arrow and label on the fictional dashboard’s disabled Export control. Open the actual annotated PNG
Attach only the evidence the reader needs
Use a full page for a layout problem and a focused region for a small control problem. Add relevant console text separately after reviewing it for credentials.
For a long sequence, use ordered section captures or a PDF. A still image cannot establish timing or every interaction, so describe those steps in words.
Reopen the attachment and confirm the destination
Check text readability and every redacted region in the exported file. Attach it to the intended issue, with a short caption that explains what it proves.
Captorify does not need a bug-tracker integration for this workflow: download the file and attach it to your existing tracker. Use a protected link only when that fits the recipient’s access requirements.