Oh look, the first post on a testing blog is about bugs, how original. I thought I’d start with something which I don’t believe is controversial, just to warm up.
I have a complex relationship with bugs. Earlier in my career I always wanted every bug to be fixed. It used to kill me to see bugs in a product, because it created a noise around my concept of completion. I would fight for every bug I found like it was the end of the world, working as hard as I could to convince Product Managers, Developers, BAs, other Testers and even Project Managers that what I found was important and couldn’t possibly live in our product.
Why? I think there are three reasons for this;
I wanted to the product to be good, and if there were bugs in it then it couldn’t possibly be good, right?
I felt personally responsible for quality, and if there were bugs that I’d allowed to go unfixed then the lack of quality was my fault.
I wanted to prove my worth, if my bugs weren’t valid then what was I adding to the product and if the bug wasn’t a bug then what was the point in me?
So what changed? Why does this not still keep me up at night? Let’s look at addressing each point:
Perfection is unattainable. No software is without flaws. I learnt to try and accept that everything is a compromise. By trying to get every bug fixed my attention was spread across a myriad of issues. Focussing in on just the real show-stoppers would allow us to improve the product in a sustainable way.
Most of the time there is a whole team of people responsible for building a product, and therefore everyone has to be responsible for bugs. Once I try and get other people enthused about getting rid of bugs or understand why other people believe we should be happy to live with them then I don’t feel like a lone warrior. I feel like quality is a burden we are all carrying together, and the load is lighter if you share it. (That’s a rather cheesy way of phrasing it but hopefully the sentiment is clear.)
Okay, imposter's syndrome is hardly new in testing and I think it can be a strong reason why testers fight hard for bugs. We should stop. And here’s why: if I explore a product, find some interesting behaviour, understand what the risks associated are and communicate these to the team, then I am adding value. The point is that everyone now understands what it does, and can make a choice whether to fix it or not. I gave them the choice, I shone the light, that’s brilliant and it should be enough.
Basically you’ll notice that the theme to how I try and let go is to understand that bugs are a shared responsibility. They have to be, because otherwise you can feel as if you are constantly shouting about how you hate the thing that someone has spent time making. If you take bugs as just new things you’ve learned it’s just an increase in knowledge for a team, and then you can share the pain.
Just to clarify, sometimes I find these things really hard to remember in the heat of the moment. I still occasionally feel a little buzz of smug self satisfaction when a bug which I campaigned to get fixed makes it to live and causes shenanigans, requiring high priority fixes. I wish I didn’t, and I hate myself for it, but I do. There are also instances when I end up doing work on teams that do not work like this and it tempts me back to my old habits; I start fighting for perfection again. At these times I try to make sure people know that I am giving them information and then walking away, because they need to be aware that I’m not going to be their conscience for them.
It can be hard, but it’s necessary to not fall into the lonely, unpleasant world of single-point bug ownership. It improves your own happiness and that’s really all that matters in the end.
