|Random Picture from my holiday in Sicily|
In a recent blog by Eric Jacobson’s he argues that reporting trivial bugs tends to waste everybody’s time and that you shouldn’t log them.
I really struggle with this concept so thought I would explain why and maybe see what I learn this year and then reflect on this in a later post.
Why should we not log trivial bugs?
‘If a trivial bug gets logged, often…
- a programmer sees the bug report and fixes it – I personally have no issue with this as trivial bugs can be very visible even they do not threaten the inherent value of the feature immediately.
- a programmer sees the bug report and wonders why the tester is not testing more important things – this I find a silly assertion but maybe it can happen? Has anyone experienced this?
- a team member stumbles upon the bug report and has to spend 4 minutes reading it and understanding it before assigning some other attribute to it (like “deferred” or “rejected”) – I see how this wastes time but in the beginning it could help create a shared understanding of trivial that may be wasting time
- a team member argues that it’s not worth fixing – that is the case with a few bugs in general, but in the end our product owner decides and needs allege information we can provide so we would log all trivial bugs
- a tester has spent 15 minutes documenting a trivial bug. – I try to note down the more trivial ones and keep them tip the end to log but yes I understand the value of using the 15 minutes to try and test to find something more juicy to log.
I think I will struggle with this concept for a while. Is it more of an issue in very big teams?
Why do I struggle?
I was taught to log anything and everything but maybe that is because I used to work for a third party games testing company providing a service and then after that I worked with a distributed team across different time zones.
So there was no time to discuss that we were aware of minor/trivial bugs but decided to not log them. We just documented everything.
Currently I still preach the same philosophy but in my last job we had a nice turnaround where any bug not touched in 6 months was closed, BUT trivial/minor bugs which tended to be grammar or spelling mistakes were actually prioritized as they are customer facing and cause the customer an annoyance. They tend to lower my own trust in a product as well.
I think it also depends how you define minor or trivial? This will vary from context to context and from project to project.
Maybe we can use the Jerry Weinberg quote “Quality is value to some person.” and state:
Bugs are minor/trivial to some person during some project.