We all know the quality of bug reports impacts the quality of software, yet many people don’t use this easy way to create better bug reports.
TL;DR
Bug reporting is a critical function in software teams and it’s time to take a new approach of using screen recording to make bug reports a lot easier to create and interpret.
The humble bug report
Debugging is essential in the life cycle of software, as any developer can attest to. As a career software developer, I dare say most of a developer’s job is debugging. The key to debugging is reproducibility; if the bug can be reproduced consistently, we’re 50% of the way to fixing it.
So, just go ahead and reproduce the issue right? Sounds easy enough, but it’s far from simple; bugs are often encountered by nontechnical users, and since an engineer isn’t around to ask “show me the problem,” the only way for that engineer to see the issue is to reproduce the bug at her end. The instructions provided on how to reproduce that bug is a bug report. As the recipient of numerous bug reports over the years I have this to say — context and detailed steps to reproduce the bug are everything.
Depending on which company we work for, bug reports differ in formats. At the end of the day, all bug reports share a couple elements: a description of the bug with steps to reproducing it and a visual aid to help engineers diagnose the problem.
The problem
A good bug report is something that’s easily interpreted by whomever is fixing the bug. If I can quickly parse a bug report and carry out steps to reproduce it at my end, we’re talking business. But from what I’ve seen, the biggest challenge is writing these reports. Since most of us aren’t language majors, a poorly written report would be even poorly interpreted, which too often devolves into the familiar repetitive back and forth and the need to nag that comes with every single bug.
For a typical software release, tens to hundreds of bug reports are created. And with the amount of communication breakdown that follows every instance of a bug, bug reporting has become an awkward but necessary channel of interaction between developers and users. In larger, more organized companies that deal with complex products and implementation, the minor, day-to-day reports are handed down to entry level engineers as a part of their training process. In smaller companies, bug reports are passed around from engineer to engineer, until it can finally be resolved.
Bug reporting has become the elephant in the room, an awkward product of software development that no one really talks about. It really shouldn’t be this way.
Better bug reports
The way I see it, the answer to better bug reporting is less ambiguity, more visibility and context, so we can focus on what really matters — fixing the bug.
In my experience, the conventional method of screenshots and wall of text can only take us so far, screenshots can’t deal with interactive elements. Screen recording can amp up bug reports like nothing else, by recording a bug we’re literally showing the engineer how we got to the issue.
Here are more scenarios for why we need screen recording in our bug reporting lives:
1. The bug is dynamic: Bugs happen when we interact with the product. It’s important to capture what we did that resulted in the bug. We need to show what we clicked so the engineer can see exactly what sequence of actions triggered the bug.
2. The bug is intricate to set up: some bugs require a magical configuration to trigger. Use the screen recording to show how to set up the environment, parameters, etc.
3. The bug requires a lot of context: every bug has a story. There are scenarios that trigger a bug, slightly different scenarios that don’t trigger the bug, etc. it’s important to communicate all of the circumstances surrounding the bug, so the engineer can get a complete picture.
Screen recording + narration = even more amazing
Once we add narration with screen recording, now we’re presenting the bug as if we’re right there. When we speak, we give ourselves more room to be expressive so we can fully explain what we’re trying to get across.
Why aren’t we using something like this already?
Effective debugging really comes down to providing enough context so the bug could be reproduced in the first place. Screen recording and narrating is the answer for an effective bug report. The big question now is why isn’t something like this widely adopted already? It comes down to these 2 things:
- Too much friction in creating a screen recording. See if this sounds familiar: 1) we need to setup some kind of screen capture software- in this case Quicktime. 2) Actually capture the bug on the screen. 3) Then we have to save it- do we export as .mp4 or .gif? 4) Find the screen recording file and upload it somewhere it to a platform where it’s visible, but not too public.
- It’s hard to adopt a new habit. Because screen recordings are such a hassle to create and share, people don’t like to depend on it regularly. It feels far simpler and straightforward to paste some screenshots and write about it.
Let’s make screen recordings simpler than screenshots
The idea is to remove as much of the friction as possible to making screen recordings. Outklip makes it a breeze to not just create the screen recording, but we streamlined the the sharing process as well, so our users can create, upload, and share all in one place. It’s the answer to our bug reporting woes.
Cover image: Steampunk Clockwork Spider Brass and Copper Wire Sculpture made by Daniel Proulx A.K.A : CatherinetteRings, Steampunk jewelry designer and sculptor. This file is licensed under the Creative Commons Attribution 2.0 Generic license.
