Where is the Difference between the Bug and New Feature ?

Bug, Or Not Bug? – That Is the Question

There are thousands of reasons why some functionality or system artifact may be called “bug” …customer says it, customer‘s daughter says it, project sponsor has an idea that this functionality is not so good, project leader found out that his own feature implemented two months ago is a bug… all of these (and many other interpretations) are the artifacts of „agile“ world today.

Seriously – for every IT Project it is the most difficult task to define some rules for recognition of  what’s bug and what’s not (from the beginning I will be using a more feasible term “issue”):

  • Is the issue in contradiction to a well-known pattern ?
  • Is the issue just clarification of the specification ?
  • Has the issue come up after release into production with a loud “Ahaa” (not immediately through verification)?
  • Is the issue duplicate against a resolved issue or not accepted change request in the past ?
  • Is the issue in contradiction against a resolved issue or change request in the past ?
  • Does the issue „just“ improve satisfaction of the users (or just one of them) ?
  • Has the issue been created based on a request from an „end user“ having no project development history knowledge ?

If there is just one “yes” …you can say – sorry, that’s not a bug. It is so simple in the blog, but not in real world.

The customers and stake holders are very often just people without analytic know-how, and even if you are one of the best analysts in the world with neverending budget you cannot always capture all requests and expectations on your software.

Nowadays, one of the answers is called “agile”. Agileness makes the way between analysis, design and verification shorter aiming to achieve a more valuable and faster feedback from users and customers, however, the idea of this article remains unchanged – how to decide whether the issue is a change request or bug.

If I would have the answer to this question, I would be one of the happiest software developers in the world. What I mean is to bring some ideas in this post that can help you in discussions with your customer, collegue or end user of your software.

Requirement Engineering, Business Analysis, Agile, Analysis and Design with UML, Java/J2EE, Liferay, Javascript, Embedded C++, MDD, Executable UML, Project Management