Friday, 30 July 2010

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…


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.


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.

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.


Tuesday, 27 July 2010

The Testing Planet

Guess what?! The STC have just released a new testing newspaper, THE TESTING PLANET!!! They've included 4 never seens cartoons. I managed to get a hard copy and the whole newspaper looks great, with good and relevant articles and it has a crossword too – they’ve thought of everything!

While on a similar topic, I must thank Rob Lambert from STC. He was the first tester to see my cartoons and he gave me lots of positive feedback. If it wasn’t for him, this blog might never have happened. One of Rob’s recent blog posts was about loosing one’s testing mojo… after my time out (and all the sport on TV) I’ve lost mine, I must find it back.

Just a quick note on one the cartoons in the testing planet as I feel I need to explain my self!
The naked tester cartoon - (which is on the same page as articles from Lisa Crispin and Anne-Marie Charrett. I’m not worthy!) the idea originated from some one in my team who came up with the name “the naked smoke test”; where we trimmed down an older automated smoke test so it would run quicker. Unfortunately the name didn’t stick. Some testers didn’t like it and the developers were really scared, I think they thought we were going to run the automated smoke test while naked – What’s scary about that?

... Anyway, do download The Testing Planet, it's a great read.