Break stuff

Why do testers say that they like to “break” software?

First of all, good testers should know that they don’t “break” software – if the software is indeed “broken” (another contraversial term), it was certainly like that when they found it. All the testers are usually doing is discovering it. So if a good tester claims that they like to “break” software, it seems likely that they are perhaps recklessly using a popularized term used to describe the act of discovering a software defect. “I like to break software” is easier and more fun to say than “I like discovering defective parts of software applications, for some given definition of ‘defective’ within my team or organization”. So to an extent I can forgive the terminology when used around other testers, who should know what “break” is referring to.

So, let’s say that someone “likes discovering defective parts of software applications, for some given definition of ‘defective’ within their team or organization”. I think that’s great, they’re taking joy in their work. But what if that’s their primary focus? If that’s the part they like the most, it makes sense that they would want to spend more time doing that than taking different approaches. Maybe that’s all they think testing is – looking for the points of failure.

Once upon a time, I was that tester. I thought testing was about breaking things. So when given something to test, I would “attack” it with a negative mindset, looking for ways to cause failure. And for what I was trying to achieve, it was effective – I would find many defects this way. But it was such a narrow scope. Testing in this way only finds a certain subset of defects. Not only that, but having this negative mindset meant that instead of trying to improve the software, I was only trying to get it to a point where it didn’t fail.

It made it difficult to deal with some developers, who didn’t appreciate a long list of failures pointed out to them. It made it difficult to advocate bugs, because I would stubbornly insist that the delicious defects I had found were definitely failures, despite what any developer had to say about it. And by then of course it would make developers instinctively more defensive of their code, because I was already telling them they were wrong about something.

But then at some point I realised that “breaking stuff” is really just one testing technique, which can be an effective approach for some contexts. For example, acting as a malicious user can be useful when doing security testing. There are many other useful mindsets that can be used to test software, some of which I’m still discovering.