Breaking software, or not

There is a lot of talk about testers breaking software: articles, blog posts and even books on this topic. It seems that a lot of testers get their job satisfaction in breaking stuff and a sign of a good tester is that they can break anything. But when they’re testing, are they really breaking s/w?

If this was the case, different techniques for breaking s/w would have been created and refined over the years…

Or

And possibly in a galaxy far, far away...

Another opinion which is very different is that testers don’t break s/w, but rather the s/w is already broken before testers get their hands on it. In this case, a major role of the tester is to identify where the software is broken.

Initially, testers may question the s/w engineers’ abilities since they are delivering broken code. But on reflection, the errors may have been introduced before the coding had started and if it wasn’t for the engineer’s mistakes, the tester wouldn’t have a job to do anyway.

Therefore, the testing techniques and methods deployed by the tester when testing the s/w should revolve around identifying the areas that are broken.


When something is broken, it’s an error that has manifested itself as a software fault, or bug. The tester’s role is to spot or discover these bugs as they reveal themselves. An expert tester is able to spot them quickly, in an effective manner.
How do they spot them quickly? It’s because the expert testers believe in the ancient Chinese warrior Sun Tzu, who taught his men to “Know your enemy”. Expert testers know their bugs. They know where they often hide, know how they operate, what kind of diversion techniques they use and they know how they reproduce.

Would you like to be an expert tester? To be an expert tester you need to start thinking like a bug, get in the bugs’ shoes. Get to know everything about bugs.

Every time you approach s/w to test, think before you start: How would a bug reveal it self in this s/w? Or in short: What Would Bugs Do? This can be shortened so it’s easier to remember: “WWBD?” And if that is still hard to remember, there is lots of stuff out there you could order to help you recall “WWBD?”: T-shirts, wrists bands, mugs, etc.

Happy bug hunting :o)


*************************************************************

Of course, the ultimate testing expert doesn’t have an enemy. The ultimate testing expert works closely with the developers to reduce the number of bugs created in the first place… but that’s another story.

*************************************************************


Trivia:
The first testers who came up with the idea that testers don't break software were most likely Cem Kaner or John Bach during the mid nineties. A gold star for anyone how can confirm the correct date and place for this.

Links:
The main theme of the post is around discovering bugs. This links well to exploratory testing, do check out Michael Bolton’s list of resources for exploratory testing articles/blog posts.
The next testing book I wan to read is "How to break software" by James Whittaker. He seems to have a different opinion to this blog post. I'll let you know if James changes my mind.

Here’s another cartoon from Torsten J. Zelger about breaking software.

*************************************************************