How to Review a Run: Bugs, Screenshots, and Reproduction Steps

A run finishes and hands you a list of findings, each with a screenshot and the steps that produced it. This guide is about turning that into action quickly: what to look at first, how to tell a real bug from noise, and how to get it to whoever fixes it.

Step 1 — Start with the bug list, not the map

The bug list is the "what needs attention" view. Open it first. Each entry is a specific broken interaction — a dead click, a failed submit, an error state, a flow that didn't complete.

[Screenshot: the run's bug list, several findings with severity and page]

Step 2 — Open a finding and read the reproduction

Each finding shows:

• A screenshot of the moment it broke.
• The steps that led there — the sequence of pages and actions, so you can retrace it.
• The context — what Manta was trying to do, what it expected, what happened instead.

Retrace the steps yourself in a browser. This takes a minute and tells you whether it's a real, reproducible bug.

[Screenshot: a single finding expanded — screenshot, step sequence, and context]

Step 3 — Triage each finding

Sort findings into three buckets:

• Real and worth fixing — reproduces, and it matters. Hand it off.
• Real but expected — e.g. a form that correctly rejects bad input, which Manta flagged as a failed interaction. Dismiss it, ideally with a note so it's not re-triaged next run.
• Can't reproduce — retrace it and it works. Note it and move on; if it recurs across runs, it's likely a genuine intermittent issue worth investigating.

Step 4 — Check the navigation map for gaps

Once the bugs are triaged, open the navigation map. Look for flows you expected that aren't there — those are coverage gaps, not bugs, but they tell you what to check manually or pin down with a plain-English test.

[Screenshot: the navigation map with an expected-but-missing flow circled]

Step 5 — Hand it off

For each real bug, the screenshot and reproduction steps are already a usable bug report. Share the finding with whoever owns that area. Automatic sync into issue trackers like Jira and Linear is on the roadmap; for now, the report is copy-ready.

Tips and common mistakes

• Retrace before you file. A minute of checking saves a developer twenty minutes of "can't reproduce".
• Dismiss expected findings with a note, so each run's triage gets faster instead of repeating.
• Watch for findings that weren't there last time. Anything broken in an area a recent change touched is more likely tied to that change.
• Don't ignore "can't reproduce" if it repeats. Intermittent issues that show up run after run are real.

What to try next

• How to Read the Navigation Map.
• How to Generate a Test Suite from a Plain-English Prompt — lock down the flows the review shows matter.
• Automated regression testing — catching what a release broke.

Start a free run and see what it turns up.