Thursday, September 8, 2011

Oh that Bug? Yeah it happens all the time, don't worry about it.

Tell me if you've heard this one before.   A User calls into a help desk saying, hey when I go to do X with my software, instead of doing X, something else totally unexpected happens?   And at some time in the past a root cause analysis is done on this, and they discover what has happened.  The user has done something to the software, perhaps they've configured some optional setting that isn't a part of the normal settings, or maybe an incompatibility with another piece of hardware or software results in it being unable to perform the problem.

Normally you would expect the team to find, and smash this bug, and fix the defect right? Well what if that wasn't what they wanted?  Or what if it was a feature they wanted to leave as it was.  Maybe its a link to some documentation that moved on a website.  It might be easy to fix, but getting a patch might be more expensive than simply telling the user another way to get that data?  This situation comes to mind as I viewed today's Wizard of Id Comic:


If you've been on any software team long enough, odds are you'll eventually come across a defect or bug that you see as a potential loss of value in the product.  After discussion with the team, that bug may be marked as deferred, or left as designed by the developer, and not handled as it is slowly forgotten in the code base.   There are times when cosmetic changes, a font size, a color, may not make much difference to the overall user experience, but what if this deferred bug turns out to be something more, more insidious?  What if it could be the bug that begins to build to a buffer overflow vulnerability that could result in your system being compromised and hacked?

As testers, its important that we maintain objectivity as we are testing.  Sometimes, the development team may not all see eye to eye on what is of value to change for the customer, but we must be every cautious when a somewhat mundane bug is deferred.  Deferred bugs may never get fixed, and as they get left in their unfixed state.  Sometimes this may be fine, and something we have to accept as we strive to produce the most value for our clients, but we must always be careful that the thing we are putting off could be something serious that could put our customer, our client data, or even our own companies at serious risk.

2 comments:

  1. So is it a bad thing if a vendor tends to classify most of their bugs as "as designed" or "deferred"? :-)

    Seriously, though, I am with you on this. I've worked on projects that have had minor bugs "deferred" for, literally, years... and this is a software package that gets patches/point releases at LEAST twice a year. When doing UAT with each release it gets to be pretty tiresome to report the SAME thing over and over.

    ReplyDelete
  2. I'm not sure if classifying most bugs is necessarily the problem. Some teams will use different names for so called 'cosmetic' or 'style' type bugs. My main point is not necessarily that deferred bugs are bad, but leaving them deferred, 'closed as deferred', or left attached to an old build in the tracking system so it can't be traced is a recipe for something minor that could grow into a mountain of hurt for the project.

    The other truth here is that for many testers, if such bugs continue be deferred, then some bugs may begin to be intentionally left unreported. Why? Because why report a bug, you know is going to be deferred? I don't have to explain why that's dangerous. When the tester has to decide too much about what they don't report, it adds risk to the project in progress I think.

    Thanks for the comment Rick.

    ReplyDelete