I was involved in a conversation today that started something like this:
Team X: “Feature Y is completely broken, but we don’t want to fix it because we don’t think any users will actually use it this way.”
My first instinct was, “Are you crazy? The fix is so easy and low risk! Of course you should fix it!” After all, if we as testers can help our teams validate fixes with high confidence, why wouldn’t we?
My first instinct was dead wrong.
This is a trap I still occasionally fall into, admittedly. But it’s a dangerous one that can have repercussions long after the decision is made. Essentially, my first instinct would have signed up Team X to spend the next decade supporting, manually testing, automation testing, statically analyzing, re-testing, servicing, and likely re-engineering several times a feature that nobody would ever use.
In cases like this, the right question to ask is “why is that feature even in the product?” If you wouldn’t fix a bad bug in a given feature, then why bother building that feature in the first place?
As testers, we need to change our basic instincts from “fix every bug” to “what’s in it for the user?” If we aren’t getting enough value for the long-term cost of building and maintaining the feature, we should negotiate to get those features removed from our products.
Complexity leads to cost, cost leads to fatigue, fatigue leads to shortcuts, shortcuts lead to holes, holes lead to dark places you don’t want to find yourself in, lest you be eaten by a Grue.