How not to make bugs. Common mistakes

Hello everyone. My name is Daria and I am a specialist in quality control of software products of the Renaissance Insurance company, or, in other words, a tester. Renaissance Insurance is not my first job as a tester. I will talk about how not to do it, that is, in detail, with examples, I will write down the most common mistakes when making a bug.

First, I’ll describe two examples of real-life bugs that horrified me, and then I’ll move on to tips on how not to do it. All the examples that I cite in the article are taken by me from previous places.

So the first bug is “I go into this system and click disable”


It so happens that for us, testers, it seems obvious and simple – it is not so for other employees, because they simultaneously work with different systems. Due to the unsatisfactory quality of the bug, they will have to spend time clarifying what is in question (which product, which environment, which system, etc.).

  • “When encoding UTF 8, Russian words are carried by krakozyabrami”

cute kkrakozyabra
cute kkrakozyabra

The only thing that I want to say after reading is that krakozyabra may well be cute :). Yes, at present, IT specialists understand what the author of this bug wanted to say. But here the question of attitude to colleagues and work already arises. Is it really impossible to spend a little more time and instead of “familiar” expressions, technically correctly describe the problem?

The most bitter and saddest thing is the subsequent communications on such bugs with a face blushing with shame. Even worse is to blush in front of developers and analysts for a bug that you inherited from a retired tester. Explaining that this is not my thing – “they forced me” is the last thing, often no one cares at all, but at the same time, each colleague for such bugs predetermines the level of “would-be testers”. Such cases are very common and, unfortunately, entail a lot of unpleasant consequences, namely:

  • undermining the reputation of a particular tester and all testers in the company;

  • underestimation of the significance of the testing process;

  • discussions about the fact that testers are an unnecessary link in the process (like their goal is to find and file bugs, but they cannot do this even humanly);

  • the emergence of conversations that testing is nowhere easier – the unfortunate tester was able, which means that the monkey can.

In no case do I want to offend or intimidate people who are just about to plunge into testing. For me personally, testing is an insanely interesting and complex world, in which there is no place for freebies and performing tasks for “anyhow”. Therefore, I really want the tester to keep track of the level of work being done. And as for the establishment of bugs in general, he was treated as a “holy of holies”.

Therefore, I decided to write a memo: “How not to create bugs. Or common mistakes “:

1. Work at speed

Speed ​​is good in sports, but quality is worth paying attention to in testing. Imagine the following situation: one tester started 50 bugs, but 30 of them need communication and clarifications, and 15 can be closed altogether, because these are not bugs at all, but features or features that can be changed in the browser settings. Another tester brought up 15 informative bugs that can be immediately taken into work without deviations and clarifications. Which side will the “victory” be on? I think the answer is obvious?

2. Lack of specifics

In addition to the first point: the bug must be understandable to the developer so that he does not have to write to you and ask additional questions.

3. Using slang when formulating a bug

As already mentioned in the example about “crocozyabra”: if there is not enough technical literacy, Google will help you. Otherwise, in the eyes of your colleagues, you will personify the little boy from the picture: funny and ridiculous.

4. Neglecting examples and screenshots

This broad gesture will not be superfluous and will save a lot of time to close the task as soon as possible.

PS Do not be confused: the screen is a necessary and useful addition, but not a complete description of the bug. The screen should not replace the description.

5. Timely transfer of the bug to the developer

It is much nicer for the developers to see the up-to-date and clearly described version of the bug. This will save you unnecessary waste.

6. Updating acceptance criteria

The conditions of the game can change directly during testing. And often more than once. Discussions can take place not only in general meetings with all colleagues. There are also official and unofficial correspondence, phone discussions, comments in the problem in the bug tracker and in various messengers. And here the employees want to quickly reach the truth, and often no one duplicates the task in real time and does not update the acceptance criteria.

Before closing any task (a bug you have introduced or a test task for a new functionality), it would be great to spend a little time and, while everything is fresh in your memory, collect “extreme” information from all sources (documentation, communications with colleagues, chats, telephony) and set out in the acceptance criteria.

Yes, I would like to say that such work is the analyst’s area of ​​responsibility, but based on my experience, I can say that for good reasons or due to inattention, analysts will rarely return to a closed task.

After all, a tester after some time, having successfully forgotten the tested functionality, may face a task that will entail a regression. And here the tester, instead of wasting time on figuring out where the relevant information is and who to trust, will be able to immediately proceed directly to his duties.

7. The establishment of “pseudo bugs”

By “pseudo bugs” I mean the features of the test environment or options that can be disabled in the browser settings.

From trivial examples – when entering the authorization page, the login and password are offered automatically. This will be removed by clearing the cookies. Another example is cross-browser compatibility. In one browser, the picture is clear and displayed perfectly on the screen, in the other browser, the fields bump into each other. Perhaps it’s the scale? Before you panic, you should first make sure that setting the same scale in both browsers will not fix the problem.

8. Changing the expected result

There are times when the tester did not have enough information to fully understand the process (absence or presence of insufficient / weak analysis). And a situation may arise that after some time after the bug it turns out that the expected result that you indicated is incorrect. It should be different. And here the most interesting thing begins: the tester, in order to cover up the traces of the “crime”, deletes the description of the expected result, or (even worse) begins to argue with the developer, which was meant to be different.

Making a mistake is a normal working situation. Do not be afraid to recognize and correct it: either close the task with the appropriate notes and create a new one with up-to-date information, or, in agreement with the team, change the description in the current task.

Another life situation is the establishment of a bug without the expected result. In this case, you have to blame yourself and realize that the developer will correct it as he understands from the description. And it is far from the fact that the revision will be exactly what you expected. And it would be unprofessional to reject a solved problem with a claim that you expected “something else”. Therefore, all your expectations and wishes must be indicated in the acceptance criteria.

9. Inability to distinguish front from back

One of the important criteria when filing a bug is the ability to distinguish which part of the service the bug belongs to – front-end or back-end.

Example: field validation does not work. The bug was duplicated and came to both front-line and back-end teams. Both teams spend time and resources fixing the bug.

If a tester cannot determine on his own, it is better to ask for help from colleagues: other testers, team lead, developers. The answer is sure to be found, resources will be spent less, bugs will not be duplicated, clogging up the bug tracking system. Everyone is happy.

10. Working with logs

A tester must be able to work with logs in order to determine and understand what kind of error occurred, where exactly it is reproduced (in which system, at which transition). Whether the bug is related to the system under test or is caused by other external systems. When creating a bug, you should attach links to the logs in order to reduce the time savings.

it also happens
it also happens

The work of a tester is directly and inherently related to bugs: we detect them, put them into bug tracking systems, and control their elimination. Therefore, it is very important to start them correctly, because without them nowhere. Bugs are a vital organ in the process of the system. Try to wind them up more carefully, then everyone will be better.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *