Bug-reporting tools already exist. What still makes bugs hard to reproduce?
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 ha
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.
Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.