When to not look for Bugs

I love finding bugs.  I realized this again recently while testing an area of the code that was pretty buggy.  As a tester there is something thrilling about having thought of ways that the code might not work well and then having your ideas validated as you watch the application start to self-destruct in front of you.  When I find a particularly bad defect I find that I want to go talk to some other testers and ‘brag’ for a while about the way I found it, but is this healthy?  Should I be celebrating the finding of bugs, or am I like an addict seeking the next thrill as I try to hunt down bugs in the software?

I don’t think there is an easy answer to that question, but I want to explore the idea that testers should not want to find bugs.  This is of course not true in the absolutist sense, but thinking about the reasons we don’t want to find bugs can be a very helpful exercise and so today I want to think about one of reasons you might not want to focus on finding bugs.

We are part of a team

Finding bugs is often about shattering illusions.  When we find a bug we are demonstrating that someone’s idea of working software is wrong.  Illusions (or biases) are some of the biggest problems we have in software development.  Our lack of ability to make the software do the things that add value for people is at the heart of what makes software development so hard.

But let me ask this question:  Who’s job is it to get a good quality product to the customer?

Let me take you to story from outside of software engineering.  After dinner in the evening, I usually clean up the dishes.  I clear the table and load the dishwasher etc.  One day, however, my wife said something interesting to me.  She told me that she would appreciate it if I would also wipe down the counter when I was done.  Now here’s the funny thing: I was wiping down the counter!  It was just that my wife and I had different standards as to what constituted a well wiped counter. At this point the illusion of adequate counter wiping had been broken.  Now, let’s imagine that the next day I did nothing different.  I wiped the counter the same way I always had.  And so once again my wife tells me that the counter is dirty.  I quickly clean it up but then the next day it happens again.  I don’t do a good job, my wife points it out and I fix it up.  No harm done right? At the end of day the counter is cleaned to the quality standard we want, so what does it matter? Well I think any of you in a relationship understand that there is harm done.  There are a couple of healthy choices here for the relationship (have a conversation to agree on what will be considered a clean counter, who will do it etc.), but to have a relationship where one person keeps giving feedback to the other person who ignores that feedback is only going to create a wedge and distance between the two parties.

Probably by now the moral of the story is pretty clear.  If we as testers keep pointing out the issues and developers keep doing the same things over and over, are we in the kind of relationship with each other that is growing together or apart?  The answer to the question of who’s job it is to get a good quality product to the customer is everyone!  The whole team is responsible for this. But how are we going to do this effectively if we can’t work together as a team?   Finding bugs is not wrong or bad, but when we find ourselves repeating the same feedback over and over again without things changing, the relationship might not be optimal.  It might be time to pursue the kinds of conversations that can bring consensus to the team on what constitutes a well wiped counter and how to make sure it gets properly wiped from the start. The effective shipping of high quality software takes a team working together.  If it is consistently easy to find ‘big’ bugs in your product, it might be sign that your team needs you to focus more on building relationships and a bit less on finding bugs.