Capturing a 2048 bug with Replayable
How often have you encountered a bug while testing an app you’re building? How often are those bugs completely unrelated? Do you stop what you’re doing and go after them? Or just let them slide and move on?
If you stop what you’re doing to capture it, you need to remember what happened. You then need to launch a screen recorder and hope that you can reproduce the issue. If the reproduction takes multiple steps, you might waste time trying to get the application in a state for it to happen again. It’s extremely frustrating.
You might choose to save troubleshooting for later so that you don’t kill your developer flow. Who wants to stop what they’re doing to write steps to reproduce something unrelated? You know that you need to fix the bug, but it interrupts your current focus and workflow.
Why you shouldn’t interrupt a programmer
As a part of the “shift left” movement, developers now play a larger role in QA and testing. QA is no longer the responsibility of another team. It’s a combination of automation and development. Developers are responsible for finding and documenting bugs, and that competes with their ability (and love) for coding.
Once a bug is found, the developer needs to support it. It needs to be documented, then you need to tell the product team about it, and maybe there’s a meeting (or three). It’s a huge PITA. With the rise of remote work, developers can’t just grab their coworkers and say “hey, take a look at this.” Instead, they say that “it works on my machine.”
Wouldn’t it be great if you could just capture the bug when it happened in the first place? No more meetings, video capture, descriptions, reproducing steps, follow-ups, 
.
Trimming a clip in Replayable
That’s why we’re building Replayable. Replayable is a dashcam for developers that helps you upgrade your bug reports with clips from local development. Rather than taking the time to reproduce and explain, you can simply grab footage of bugs when they happen. It’s like a black box on an airplane. Anyone who reads the bug report won’t need to follow ambiguous instructions, ask follow-up questions, or the dreaded “what version are you on.” It’ll be in the clip.
Replayable helps you show your team what you’re talking about instead of constantly trying to explain and describe the situation. It gives your team all your information – your perspective when shit hits the fan. You get to stay focused and feel peace of mind as you know that when anything goes wrong, you’ve got footage of it – just like a dash cam.
It works just like a dashcam too. Replayable records your screen LOCALLY in the background while you work (and yes, it’s performant). Whenever you encounter a bug, just hit the hotkey or press the “create clip” button and you’ll get a video of whatever happened in the last 30 minutes.
You have a chance to trim, crop, and censor the replay before publishing. Once you publish, you’ll be presented with a quick sharing link for markdown, Jira, etc. In fact, you can even do this all in one line with the CLI. But more on that later.
Embedding a Replayable clip in GitHub
Not quick enough? The Replayable buffer records up to 3 days of footage, so you can upload Friday’s bug during the Tuesday standup. Replayable keeps its replay buffer on disk so your RAM doesn’t fill up, and it records at a low FPS, so things take up less space.
So how does it work? Imagine I’m playing 2048, and a bug pops up. Oh no! I hit the “Create Clip” button and capture it. I trim only to show me encountering the error (and the time leading up to it), then I crop and upload. I can then use the sharing dropdown to embed the replay within GitHub, Jira, or wherever your bugs go. I can go into the console.log and attach the logs to the replay as well.
In fact, you can even do most of this automatically by triggering a capture when the browser hits an error, but more on that later. For more, check out our CLI, Jira integration, and docs. Follow us on Twitter and join our beta!
Top comments (0)