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.
