How to Report Bugs so that Developers Won’t Hate you – 7 tips for Quality Assurance Professionals

Nobody likes having their mistakes pointed out, but let’s face it – this is what we do as Quality Assurance specialists aka testers.

Developers often treat their code and their apps very personally, similarly to how musicians treat their riffs or painters their paintings.

This is fine, since the community emphasizes the Clean Code approach and believes in Software Craftsmanship, which is great because the team and its apps can both improve. However, the side effect is, as mentioned earlier, a strong affection for their own products.

So, how can Quality Assurance Professionals deal with developers, when we need to report another bug, and how can we avoid possible conflicts?

1. Always be sure it is a bug

I know, I know… that pleasant feeling when finally, after several hours of an exploratory session and testing another task, we find our holy grail: we feel needed, completed, important. But let’s hold our horses and ensure we have really found a bug.

Nobody likes situations when there is one guy who claims that we did something wrong but, in fact, we didn’t and now we need to waste time to prove ourselves right and show that nothing bad happened.

We do not want to be that guy and we especially do not want to change permanently into this person. In order to be sure, always try to reproduce the bug you’ve just found. Maybe it was just a single action? Maybe your web browser or OS wanted to show who is in charge here and caused this bug just once? Check other devices, operating systems, web browsers… anything that will help you be absolutely sure that the thing you have encountered is a bug.

2. Don’t a bad guy here

Sometimes we are so excited we’ve found a bug that we forget to check if we did everything properly.

OMG – I can’t log in! Of course not, the password was too short. Hey, hey, look, location sharing is not working! You bet it isn’t, you didn’t allow the app to use your location! Hey, hey, I reported this bug one week ago and it’s still here!

Yes, it is, you downloaded the old version. Make sure you avoid such situations.

3. Be specific

Be specific. When you tell a developer “Hey buddy, it ain’t not working” it will not make you two BFF (Best Friends Forever). Don’t be the parent who calls and says “Hey sweetheart, I can’t attach a photo to my E-mail, I think my computer is broken, do something”. Be specific. Tell them exactly what and where it happened.

Imagine it’s an accident and you call an ambulance – the more information you give, the better help your buddy will get. Report the environment, OS version, web browser, build version and type of device – these are essentials. Give it a unique and clever title, so that even a stranger can simply recognize what is going on (but keep it short and sweet).

4. Be a navigator

Once you know how to reproduce a bug, don’t hide it. It’s not highly secret knowledge. Tell the developers how to find your bug and, if there are more paths to reach it, include every single one of them – you never know where they are going to find a solution. Be their navigator.

Another important thing is to mention preconditions that have to be met in order to find a bug. If you should be logged in, then to which account – premium, standard, or something else? If you found a bug in a searching module, did you have your search filtered or not etc. This is all highly important information.

5. Show it

This is what I like most. I’m not a Shakespeare type, I always have the impression that my descriptions might be too poor or (more often) too complex. I don’t want a developer reading my statements to feel like:

Rather than writing something like “green button on the logging in screen to the left from the hamburger menu, above the logo” I prefer to attach a screenshot with a huge red arrow saying HERE and a short message.

If I find a bug that has a complex path, I prefer to record it step by step, rather than write down 16 points with directions.

Usually, I use both methods just to ensure that my explanation is clear, so that no one will be forced to visit me at my desk and ask what the heck did I actually have in mind when reporting this bug.

6. Explain how it should be fixed

Fine, once we’ve checked and ensured – twice – that we have found and described a bug, it would be a nice to tell (if we have this knowledge, of course) how it should be corrected.

If you report that there is the wrong background color on the settings screen, don’t make a developer look for the proper one in the specifications sent by the client three months ago. They will be able to fix bugs faster if you give them all useful information. 

7. Be gentle

As I mentioned at the beginning – nobody likes having their mistakes pointed out, so you need to avoid being unnecessarily critical (or critical at all).

Remember, we are not censors, we are not judges or teachers and we do not assess – we ensure quality.

Developing an application is a complex process that requires a lot of focus and planning. It is impossible to avoid crashes, mistakes (sometimes petty, sometimes stupid) and bugs. Do not report bugs with this conceited manner and avoid expressions such as “again”, “of course” or “no surprise” when you tell people that something is not working as it should.

The most essential thing is to remember that you are a team, a band, you have the same goal – this is the clue. There is no space for looking down on anyone in your team, the sooner you realise it the more fun you will have working together.

Wrap up

I believe fulfilling all these steps will help you be a better Quality Assurance Professional. These rules of being specific, gentle, short and sweet will improve the work of all people in your team, allowing you all to produce better software and applications.

Remember that you and your team or company are as good as your last product and, since we are an important part of SDLC (Systems Development Life Cycle), be sure to also make it a useful one.

Related posts