I Don’t Like Breaking Things

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.

4 comments: On I Don’t Like Breaking Things

  • I really like your conclussion! As a tester we have a negative job, but you can try to maintain a positive attitude to the issues found!

  • I agree with the sentiment of the post but I think it’s wrong to look at any software as broken at any point before it’s released. Software *released* with bugs is broken, and none of the team should be happy with that – nobody likes broken things. I don’t like breaking things either, but I don’t think that’s part of my job; I’m happy to find bugs when I’m testing – not because I’m looking at a smashed vase, but because I’ve found a hairline crack in that vase that can be repaired before it breaks.

    So while I agree that “I’m going to break this!” is the wrong approach, I also reckon that “I *really* want this to work perfectly” is not only too far the other way, but will inevitably lead to disappointment.

    • Hey Ian – sure, I can get behind that. I think we’re pretty much saying the same thing to be fair. I love the concept of software not being broken until it’s out there and consumers report those bugs, or to use your analogy, those hairline cracks were missed and now the end user has a smashed vase.

      I’m quietly pleased when I find bugs when I’m testing, after all, that’s what my job is. Then again, I also usually work to the philosophy that it isn’t strictly speaking a bug. I don’t like raising bug reports, I prefer to work with a developer to get the issue fixed without having to go through red tape. Again, different scenario whenever it is an issue found by a customer / user, but I tend to only label things as ‘bugs’ when somebody somewhere says ‘Yes, that piece of work is complete’ and we retrospectively find a problem – be it by tester, user or other.

      I think we agree 🙂

Leave a reply:

Your email address will not be published.

Sliding Sidebar

About Me

About Me

Hi. I'm Neill. I'm a software tester from Belfast. You could say a Belfast Tester. I've worked in some companies and all my thoughts are my own. Not the man's. I can think for myself. Honestly.

Latest Posts

Social Profiles