Michaela
Between "QA found a bug" and "a developer starts fixing it" there is a loop. The developer needs something the report does not say, asks, waits, and tries again. Nobody tracks it as a line item, and every team knows it exists.
What the loop looks like
- QA writes a report and files it.
- A developer reads it and finds a missing piece: which account, which request, which browser.
- They ask. The answer arrives later, sometimes the next day.
- They try to reproduce with the new detail.
- Only now does the investigation start.
Steps 2 to 4 exist only because the first report was incomplete. The time they take depends on your team, so measure it: count how many reports get at least one clarifying question. That follow-up rate is the number to watch.
Why the loop forms
- Reporters describe what they saw. Developers need why: the response, the error, the state.
- Context decays. The longer between the report and the investigation, the less anyone remembers.
- Asking is asynchronous. Each question costs hours of calendar time, even when it takes a minute to answer.
How to shorten it
Make the evidence part of every report instead of something the reporter has to remember. Each SnagRelay report carries:
- the element the reporter pointed at, with errors tied to it
- console errors with file and line
- requests with request and response bodies, failed and successful
- repro steps and a short session replay
- browser, OS, viewport and URL
Then the developer, or a coding agent reading it by key over MCP, starts from the evidence. When the fix is done, the reporter is told by email, which removes the last follow-up: "is this fixed?"
What to measure
- Follow-up rate: the share of reports that get a clarifying question.
- Time to first action: from report to a developer or agent opening it.
- Carry-over: bugs filed in a sprint that are still open at its end.
Set your own baseline first. Improvements show up in your numbers, not in anyone else's average.