Performing a Root Cause Analysis for a simple bug takes too much time
In a previous post I described how we performed a root cause analysis for a simple bug: one incorrect value in a dropdown. Performing such a heavy analysis (which generates a lot of rework) may not be appropriate for every bug.
Here’s how another team handled a very similar bug: one value missing from a dropdown.
The fast way to deal with simple bugs
- There’s a bug: in one screen one of the dropdowns misses one value: “X”. This bug is unexpected: in all other screens the behaviour of the dropdowns is correct, each of them contains “X” as the final and default value. This bug only appears in one screen. Why only this screen? What’s so special about this screen? Isn’t this the same code for all dropdowns with the same behaviour?
- The bug is reported during internal testing. The bug can be repeated very easily.
- Developers grumble (I told you the “Thank you” step in the algorithm to write perfect code was difficult!)
- A developer takes the bug and fixes it: an extra value “X” is added to the dropdown in the screen
- Tester validates: go into the screen; open the dropdown; the value “X” is there. Bug closed.
- Software gets shipped to customer
- Done. Next bug!
Easy.
A few days later…
- Customer files a bug report: each time they enter this specific screen an “X” gets added to the dropdown. Enter the screen twice, you see “X” “X”. Enter again, you see “X” “X” “X”. And so on…
- Developers grumble: “Not another stupid bugreport!“
- A developer takes the bug and analyses it. “Some idiot has added ‘X’ to this dropdown. Let’s remove that.“
- Tester validates: go into the screen; open the dropdown; no “X” is added. Bug closed.
- Software gets shipped to customer
- Done. Next bug!
Easy. Only took a few minutes to fix and (a few days later) a few minutes to test. And another release to build, ship and install.
A few days later…
- Customer reopens their bug report: when they enter the screen, there is no “X”. To be clear: they expect exactly one “X” in this dropdown (and all similar dropdowns in other screens). Not zero. Not an infinite number.
- Developers grumble. “When will they make up their mind?“
- Developer takes the bug and fixes it: an “X” is added to the dropdown unless there’s already an “X” in the dropdown
- Tester validates: go into the screen, one “X”; go into the screen again, still one “X”; go into the screen again, still one “X”; go into other screens; go into this screen, still one “X”. Stop the application. Restart the application. Go into the screen, one “X”; go into the screen again, still one “X”. Bug closed.
- Software gets shipped to customer
- Done
Easy. Only took an hour or two to fix and (a few days later) an hour to test. And another release to build, ship and install.
And they all lived happily ever after
Except for the customer who grumbles “how can I trust them with the important stuff if they can’t get the simple stuff right?”
Except for the developers who grumble “how can we get any work done if we have to keep fixing these stupid bugs?”
Except for the testers who grumble “why do we have to retest every bugfix a thousand times? Can’t ‘they’ get things right the first time? We need fewer releases, more detailed specs, more elaborate test scripts, more time to test and, above all, a lot more testers to get any quality in this application.“
