Bastion Helix
Article

The bug report a developer can fix on the first read

Most bug reports start a conversation instead of a fix: which browser, what did you click, can you send the error? Here is what a report needs so the first reply can be “fixed”.

·4 min read·Software development

Why reports bounce

A developer who can't reproduce a bug can't fix it. So a report that says “the save button doesn't work” starts a round of questions: on which page, in which browser, what happened instead, was there an error? Each round costs a day when people are busy. Nearly everything those questions ask for already existed on the reporter's screen at the moment the bug happened, and most of it was gone a minute later.

The eight parts of a report that gets fixed

  1. A specific title. What broke and where: “Save on Invoice settings returns 500 when VAT number is empty” beats “Save broken”.
  2. Steps to reproduce. Numbered, starting from a page address, one action per step. Leave out anything that doesn't matter.
  3. Expected and actual result. One line each. The gap between them is the bug.
  4. Environment. Browser and version, operating system, window size, zoom, language and time zone. Layout and date bugs often depend on the last four.
  5. Errors from the page. The messages from the browser console, including errors the page didn't catch.
  6. Failed and slow requests. The address, method, status code and time of any request that failed. That often names the broken service outright.
  7. Visual evidence. A screenshot with the problem marked, or a short recording when the bug is about something happening over time.
  8. The exact element. When one control misbehaves, which one: its label, and ideally a CSS selector a developer can search for.

A template to copy

Title: [What broke] on [page] when [condition]

Page: https://…
Steps to reproduce:
1.
2.
3.

Expected:
Actual:

Environment: [browser + version], [OS], [window size], [zoom], [language], [time zone]
Errors from the console:
Failed requests (method, address, status, time):
Screenshot or recording: attached
Element (label or selector):

Keep private data out

A report is copied into trackers, chat threads and AI tools. Anything in it travels too. Before sending, check that it contains no passwords, access tokens or session cookies, no customer emails, phone numbers or card numbers, and no request or response bodies that carry personal data. Blur screenshots rather than cropping around the problem: the developer needs the context, not the customer's address.

Collecting it in one click

Gathering eight parts by hand is why people skip them. Bastion Helix Capture is a free Chrome extension that collects them from the page where the bug happens: a screenshot (visible area, a selected area or the full page), the page's errors, failed and slow requests (address, method, status and time, never bodies, headers or cookies), steps written from your clicks, speed numbers, and your browser, system, window, zoom, language and time zone. Point at the broken part and it records the element's selector and draws a box around it. Its instant replay keeps the last 30 seconds of the tab in memory, so you can report a bug after it happens.

Emails, card numbers, phone numbers, long ID numbers, passwords and access tokens are blurred in the screenshot and replaced in the text before anything leaves the page. A “What's sent” view shows exactly what will go. Reports go from your browser straight to Jira Cloud, GitHub Issues or Linear, or to a single HTML file, and never pass through Bastion Helix. Before filing, Capture searches the tracker for the same error and offers to add your report to the existing issue instead of opening a duplicate.

Automatic blur covers screenshots and text. It can't blur a replay video, so watch a replay before you send it.

Questions

What should a bug report include?

A specific title, numbered steps to reproduce, the expected and actual result, the environment, console errors, failed requests, a screenshot or recording, and the exact element involved.

How do I write good steps to reproduce?

Start from a page address, write one action per numbered step, and stop at the step where the result differs from what you expected. Leave out anything that doesn't affect the bug.

Should a bug report include network requests?

Include the address, method, status code and timing of failed or slow requests. Leave out request and response bodies, headers and cookies, which can contain personal data and secrets.

Capture is free on the Chrome Web Store, with every feature on during early access. Add it to Chrome, or read what Capture does and its privacy policy.

Recorded from the live demo on this site: the module’s real code running on sample data. Nothing is edited apart from the title cards.