Bug-reporting tools aren’t new.
Tools like Jam.dev already capture screen recordings and technical context. So the interesting question isn’t “How do we add a recording to a bug report?”
It’s: what still makes a bug hard to reproduce, even when you have that context?
A recording can show what someone clicked. But the issue might depend on their account state, the data they were viewing, timing, or something else that’s hard to recreate. And capturing more information isn’t always the answer either: too much noise makes the useful details harder to find, while collecting sensitive data creates its own problems.
A useful report still needs to make a few things clear:
- Where did it happen?
- What steps led to it?
- What did the person expect to happen?
- What happened instead?
- Can someone else reproduce it?
The tricky part is getting that context without making the person reporting the bug fill out a long form or become a detective.
If you use Jam.dev, Marker.io, or something similar: what still sends you back to Slack to ask for more context? And what information would you not want a tool to capture automatically?
I’m exploring this space while building caes.dev. It’s early, and I don’t have a demo ready yet. The waitlist is at https://caes.dev.
Top comments (8)
The distinction between recorded steps and the state needed to reproduce them is important. A click sequence alone can't recreate account permissions, seeded data, or a timing-dependent failure. I'd want those prerequisites stated explicitly, plus the expected result where the flow goes wrong—not automatically capture credentials or all local storage.
I'm building QA Bug → Regression Test, a Chrome extension that exports recorded browser steps as a Markdown bug report and an editable Playwright draft. It helps with that handoff, but the draft still needs review and safe test data; it doesn't reconstruct backend or account state.
Demo: youtube.com/watch?v=GrtotYTfhbg
For caes.dev, are you considering a small explicit prerequisites section alongside the recording?
Yeah, a click sequence can't tell you about permissions or seeded data, that's a good point. Asking for prerequisites explicitly makes more sense to me than grabbing everything automatically. Still figuring out what's worth asking though. Which prerequisites do people forget most in the reports you see?
I don't have enough real-user reports yet to rank what's forgotten most, but I'd start with three explicit prompts: the user role/permissions, the test data or existing records needed, and the starting state (page, login state, or steps already completed). Environment/build details can help too when the behavior differs between setups. I'd describe these without copying credentials or private customer data.
If you get a chance to try QA Bug → Regression Test on a browser bug, I'd really appreciate your feedback—especially the first thing you need to add or change in the exported report or Playwright draft. That would help me see which context is still missing.
a report should probably say whether the bug happened in a fresh tab or after a long session, and whether a reload fixed it. that's small enough to ask explicitly without collecting the person's whole browser history
That's a good one. Fresh tab vs long session and "did a reload fix it" are easy for the reporter to answer, and it saves digging through their history. Would you want those as quick toggles, or should the tool just detect it?
I'd auto-detect what the tool can see for sure and ask the reporter only about what it can't. The tab age and whether the page was reloaded are easy for the tool to record, so the reporter shouldn't have to remember them. "Did a reload fix it" is different, because the tool only knows about it if the reporter tries it. That one works best as a single optional yes/no/didn't try. Detected values should show on the report so the reporter can correct them if they're wrong.
Thanks, this is really helpful. Detect what it can see, ask only about what it can't, and show the detected values so people can fix them. That makes a lot of sense, and the yes / no / didn't try for the reload is a good detail. I'm writing this down. Appreciate you taking the time!
More context isn’t always better if it just adds noise. I’m curious which details actually help you reproduce a bug, and which ones you end up ignoring.