Using GIFs on Bug Reports

If you've been developing software for any length of time you've fixed a bug or two that someone has reported. Whether for a customer or a user within your organization, sometime's words of how something is fixed or how to duplicate an issue may not be enough.

Using screenshots is great to show if something is working, especially if it is something easily to show like a UI element working. However, to show that a series of steps is working with the end showing that the fix is there, I believe GIFs are a great way to include in your bug reports after a fix has been implemented.

But How Do I Make A GIF?

I primarily run a Mac, so I really love how easy Screenflow is for this. Sure it's primarily for screencasting, and I use it for that, too, but it's really easy to make GIFs with this.

Of course, there are free alternatives (before Screenflow I was using Recordit with good results) and they all are good to use in their own right. One thing I really like with Screenflow is that it is really easy to edit after recording your GIF.

Why Does Editing GIFs Matter?

The primary reason why I'd want to edit a GIF is to remove unneeded parts of what I was recording. The same thing you'd do with any video, remove any dead or time consuming parts. If you're recording a GIF to show that something is working after a fix is put in, you may have times where you're waiting for a process to execute in order to show the fix is working. Editing your GIF to remove the time it takes for the process to launch and load will reduce the length of the GIF as well as to make it smaller for uploading or viewing.

Another awesome reason I like using Screenflow for GIFs is that you can use all the advanced screencasting features Screenflow provides for you inside of your GIFs. For instance, I can zoom in on places I want to show in the GIF or highlight specific areas of the screen so the viewer can know what I want them to see.

Let's take a look at an example. I did a very quick recording of some F# using VS Code and running a selection in the FSI. Here's the GIF of that using Screenflow's editing tools.

Not the best edited example, but I hope it helps illustrate some of the things Screenflow can do to make GIFs that much better to include in bug reports.

There are a couple of things of note, though.

• Screenflow allowed me to specifiy what area I wanted to be recorded. I just adjusted the preview window right before recording to the size I needed.
• I did a small zoom to better show the FSI output.
• I did a callout to show to viewers the specific output in FSI of the input I gave it.

I got Screenflow to start doing some screencasting, but since they've introduced GIF support I've been using it much more for caputuring GIFs for projects at work and uploading them to whatever bug tracker we're using (Jira, Visual Studio Team Services, GitHub) and, to me, it's been quite helpful. Often I've recorded a GIF and found something else I needed to work on for that issue before it should have been sent back as fixed.

Watch How Your Users Use Your App

If you develop applications at your company and another group there uses it to do the actual business of the company, have you actually seen how they use the software? Seems a bit crazy, right? You developed it, so of course you know how it works! Not quite so. The people who use your applications all day every day at work will find little nuances about it that you never would have dreamed of. They'll take six clicks to get something done when you thought it only would take two.

You won't really know how they use it until you sit with them and watch them for a few minutes. Requesting this to your boss should show that you care enough about the business to help out the productivity of the users and the quality of the software you give to them. To get an even better idea is to see if you can actually do a little bit of what they do to get the full effect. Then take notes...anything that comes to mind. How do you think this can be improved? What issues were you having to accomplish a certain task? Were there any performance problems that had you waiting for a task to complete? Could something be done simpler to minimize the user (in this case, you) from having to think about what should be done on the page?

I actually propose the whole team to do this. Then once everyone has finished, compare notes and even have a small meeting on all the things that can be improved.

I just did this today and saw massive productivity improvements and you can bet I'll share them with the team as soon as I review my notes.

On Better Developer Testing

I read an interesting post by Phil Haack a little while ago on having developers do better testing themselves instead of relying solely on their QA team to test. While it’s definitely a great read in itself, I felt I had to add my opinion to it.

Don’t get me wrong with this, though. I think the more experience and skill a developer has on testing their own code, the more valuable they actually are. Also, it’ll mean their code is that much more reliable and stable upon initial release all the way through to production. No developer wants to find that their code somehow broke in production the morning after it was deployed and spend that whole day fixing it.

While I definitely agree with Phil on most of his arguments, there was one thought about the whole thing that kept coming to mind about myself, personally, when testing stuff that I’ve written. I know I don’t have the experience to think of a good amount of scenarios the code will be hit at. Now, this may not be an issue for the more experienced developers out there, but I know it’s a weak point of mine. I’ve definitely been bit by not doing more of this in the past and, indeed, it wasn’t fun admitting it was my fault when the manager is asking what happened. In fact, when this happened to me it gave me a very real benefit of using unit tests. Of course, unit tests can’t test everything that a user would do as input or processes on a screen. While Phil notes that Test Driven Design is mainly for the initial design of the code we’re ultimately testing, it definitely helps to make sure any refactorings for readability, maintainability, performance, etc. didn’t break anything we’ve already shown and trust to be correct.