Are all bugs serious enough to log?
I found one during testing today that raised the question of the costs of raising, triaging, fixing and retesting a bug compared with the costs of just leaving it in the system.
It set off some interesting discussions on Twitter on the subject.
@kinofrost @Kalyr Yes. If logging a bug is more likely to add more cost than value, don't log it — for now. … but do mention it.
— Ben Simo (@QualityFrog) June 18, 2014
@Kalyr Are you measured by how many bugs you find?
More serious answer – are you sure you are able to assess the triviality of it?
— pkirkham (@pkirkham) June 18, 2014
@QualityFrog @kinofrost @Kalyr If it bugs you then record else not?If you are only person in the forest hearing thunder did someone else did
— Mohinder Khosla (@mpkhosla) June 18, 2014
@mpkhosla @kinofrost @Kalyr Not recording doesn't mean I tell no one. Trivial bug may be a costly distraction, or may not be trivial.
— Ben Simo (@QualityFrog) June 18, 2014
@kinofrost To my experience "baby dragons" like that can grow big. Could be good to MIP or log somewhere. @QualityFrog @mpkhosla @Kalyr
— Annie Rydholm (@AnnieRydholm) June 18, 2014
The bug in question was a drop-down list for an optional value in a create dialog in a relatively little-used part of the system. One of the values in the dropdown was not valid, and quite obviously not so, at least with the data in the test system. If you selected that bogus value and saved the record, the server-side code didn’t throw an error, but inserted null into the column.
Since neither the field nore the underlying column were mandatory, the bug didn’t result in any data corruption, and it did save the correct value to the database if you selected one of the legitimate, valid values.
From a user perspective, it’s more of an irritation than a major issue; it certainly doesn’t prevent you from using the feature in its intended way.
In the end I discussed it with the business analyst, and we agreed to log it in the bug tracking system, but assign a low severity.