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.

6 thoughts on “Break stuff

  1. I once wrote somewhere that I think a good tester can be a cross between a crime sleuth, an investigative journalist, a scientist (occasionally a mad scientist) and a philosopher.

    I think the “break it” mentaility is good sometimes in the background – so maybe I need to add demolition specialist to the list (or mad axeman – depending on your mood.)

    Maybe there’s also a need for a bomb disposal mentality too – to be able to pick the error/defect/situation apart to understand what will make it “go off”/explode.

  2. Hi Trish,
    I think the “I’ll break it” (tester-meaning of break) mentality is quite important when you start a testing session. Starting off with the idea that things will work smoothly might make overlook things.

    However, for me it is vital (by now) to be able to switch from “breaking” to analyzing mode. This also includes finding ways that may reduce the severity of a problem. One example (don’t know were I read it) is “Printing doesn’t work with the toolbar button, but it’s still possible with CTRL-P”.

    You must be able to take the whole situation into account.

  3. Hi Markus,

    I agree, I have found that being able to switch from one mentality to another is a really important skill. I know what you mean about having to take the whole situation into account. Thanks for sharing.

Comments are closed.