How It All Started

Welcome to the BugReplay blog! We thought our first post should be a short intro to our company. So here it is!

I’ve been a developer for over a decade primarily on web applications. As a web developer, I spend lots of time talking and thinking about bugs. Dealing with bugs is frustrating enough when I find them myself, on my own software. However, when they are relayed to me through multiple layers of people, I often find myself asking the other person to clarify the problem multiple times (they see the software from the outside, while I see it from the inside).

Saying “I can’t get on the website” might sound like a great description to the person experiencing it, but for a developer it’s almost entirely useless. What’s worse is having to tell them you can’t reproduce the problem - which is unhelpful, confusing, and maddening (for them)!

One day I was diagnosing an intermittent problem with a site I was working on when I became frustrated about not being able to reproduce what the user seemed to be describing. If I had seen it in real time, it would have been much easier. I figured a screencast along with the network traffic would get me about 90% of the way there. After some research, I discovered it was not only possible but that it could be a one-click extension install and extremely easy to use.

So that’s what inspired me to create BugReplay. We quickly realized that it would be a useful tool not just for non-technical users but for QA and for internal use by any member of the team. To illustrate why BugReplay is an amazing tool, let’s first take a look at the alternatives:

1. Text. A user sends an email that goes something like this “when I did X… Z happened. Isn’t Y supposed to happen? What’s going on? I NEED Y TO HAPPEN NOW”. Then there is a lot of back and forth trying to get more information. Everyone gets frustrated (even if support hides it well in an email).
2. Screenshot. A screenshot is an efficient way to show someone what your screen looked like at a specific moment in time. Sometimes a screenshot is sufficient but quite often is just not enough information.
3. Screencast. A screencast (or screen capture) or GIFs are great ways to show someone what went wrong. The issue is that it offers no insight as to why it went wrong. I personally think they’re the best alternatives of the bunch but they’re still incomplete. Without seeing the network traffic, JavaScript errors, browser data (and other environmental data), a developer has to do a lot of detective work.
4. Screenshot. A screenshot is an efficient way to show someone what your screen looked like at a specific moment in time. Sometimes a screenshot is sufficient but quite often is just not enough information.
5. Screenshot of Console. SquareSpace customer support actually asked me to do this once. I sent them the report I made with BugReplay instead because it was just better and easier. The problem with a screenshot of the console, is that it’s an incomplete story. What was the user doing, where were they clicking, what did the screen look like?

While every alternative definitely serves a purpose, BugReplay makes it easier by combining them all into one, but more importantly, syncs them together to tell a complete story.

The screencast is synced with network traffic and JavaScript Errors. You can take multiple screenshots in one session and edit them. You can use it with your team and of course, you can make as many notes as you want :)

Intrigued? Sign up now for access to our private beta at https://www.bugreplay.com.

We are constantly working on improving BugReplay and adding more features. Hope to see you around!