Why a simple “it doesn’t work” is not enough?

Why a simple “it doesn’t work” is not enough?

Technology
Michał Potasiak
Michał Potasiak
19.01.2017

Everyone who has ever worked in IT has surely stumbled upon communication issues between programmers and testers, or in other cases. Talking to programmers, you can hear many anecdotes regarding bug reports and feedback they have received. Working as a tester in a drupal agency, I see this issue from the other side, but I understand the developement team. When returning a task from tests, I often find myself wanting to write just: “It doesn’t work!”. However, situations in which nothing actually works are pretty rare. You should believe that if a programmer has decided to push his code to testing, they are certain that it works for them and they checked at least some of the basic paths in their environment. This is why we should try and give the developer the most information possible about the error or bug that we managed to find.


“It doesn’t work!”

A report or ticket that does not contain enough information is useless because it does not allow for the bug to be recreated by the developer and thus it does not enable them to quickly solve the problem. In general, I would recommend observing the principle that it is better to write too much than not enough. Of course, it is also important to have some moderation and avoid going overboard. Below I am going to present several things that are worth including in a bug report.


Title 

A short but precise description of the nature of the error, e.g. wrong validation in the contact form.


ID

A number or a series of characters allowing everyone to unambiguously refer to a given ticket. Nowadays, thanks to the use of bug trackers we often do not have to worry about this, because it is generated automatically for each task and ticket.


Name 

Providing the name and the details of the person who found the bug allows everyone to discuss and clear any doubts regarding the report (hopefully there won’t be many of them).


Code version 

An indication of the version of the code on which the task was tested. Depending on company policy it might be for example a name of a given version of the program, name of the branch or test date. It is important to clearly state which version contains the bug because not every version might have it.


Priority 

In most cases, priority means timeframe in which a given error should be fixed. It is often presented using a scale, such as “critical, high priority, normal priority, and low priority”. You can estimate the priority of a given bug taking several factors into consideration:

  • how quickly should the bug be fixed,
  • to what extent does it impact the functioning of an entire project,
  • how often the bug occurs,
  • does this bug concern a new functionality or something that is already used by your users. 

In this case, the priority of the bug will be the resultant of these factors, presented on a scale, such as critical error, serious error, normal, low priority, suggestion. Of course, we can also assign a separate category to each of those factors and describe them in tickets – this varies from company to company. However, it is crucial to categorize the reported bugs.


Prerequisites 

If there are any actions that had to be undertaken before the test, or if there are any conditions that have to be fulfilled before the recreation of the bug is possible, you should include them in your ticket. For example, the bug appears only if you create a user account and assign them the role of an editor.


Testing environment 

There are situations in which a given bug will only appear on a specific hardware configuration. This is why it is crucial to provide extensive details regarding the hardware the bug was found on, your operating system, your browser, all software that might impact the operation of the program, screen resolution and so on.


Bug description/steps to recreate the bug 

Of course, the short description of a bug in the title will not be enough; you also have to describe the problem in the clearest and precise way possible. You can start with a short introduction explaining the bug; however, the most important thing here is to describe all the steps that led us to find the bug. You should not use descriptions such as “I switched the windows” or “I entered some data”, instead you should describe precisely what you clicked and what data did you enter in the fields because it might be entering certain data that causes the bug. If you are testing a web application, you should provide URLs of sites that led you to find the bug.


Current result 

Everything that happened after completing all the steps that allowed you to find the error should also be reliably described. Keep in mind to avoid writing things like “And then an error window appeared”. Of course, you should include such information in it happened, but do not forget to add what kind of error did it contain. Even if it tells you nothing, it might actually hint the developer at finding the source of the problem.


Expected result

You described the steps that led you to find the bug, you described what you saw and it would seem that nothing else can be added. Indeed, very often this is enough; however, there are situations in which the expectations connected with the problem are not that obvious. This is why you should always remember to clearly state what you expect from a given task. It allows everyone to explain possible differences in the understanding of the system’s operation and clearly shows what needs to be fixed.


“Presentation – better than a thousand words...”

Undoubtedly, one of the best methods of reporting bugs is to show them directly to the developer. Have them sit down in front of your screen and show them step by step how to recreate the bug. As the author of the code, they know what to look for when the bug appears and where to look for additional information regarding what happened. Apart from an error message, they should also able to notice other indicators showing that something is not working as intended. Sure, often we simply do not have the opportunity to show bugs directly, but you can always try to find an attractive alternative, which will make our work easier despite not being a direct presentation. If you know that the bug that you found is not easy to describe and rather complex, try to record your screen during the test. It will certainly help with understanding the problem. If the bug is not very complex, try to at least include a screenshot and mark where the bug occurs. Many people in the world are visual learners and they will understand the bug better when they see it. Thanks to that, even if they do not manage to recreate the error on their machine, they will know how it looked like in your environment.

Tools that support bugs reporting

All of the above elements can be reported in many different ways: verbal, in calculating cradle, e-mail, etc. However, it is also important to track this issue later. Therefore, most companies use software to support this. Below is a short list of solutions that should be considered when choosing such a tool:


Summary

To sum up, I will give you a few basic rules and principles that should be observed when reporting bugs:

  • remember to express yourself in a clear and precise manner, so that the developer can easily recreate the bug,
  • describe all symptoms indicating that something does not work properly, even if you know exactly what the problem is,
  • report bugs as quickly as possible,
  • always try to repeat the bug two or three times, if you do not succeed, mention it in your ticket,
  • if you have the opportunity to show the error directly, do so,
  • never omit facts that seem to be obvious to you in your ticket,
  • if you have the opportunity, check whether the bug occurs only in a given situation or on a given hardware configuration.
     
As part of Drupal support, we maintain existing websites and expand them with new functionalities
Check related blog posts