Bug reporting isn’t’ just about logging issues-it’s about clear and effective communication.
What’s the most common response you have received after reporting a bug?
What’s your approach to making a bug report effective? Any unique techniques that work for you?
screenToGif
I create a gif/video of the issue with the full steps and I’ve never had a “cannot reproduce” because they can literally see that it’s happening on my screen.
Openness is ultimately the key. Devs know what we’re testing, they have visibility of our test cases so there are “few” surprises. We’re also open that we’ll be exploring which they can’t really prep for, but they can certainly learn from. So its very rare for us to get negative responses as the culture is very collaborative. Where we can bump into conflict is where something is missed from the story or a lack of understanding of the architecture - the natural reaction being “Why didn’t I know that?”. So I think in the relationships of the lifecycle, probably more work needs to be with engineering and product rather than test and dev.
When it comes to our approach to bug reporting, there are a few standard things we do:
With that process, there is (hopefully) more asynchronous activity to resolve the bug rather than waiting for each bit.
As @ghawkes said, it won’t be a battle in a collaborative environment.
My take on your title would be Bug Reporting: Battle or a Menace?
When does it become a menace?
When does it become a battle?
I think most word I received was Rejected. However after I did I got the info of why it was rejected. Then I understand what the Requirement actually means.
Hi Andres, if you often hear the word rejected and then realize what the requirements really mean, then the reports are not the battle but the requirements.
I think that we as QA people should also try to get in touch with the requirment writers and talk about possible improvements on this side.
You right. It is something that I still trying to figure out. In my current branch (Automotive), to have requirements that are ambigous and not clear is quite normal. Also it is quite normal to live with that, as I dont know why, but change a Requirement once it has been aproved by developers/client/leaders… is dificult. I think this is because when redacting a requirement a lot of people is involved and to actually change something you must anoy a lot of people, so you as a tester just leave with that and have that in mind when testing that specific requirement.
In a similar way I have been in the latest weeks testing webs as a practice in the platform Utest. I had two rejections because Working as expected or out of scope. Of course that one is easy as there is no Requirement at all, or tester do not have access to them, any missbehaviour can be interpreted as working as expected. I mean, at the end your requirement when testing webs without Requirements is common sense which is something quite subjective indeed.
It looks like the problem in your environment lies in the processes.
It sounds to me like you have a fairly static development process that has difficulty dealing with changes.
You could ask whether this is really still up to date. You’ve probably got used to it. But I wouldn’t call it “normal”.
You can be right. My company developes products (air compressors) for already more than 3 decades but the development of software that controls that compressor we started like just few years ago. So I guess some ways to do stuff are still oldfashion. In the first companny that I worked testing infotaiment system was a little diferent. A lot of requirements were still not clear but we also had several additional documents clarifiying specific requirements and ways to test resulting from meetings with person in charge of those Requirements in each case.
An effective bug report is one that can help developers to understand easily what the issue is and what needs to be fixed.
If developers have to communicate repeatedly for clarity of a bug report, that means we need to change the way we report.
While reporting the bug, we can ensure that we add all the relevant data, logs, IDs, and clear STR, along with screenshots/screen recordings.
The most common response I receive from developers this is not a bug this is feature. 
In the case of reporting defects, I would say the most common response is 
and disappointment that they have not spotted it before sending it to me
That’s a solid approach; visual proof really does not cut down and saves everyone time.
Thanks for sharing this, that early slack heads up-before even raising the bug is such a smart move, keeping things transparent and avoids surprises when team is mid-task especially.
Also, totally agree with the 80/20 rule, giving just enough context without overloading, while still ensuring reproducibility, makes a big difference.
How do you handle prioritization when multiple bugs are flagged in slack at once? do you have a quick method in place?
This is such a sharp breakdown, liked you reframed it as Battle or Menace?, the point that devs needing to actively participate and not just follow specs blindly is so true. Building something together for the end user really is the goal and it’s easy to forget that in the rush to deliver.
A simple convo could really save so much back and forth!
Thanks for adding your perspective!
haha totally get what you mean. Sometimes it takes that rejection to actually understand what the requirement was really asking for.
Thats a great point, it really highlights the importance of that early connection with requirement writers. If we are part of the conversation early on, bug reporting turn into opportunities to refine-not fight.
Really appreciate how openly you shared this, the balance between vague requirement and real world testing is tricky.
If we are getting follow-up questions on every report, that’s a sign we are not given the full picture, and yes, “it’s not a bug, it’s a feature” has become the classic comeback at this point-still make me pause every time, totally agree!
haha the face moment is real-especially when it’s something pretty visible and we end up being the ones to call it out.
My bug reporting has changed over the years, in part because of the company and team structures I’ve been part of, and in part because my role has changed and I’ve matured.
I now focus on trying to reduce bugs, and I try to do my most effective testing before code gets merged to main. This means I tend to be giving feedback early enough, often in direct collaboration (pair testing) with the developer, so no bug is necessary at all.
If a bug if necessary, maybe because of when we found it in our process, or because we agree to fix it later rather then imediatally, then I try and ensure it isn’t a surprise. e.g my team will know the bug is incoming via some kind of conversation, live or via Slack.
As far as effective communication, the more I can do to illustrate the expected behaviour, and dig into why the unexpected behaviour is happening, on a technical level, the better. If possible, I won’t just include logs or a screenshot, but I might work on my own or paired with a Dev to do some debugging together. This might be before I rise the bug, or we might pick up the bug together.
In some cases where the fix is obvious and within my skill to fix, I might raise a bug, and a PR, and simply get the team to review it. I appreciate this isn’t an approach that will work for everyone.