Bug reports can be simple
Hi, Habr. On the eve of the start of the course “QA Engineer” we invite you to sign up for an open lesson on the topic “How to write a bug report correctly”.
We also bring to your attention the translation of a short useful article.
I was recently asked if I could talk to some of my colleagues about working with bugs. In particular, I was asked if I could explain what a good bug report looks like and what information it might contain. The Halaxy Service team was at gunpoint. I admire the people who work in the support team, it can be hard work and when you have difficult clients or situations you are under a lot of pressure. I worked in this position (in another company), it can be very difficult at times. That being said, the Halaxy Service employees are something special. Their rapport with Halaxy customers surpasses anything I’ve ever seen or heard.
I had 10-15 minutes to speak. It doesn’t take much time to really dig into it, especially since the people I spoke to weren’t testing specialists. My goal was to convey some key points in understandable terms that could be learned and used. I decided that the discussion of the difference between fault, error and failure does not fit into this discussion. Likewise, there was no time to cover heuristics as a concept, but I briefly talked about the importance of consistency. What we wanted to achieve was that people on the support team could write bug reports that were detailed enough to clearly define the context and facilitate further investigation and problem resolution for other development participants (including all team members, not just developers).
I formed the structure on 3 key points when filing a bug based on customer interaction. Three simple questions to rely on when creating bug reports. What happened? How did this happen? What should have happened? Let’s take a look at each of them in turn.
What happened – in other words, what went wrong? Something happened that our client did not want. This is the right moment to find out if the client has ever encountered this “misfire” before or if this was the first time. At this point, we know that something that is perceived as undesirable has reflected on the user, and we have an idea of what it is, but this is not enough. As with a car crash, we could just say “the car hit a tree.” The problem with this approach is the lack of information about how it happened to prevent future incidents.
How it happened – at this stage of the bug report generation process, we want to get an idea of what happened when the results went in an undesirable direction. Browser information (especially if it’s an old browser) will be helpful. We could ask how they interacted with the software, with specific data, or anything else that they can remember of what they have done up to this point. There is a lot of information here that may be relevant depending on the context of the problem. The “how” is information that will help us see the “what.”
What had to happen – it is useful to know not only what the problem is, but also why our client thinks it is a problem. This serves several purposes. First, it gives us an idea of what our customers want. It could be as simple as “I wish it would work the way it did when I did the same thing two days ago.” It can also be a discussion from the category “I want” X “, but I get” Y “”. In both examples, regardless of whether the customer feedback is based on an unintended change in the result or on an assumed one (our client is mistaken or the client’s documentation is ambiguous), we understand how our client sees this part of our system. This is important both for research and problem solving and to help manage customer expectations if we later need to explain why the distinction between “desired and actual” reflects how functionality should be performed at the business level.
After a little reflection after my short presentation, it occurred to me that I could include a fourth point – What are the consequences? This is useful information that helps us determine how quickly we want to solve this problem and how we can handle it. I know that when something serious comes through our support team, it gets reported very quickly, and the development team (again, including testers) is centered around the problem and potential solutions. However, it is useful to capture business reflection as part of the error details, whether the impact is large, minor, or somewhere in between.
That’s all. No complicated technical terms, no diving into a glossary or insisting on specific terms, but hopefully keeping the information up to date and useful at the expense of simplicity. Not enough time has passed since the event to assess whether my efforts helped people, or how I could improve this educational program. However, I thought it was a good story about keeping communication simple and worth sharing. This is my simple story.
Learn more about the course “QA Engineer”
Sign up for an open lesson on the topic “How to write a bug report correctly”.