Blog / Quality Engineering

What is a bug?

Is any failure to meet user expectations a bug?

What is a “bug” to you?

I hear two common definitions:

  1. Any software behavior that differs from user expectation.

  2. Any software behavior that differs from the intention/specification.

Both have their place. And a lot of product-minded people strongly prefer the first. I understand that view, if you’re product-minded. If the product doesn’t do what the user expects, it’s a defective product, right?

Well, I believe the second definition is far more useful, at least in the realm of software development and delivery:

1. User expectation is entirely subjective.

If I expect my hammer to drive screws, and it doesn’t, perhaps a case can be made that the hammer is defective from a product-centric standpoint. And if I want to return the hammer to the store on the grounds that it doesn’t drive screws, that’s fine. I expect most stores would offer a refund.

But from an engineering standpoint, what matters more is: Do I need to change the product?

2. Feature changes and broken features should be prioritized differently

If my hammer head falls off when I try to hit a nail, I call that a bug, and is more important to fix than the fact that it can’t drive screws.

Or maybe we’ve decided that we want to build a hammer that can drive screws, but it also has a head that falls of when hitting nails. Which “defect” should we fix first?

In my opinion, we should always fix failures in the intended functionality first, and only after that’s done should we consider adding new functionality.

Share this

Related Content

My Most Controversial Opinions

Edited by Taavi Kivisik Happy New Year to everyone! I was excited to kickstart the new year with a new position at Lana, a Spanish FinTech startup. As part of my first week on the job, I met a candidate for another position there, and we started talking about controversial opinions in IT. Unfortunately, we found nothing to disagree about. Although I was inspired to catalog a number of my own personal opinions about software development, which may be more controversial.

Stop waiting

You never need to wait for permission to start doing quality work.

Should testing be a separate user story?

It's like mixing the eggs and mixing the flour as different parts of a cake recipe.