All throughout my childhood I had the fear. It’s difficult now, as an adult, to describe exactly what that fear is as I haven’t felt it since. However, I suspect you’ll know exactly what I’m talking about when I say:
Just you wait until your father/mother comes home.
That line often came after I broke something. A vase, a window or a shiny new gadget. Breaking things is bad. Broken things aren’t good. Nobody wants something that is broken.
However, seemingly the ability to break things is a trait that is revered in my line of work. I see it all the time with recruiters looking for testers who “love trying to break software” but I especially cringe when testers themselves take the notion of broken software and wear it as a badge of honour.
I hate broken software. Broken software means somewhere down the line, something went wrong. That alone isn’t necessarily a bad thing as we can learn from our mistakes, but the mindset of ‘I’m going to break this!’ is a destructive one. It’s a selfish one. It’s an inward thinking one. I love software that works. I love the idea of software helping solve a problem. I love the idea of a real user having an awesome experience with a product I helped make. Sure, it is my job to find things out about the software that can lead us, as an engineering team, to make improvements and from a certain point of view you could call that breaking things, I just don’t like to think about it like that. I like to think about it that I’ve discovered something new about the product that I didn’t know before which would ultimately lead to a terrible experience for the user. Discovering this doesn’t get me off. I’m quietly pleased I’m adding value to a process but I’m not shouting from the roof tops that I’ve found a bug.
Testers preach that quality is a team goal. It isn’t our job to ‘assure quality’. It isn’t our responsibility to produce quality software. Sure, I love that. But if you really believe that and are true to that ethos then you have to stop taking pride in breaking things. Instead, channel that negativity into a positive learning experience that the whole team can benefit from. We often wonder where the ‘us versus them’ scenario derives from and maybe, just maybe, we should look in the mirror before casting blame.
I’d also have strong words with anyone who whips out the oh-so-witty ‘I don’t break things, it was already broken when I got it’ retort (which, shamefully, I’ll admit to have used in the past, but we all make mistakes!) – that in itself isn’t an overly helpful remark either.
People get annoyed at broken things. Whether it be a user, a stakeholder or a parent coming home from work to find out little Johnny broke the glass over a fire place by playing football indoors (wasn’t me, honest, it was little Johnny), nobody wants to have to work with a broken thing – a simple mindset change can shift the focus of ‘broken and negative’ to ‘discovery and positive’ and start producing really kick ass products and as a tester, be proud of that.