Flawsnap
Free trial

Bug reporting for QA testing

Testers mark the bug on the page they are testing, and the report arrives with the console, the failed calls and the device, so nobody has to rebuild the scene.

The problem: the bug is clear to the tester, not to the developer

A tester working through a release on staging finds that the discount field accepts a code and then shows the old total. They take a screenshot, paste it into a ticket, type the steps from memory and move on. The developer opens it the next morning, can't reproduce it on their machine, and asks which browser, which account and what the console said. By then the tester is three test cases further on.

The fix is not a longer template. It is capturing what the tester can't easily see at the moment they see the bug: the last console messages, the network calls with their status codes, and the browser, viewport and page URL.

Setting up a project for a test cycle

  1. 1

    Create one project per product under test

    In the portal, create a project for the web app. Add every environment testers use to allowed domains: staging.example.com, *.preview.example.com for branch previews, and localhost:3000 for developers checking their own fix. The port must match for localhost. The widget refuses reports from any origin that isn't listed.

  2. 2

    Install the snippet on staging

    Paste <script src="https://backend.flawsnap.com/widget.js" data-key="pk_…" async></script> into the <head> of your staging build, so console output and API calls from page load are captured. See the HTML install guide or your framework's guide.

  3. 3

    Turn on team sign-in

    Enable Let team members sign in from the widget and app. Testers click Team member? Sign in, approve the site in a portal popup, and every report carries their name. Sign-in is offered on https sites and on localhost.

  4. 4

    Shape the categories

    The form asks Who should look at this? using the project's categories. The defaults are Design, Frontend and Backend. Add the ones your team actually routes on, such as Payments or Search. Reports can only use categories on the list, so the board stays tidy.

  5. 5

    Send every report to the board

    Turn on auto-add to board. Each new report becomes a card in Backlog with the priority the tester chose. The default lists are Backlog, Todo, Bugs, In Progress, QA and Done.

Agree what each priority means before the first report

The form has four priorities: low, medium, high and critical. Testers pick inconsistently unless the team writes down what each one means. A short rule set works better than a long one:

  • Critical: blocks a release or loses data, such as checkout failing or a save that silently does nothing.
  • High: a core flow is wrong but there is a workaround.
  • Medium: a secondary page is broken or a message is wrong.
  • Low: cosmetic, such as spacing or a misaligned icon.

Keep the rules in a project doc and link it from the board, so new testers find it.

Use the QA column to close the loop

When a developer moves a card to QA, the report's status changes to in progress, and when the card reaches Done the report is resolved. The tester retests on staging. If the fix fails, they choose Send back on the card and give a reason. The card returns to In Progress with the Rollback label added automatically, and its activity records the send-back. That history is what a release manager needs when deciding whether a build can ship.

Use the board's filters by label and assignee to give each tester their own queue of cards waiting in QA.

What a good QA report looks like

  • A title that states the wrong result: 'Discount code applied but total unchanged', not 'Checkout bug'.
  • A box around the total and an arrow to the code field, drawn with the annotation tools.
  • Expected and actual in the description, plus the test case ID if you use one.
  • The console and network tabs filled in automatically. A failing POST with a 500 status often answers the question before anyone asks.
  • On Pro, a recording of up to five minutes for bugs that depend on a sequence of clicks. It is a page replay, not a video, and typed values are masked.

Pitfalls

  • Forgetting a new preview domain. If reports stop arriving from a branch build, check the allowed domains first. A wildcard such as *.preview.example.com covers subdomains but not the apex.
  • A strict `Cross-Origin-Opener-Policy`. If your staging app sends same-origin, tester sign-in can't connect. It needs same-origin-allow-popups or unsafe-none.
  • One project for everything. Mixing several products in one project makes categories meaningless. One project per site or app is the intended shape.
  • Recording on Starter. Recordings are a Pro feature. On Starter the report is kept and the recording is dropped.

Questions

Can testers report bugs on localhost?
Yes. Add the host and port, for example localhost:5173, to the project's allowed domains. Team sign-in also works on localhost for development, even though it otherwise needs https.
Do testers need a Flawsnap account?
No, anyone on an allowed domain can send a report. Giving testers accounts and turning on team sign-in is still worth it, because reports then carry the tester's name and they can see the board.
Can a developer read a report without opening the portal?
On Pro, a coding agent such as Claude Code or Cursor can connect over MCP, read the report with its console, network calls and screenshot, and move the card to QA when the fix is done.

Try it on your own site

7-day free trial, then $9 a month for Starter or $19 for Pro, per organization, with unlimited team members.

Start free trial Try the live demo

Related

Updated