It’s a Bug!

As a tester, there’s probably not a phrase more often heard than; “It’s a Bug!” or “I’ve found a Bug!”  Usually, the phrase is delivered more emphatically by people who aren’t actually testers.  The Project Manager, Tech Writer, Customer, and of course Developers seem to take a small thrill in finding bugs in the software.  I’m not sure if it’s because they enjoy finding errors in other people’s work or simply think that bug finding is a game or puzzle and they’ve just won a prize.

 “I’ll take Software Errors for $400 Alex!”

But the problem I’ve often found with the quick-to-label “It’s a Bug!” is that once that bell is rung, it cannot be unheard; especially if an end user is within earshot.  Suddenly, the whole application’s stability is called into question and quite often, there’s no proof that there’s even an actual bug.

When is a Bug not a Bug?

The term bug carries a very large stigma in Software Engineering.  It’s used to describe everything from the wrong color of a button to a leak in memory causing massive system failure.  Imagine the same label being applied to the code that caused the Pentium to fail Long Division to the code that made a red button look pink.  But this is done all the time.  Those of us in the know will quickly add to the label words like “minor”, “critical”, “showstopper” and “negligible.”  However, the common user will still simply hear the words “It’s a Bug!”

Ben Simo (@QualityFrog) recently tweeted:

 “There is a big difference between your code ‘working’ and doing what it’s supposed to do”

I think this may be where a lot of the breakdown occurs; somewhere between what the developer codes and what the user expects.  Inside this gap, there be bugs….or at least what everyone calls bugs.  And in all fairness, they’re kind of right.

If Something Doesn’t Work The Way You Expect It, Is It A Bug?

There’s the main question; when is a bug really a bug?  And who gets to decide the criteria?