Bug to the Future - Ultimate Bug Prevention
Posted by Eric Jacobson at Wednesday, September 08, 2010Yesterday a manager told me they were troubled by a showstopper bug that was found after my team had finished testing a particular build.
(My team uses the “Time’s Up!” heuristic to determine when we’re done testing.)
Then the manager asked me what I could do to prevent this from happening again. I thought long and hard on this question and just when I was about to concede defeat, the ultimate solution came to me.
It may take several iterations, but if my team can build a time machine, we can guarantee no showstopper bugs will escape. I think it will really shorten our test cycles too. We’ll just throw stuff to the users, see what problems they encounter, then travel back in time and log it as a Showstopper...or maybe we'll call it a "Show Stopped". Better yet, we’ll just explain it to dev before they write it.
I just have to work out the predestination paradox, so I don’t get stuck in a causal loop, eternally traveling back in time to prevent the same bug from occurring.
My favorite recent time travel movies:
RSS
And you don't even need to test!
http://strazzere.blogspot.com/2010/04/how-to-achieve-perfect-software-every.html
Eric,
That's a tricky question to answer.
I'm guessing your explanation isn't going to go over too well - especially in the heat of the moment and if there is a hint of cockiness in your tone then you are going to cause yourself pain.
If you really want to get people going - ask why the developers didn't find it in their testing before they gave the product to the test team. More specifically why didn't the unit tests catch it!
If played properly it can give you a good "in" to start talking about the amount and quality of developer testing
Here are some other things I've done
Explain why this phenomenon happens. I have used a sport analogy (hockey here in Canada eh!) where I talked about the testers being "the goalie". There are several other team members who are supposed to be working together to make sure show-stopper don't happen. All you can really do is learn from it and move on.
If it becomes a repeat systemic problem then I might start looking at what my test team is doing a little deeper. I would consider creating a running log of last minute show stoppers or field bugs found.
We've gone so far to create a taxonomy of field issues to see where the general problems are and feed that information back into the development team. (AKA - driving quality upstream)
Another, more subtle method, I've used is to pass out copies of G. Weinberg's Perfect Software. Of course I waited until tempers cooled down as people are much more responsive to the subtitle (and other testing myths)
Lastly - if all else fails - I bring in someone like Michael Bolton, who tells people the same thing I do, but since he's paid to be an expert, they listen to him :)
How to prevent that particular bug from happening again, or any showstopper from happening again? If the former, to Adam's point, you and your team (viz. the devs) can set up some tests to make sure that very thing never escapes.
If the latter, then the time machine seems like a good idea.
Has the idea of lowering the amount of features per iteration (in order to test them more thoroughly) been broached - or is that a stupid question?
I just want to thank you for recommending those movies
I saw "Triangle" and was quite nice.
"Bug to the future " is an unlimate plug in. good post.