Pet Peeve: Incomplete Bug Tickets

By June 26, 2018For Developers
vicious chihuahua

Here you are again. You’ve made it to the office, and you’re ready to dive into the day’s work. The first thing you always do is check to see if you have any tickets from the previous day.

Much to your surprise, and satisfaction, there is only one ticket in your queue. You’ve done it. You can knock this ticket out super quick and spend the whole day devoted to your actual work. Lucky you.

That lucky feeling quickly evaporates as you read the title of the ticket, “Tax button crashes the app”. Vague, you think to yourself, but maybe not that bad. You open the ticket and your uncertainty turns to horror as you read this:

Description:

Tax button seems to be broken.

Steps to Reproduce:

I had an order with some items on it. When I hit the Tax button, the app crashed.

Oh no, another one. Audible sigh.

When you are a developer and responsible for maintaining your application and fixing issues, this is a never-ending ordeal. Whether it came from your QA department, customer, or Billy who works in sanitation, no one should submit a defect ticket that looks like the one above. How are you supposed to get started with that information?

You know that the person who submitted the ticket had an order with items and hit a button. Obviously, out of curiosity, you will go in and try to replicate the issue on your side. And of course, no dice. You might even go back into their ticket history and see if you can build a personal profile on the individual to decipher what they did to get there.

Then, there’s the last ditch effort.

The option so horrifying, every developer I know is traumatized at the prospect of it. Talking to the person who submitted the ticket. Having to explain to that person that it is impossible for you to fix their issue if they don’t offer more in-depth information. Ideally this would include fifteen, excruciatingly detailed steps to reproduce the issue on a consistent basis. But you’ll take whatever you can get.

When I developed, our QA person (shout out to Jacki – I miss you) was extremely diligent with the tickets she submitted. Very well documented and detailed instructions on how to reproduce an issue. Build version, screen names, items, and steps always present in the tickets. I beamed with glee whenever she submitted bug tickets. Well… maybe not glee, but she knew how to make the bug fixing process easier.

While I certainly had other pet peeves, this one was an ongoing annoyance in my day-to-day life as a developer. It would have been so much easier if the person had taken a few minutes to consider the work that needs to be done to fix their issue, before submitting a ticket. It’s easy to identify a bug in an application. It is much more difficult to understand the steps it took to create it. There could have been something that you did twenty steps before finding the bug that is the actual issue.

From my experience, if you’re responsible for submitting tickets to developers, the best thing you can do is make sure that you take that extra minute of consideration to make your developer’s life easier before hitting the “Submit” button. Whether it is laying out requirements for a new feature or elaborating on potential issues, they will be grateful for your consideration. Otherwise, you can be certain the heavy sigh you hear when they open their computer in the morning can be attributed to you.

More from our sales engineer Josh:

bugs bugs everywhere

There’s Perfectionism, and There’s Programming

Bill Lumbergh from Office Space

Can a Software Project Hurt Your Career?

Business Analyst

Can Your Business Analysts See the Problems With These Data Visualizations?

Leave a Reply