The 4 Biggest Software Testing Myths

As with any other area of expertise, there are a fair few myths of software testing around. Some of these are borne of ignorance of the specialty of software testing, yet some come about from overconfidence. As they say, familiarity breeds contempt. In any case, there are too many myths to list all of them, but these are some of the biggest ones around.

4 Biggest Software Testing Myths:

1 – Software testing is unnecessary

You might think that this attitude has been turned on its head and no one subscribes to this belief anymore. You’d be wrong. This belief is still strong with many, and yet many more know that software testing is necessary and still attempt to do without.

At the risk of alienating readers, let’s remind ourselves exactly why we test. We test because testing identifies faults. Removing these faults increases the software quality by increasing the software’s potential reliability. Testing is the measurement of software quality, therefore we measure how closely we have achieved quality by testing factors such as correctness, reliability, usability, maintainability, reusability, testability, security etc.

In conclusion, if you don’t test, you risk sending software out there that is non compliant, non functional and not operational. In short, bad software.

2 – Testing is easy

Too many people assume that testing can’t be that hard if a general, everyday user find bugs all the time. In fact, that is a very unfair assessment, especially as testing is a very complex craft which is not suited to your average person. According to Google’s Patrick Copeland, here is, what according to him makes a great tester:

“From the 100s of interviews I’ve done,  “great” boils down to: 1) a special predisposition to finding problems  and 2) a passion for testing to go along with that predisposition. In other words, they love testing and they are good at it. They also appreciate that the challenges of testing are, more often than not, equal or greater than the challenges of programming. A great “career” tester with the testing gene and the right attitude will always be able to find a job. They are gold.”

Doesn’t sound so easy now, does it?

3 – Testing is about trying to break stuff

True, some testing is about trying to break stuff, but that is stress testing, and not all testing. In fact, stress testing is only one kind of test, whereas dozens of varieties exist and are used. You can’t test the usability of a product by trying to get it to break.

Similarly, you can’t test a program’s performance if all you’re trying to do is make it crash. Sometimes yes, we will try to break stuff, but only because we need to know at what point stuff breaks, so we’re not just doing it for the sake of breaking things.

Testing is very much about providing feedback to the customer and to development team, feedback that the product is working or feedback that the product needs to be adjusted to fulfil the needs.

4 – Testers don’t like developers

This one is just plain unpleasant. And untrue. If anything, in the few cases where this might have been true, the reasons behind it point the blame at higher levels of management who allowed unfair work practices and a tradition of ‘throwing code over the fence’. In many companies today this is very different.

Developers and testers need to work hand in hand and side by side very often and ownership of the code is best seen and being everybody’s not just whoever wrote it. This is a much healthier attitude and demands respect both for the developer’s work, as well as the tester’s.

So in short, no, testers do not dislike developers, and in fact, a lot of testers have also spent a lot of time coding.. Additionally, do you think that we enjoy pointing out 500 issues in a piece of code, especially when we have to retest it after it’s fixed?