What is a bug?
March 31, 2022Is any failure to meet user expectations a bug?
What is a “bug” to you?
I hear two common definitions:
Any software behavior that differs from user expectation.
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.
What's the ideal ratio of devs to QAs?
Of course, as a consultant, I can confidently tell you: It depends!
I just threw away a bunch of tests
I had failed to complete the "refactor" part of "red/green/refactor" several weeks ago, leaving me with some redundant tests that came back to bite me.