How To Serve Bugs Properly
By: Olga Kouzina
Tags: Software Development, Friday Fun, Bugs, QA, Documentation

Image credit: pexels

If you’ve been to Asian countries, or to Chinese quarters in a large city, you probably know that they eat bugs in Asia. Well, they also eat snakes, caterpillars, ants, worms and what not, but for the sake of my today’s discourse I’ll focus on bugs. Cooking and serving bugs properly is a high art. If something in the cooking process is messed up, bugs will not taste as a deli, but as something mmm… extremely un-delicious. I don’t think I will ever want to eat any of those many-legged sources of protein, unless under very compelling circumstances. However, there are folks who have to deal with bugs every day. In the office. At work. You guessed it right. Today I will provide a few suggestions on how bugs should be “cooked and served” for QA engineers, or for anyone else in your team who wants “to digest” them and to get rid of them as efficiently as they can.

I borrowed these tips from the QA team with which I worked once in my capacity as a publishing editor of a product blog release notes. These release notes included a short summary of fixed bugs, and at times it was quite a pain for our blog publishing team to understand what those bugs were about from their names. For the release notes, we wanted the bugs to have concise names, because our customers had to know what was actually fixed. Likewise, the developers would experience the same kind of trouble, as they struggled to retrieve the nuggets of meaning from a lousy bug report in their daily assignments. Or, the support team would want to check quickly if a bug they’re reporting is a known one, or not, and were unable to do that because of the confusing bug names and descriptions.

Why do we need informative bug reports?

a) We waste no time asking myriad questions to figure out what a bug description implies. Yes, people are supposed to talk when they work in teams. However, when a team gets bigger, approaching someone to talk might not be as simple as in a pizza-sized team.

b) We can quickly refresh in our memory what exactly has been done about that bug.

c) We are able to follow the thinking behind a bug fix solution, and we stay informed of any possible trade-offs, if any, and why they have been made. At times, the steps to reproduce a bug, or a bug fix might seem weird, unless one knows from which pantry this bug comes from, so to speak.

d) To stay in the loop of what’s going on around and make mental notes of the bugs processed by other teams.

Now, can anyone, except the person who wrote this, figure what the following is supposed to mean: “This thing is not working correctly” ??? To make some sense of it, one has to check tons of info searching for a clue of what “working correctly” implies for “this thing”.

On top of that, if this bug lacks a screenshot and a clear how-should-it-work summary, the person who posted it looks like a perfect nominee for the “Bug Chef Dunce” award.

Which bug is a well-served bug?

We will call bugs well-served if all of the following is true:

1. Their Name is a concise, well-written sentence that renders the problem. Not that this bug just exists, not where it exists, but the problem that it causes to users.

Compare: “Quick Add for users is not working correctly” and “Quick Add many users: only the first user from the batch is assigned to selected Projects”.

2. A good bug Summary should allow a developer to understand in as little time as possible which behavior should be reproduced and the steps to reproduce it.

Bugs with a summary such as this one: “When I see “remove” button, I see performance degradation” get straight to hell along with the “wordsmiths” who write them. One might want to use the “What? Where? When?” technique to write a bug summary. What goes wrong, where this wrong behavior is observed, and when, for which actions.

3. Actual behavior vs. Expected behavior. A few sentences or screenshots describing these are the best friends of productivity for a fix. They simply leave no chance for your bug report to be misunderstood and fixed improperly.

I hope this quick tips will help QAs, developers and tech support teams ensure that their bugs are served properly and are ready to be digested by the stomachs of whichever omnivores who are supposed to process them.

🙂

Related:

Why I Love QAs

Quantify or Wordify?

Why Is It Right to Write?