Over the years I have seen an increase in the idea of not reporting defects within Jira, Azure DevOps, Bugzilla etc and having a conversation instead.
If it is an issue within the story itself and an AC failure then I certainly see the merit in skipping the bug report. It can be busy work to write up behaviour, send it to the developer and for them to go “ah sod – I forgot about that” and quickly fix it. However as a counter point, from my time as a developer I did find it easier when things were written down as my memory recall from verbal communication isn’t the best. As a tester, unless the story comes back to test quickly, I want some kind of record.
This post is about more than pointing out that as humans we have different preferences. My concern is when entering a bug that isn’t currently planned to be fixed is considered busy work. This includes bugs found in areas that isn’t related to the current feature, or is quickly reviewed sat together & consider too low priority. I still always want to log a bug here.
Documenting why a bug isn’t worth fixing
I’m sure we’ve all been there where a defect is seen when you’re up against it. It is a real edge case and doesn’t have a significant user impact. The developer realises that it will be in a high risk area of code and a chunk of effort to fix & test it. Quickly it is clear that it isn’t worth doing right now. This is made in the knowledge that not fixing it now means that it probably won’t get done at all. So why enter a bug?
Think about the case where 6 months down the line and someone else sees this for the first time. They raise it with their PO and its agreed as a nice fix to put in. The scope isn’t quite understood so a developer goes away to investigate it. Half a day later they come to the same conclusion as before but aren’t all that confident in their understanding and want to get a second opinion from another team. “Oh that rings a bell. Yeah, real can of worms.”
The 15 minutes saved by skipping writing this down has saved a lot of time here!
What about when the customer reports it?
Very much in the same line of thinking as above, what about when the rather angry customer phones tech support complaining that half the time they try saving to their shared space, they get an error and need to retry.
Tech Support haven’t heard of the issue. It isn’t in the bugs / known issues list available to them. So naturally they investigate. A chunk of time later it comes to Engineering. They try and reproduce it and confirm it is a bug. It is then scoped and fixed by a team.
The team involved in the fix decide that a bug escape review (or whatever your company calls it) should be held. How was this missed?
If only that bug was entered eh? Tech Support may have known already. The team responsible for fixing it would have known who to speak to about it.
Bugs can be useful for learning
I’ve mainly worked with large, complicated software. This means there’s tech debt and a deep history of why some of our more complicated code exists. When it comes to developing a feature that has been around the block a few times, unless you yourself are familiar with it then it can be good to know about the gotchas and challenges. Similarly when identifying the risk and scope of testing, what bugs and challenges have we seen in the past?
A searchable pool of defects that includes changeset notes, a discussion on how to fix an issue or why it isn’t fixable can be pretty handy here! I’ve learnt about some of the nuances of the protocols used by our solution through developer’s bug comments.
I also believe that just knowing about the quantity of bugs in software is important. Zero bug software isn’t saying zero bugs are in the application – give me 30 minutes and I’ll prove otherwise – but that we’re leaving zero bugs in an open state. Just as zero bug development shouldn’t be misinterpreted as developing bug-free software, it shouldn’t be misinterpreted as don’t bother entering bugs!
As engineers we are all responsible for quality but how do we gauge that if we’re not recording bugs. How can we say that we have an understanding of our software’s quality level when there is no visibility of how many bugs we have accepted.
Within the world of cyber security it is known that you can mitigate, accept, transfer or avoid vulnerabilities. The same is true of bugs. Marking a bug as won’t fix is accepting the risk and impact on a customer should they encounter it.
The next time you or someone on your team says “don’t bother entering a bug”, make sure that everyone involved in the decision knows that they are keeping quality issues to themselves and they may be screwing over their colleagues down the line.
ACs passed. Able to place mug on the table. User story moved to done.
