| testing.com > Testing Craft > Techniques (Handling Bugs) > Failure Improvement > Finding More Serious Consequences |
Created and summarized by Brian Marick.
The task of taking an observed failure and finding a more compelling consequence of the underlying problem is one part of failure improvement. Here's an example.
I was testing a product written in Java. Users of the product had user names and passwords. The user design specification ("UI spec") was by far the most complete one I've ever seen. It said that user names could contain embedded spaces, but could neither begin nor end with spaces. The reason, I think, was that user names should not confuse other people. Suppose this product was an instant messaging service. (It wasn't, but I don't want to identify the product.) Whenever you logged on, a message saying you had done so might be displayed to other users of the system. For example:
Sophie Marick has now logged on.
Someone who wanted to contact Sophie Marick would type some command including the string "Sophie Marick". Suppose that Sophie chose a name with a leading space. Then the message would look like this:
Sophie Marick has now logged on.
What string do you suppose people would type to contact Sophie? Would they notice the leading space? No. They'd think there's a bug in the product. So the name restriction was a good one..
It was not, however, correctly implemented. You could create a name with a leading space.
This was an internet startup. There was not going to be time to implement huge chunks of the UI spec. Suppose I'd reported a bug with a Summary like "can incorrectly create user name with leading spaces". That would have been immediately assigned a "fix when hell freezes over" priority.
So I did a little more digging. What else could go wrong, once a bad user name was created?
I knew something about the implementation of the product. All the information about the user was stored in a file on the disk, named with the user name, encrypted with the password. Because I followed my usual practice of reading all the bug reports, I knew that there were bugs associated with filenames with blanks in them. Once I realized that, it was obvious what to do next. I created a user with a leading blank, exited the program, restarted it, and tried to log on as that user (which meant the program tried to read the file).
The program crashed. If I recall correctly, that user identity was permanently lost. You couldn't work around the problem by renaming the file. Moreover, since the file was encrypted, everything in it - the record of everything done in that first session - was unavailable. (Though I suppose one could write a separate program to do the decryption, given the password.)
That makes for a much nicer bug report Summary line:
crash and permanent loss of data (username with leading blanks)
Be the first person to add a comment in the
Wiki Forum at page FailureConsequencesCaseStudy.
(The Forum is explained in its FrontPage.)
In this spot, the author of this page will occasionally summarize the discussion in the Forum.