Quality Management, Testmanagement, Testautomation, Continuous Integration and Delivery, Jenkins, Consulting, Training, Auditing
3+1 Myths of Software Testing | Comquent GmbH, Continuous Quality in Software

3+1 Myths of Software Testing

By Thursday March 9th, 2017 No Comments
3+1 Myths of Software Testing

A part of Software Development is also Software Testing. Software Testing is the process in which it is precisely examined if the Software meets the defined requirements, if there are deviations or if the requirements where implemented incompletely and if there are any error effects. During testing it is observed if the behavior of the Software is the expected one. According to ANSI/IEEE Std. 610.12-1990 testing is “the process of operating a system or component under specified conditions, observing or recording the results and making an evaluation of some aspects of the system or component.

Software testing is very often underestimated. Due to the fact that as end customer one expects the necessary quality as obvious, one oversees the processes that exist till we get the desired quality and one easily forgets that Software Testing is a significant part of Software Development. In this way many myths come up concerning Software Testing. In this article we will deal with 3+1 of these myths and we eill try to bust them.

Myth 1: Testing is easy, everyone can do it

Many people think that testing is not a particularly demanding job. ” You click here, you click a little bit, maybe you click on some random buttons, you check the results and that’s it” one might think.


Testing is particularly demanding job. As tester one has to know and understand the technical processes in every single detail. The tester must know all differents paths, in order to “catch” them in test cases so that he can test them. It is often requiered that a tester cooperates with the business analyst and the developers so that no piece of information gets lost. This requires high technical understanding and knowledge about the correlation between different subsystem of the software. Thus, the testers are the only persons that can estimate correctly the complexity and effort of testing.

Testers are highly qualified persons that have profound knowledge about test techniques, but also have a real enthusiasm and feeling for quality. And this is can’t be done by everyone! -> Myth busted!

Myth 2: Testing is expensive

A statement we often hear in projects, is that a testing team is expensive and blows up the costs of a project.


In order to make this statement we have to compare the costs caused by a testing team during software development with the costs incurred after o product goes live. In reality, costs caused in order to solve software bugs after go-live are much higher than costs of finding and solving bugs before a system goes live. At the same time one should neither forget nor underestimate the image loss and the following customer loss.

The earlier bugs are found the cheaper it is to resolve them. Take a look at the following images (Source 1 and Source 2):

The images show clearly that early testing leads to enormous financial savings because resolving bugs after go-live can be extremely expensive. Under circumstances resolving bugs can costs many thousands Euro per bug. The earlier you start testing the better and cheaper it gets. In this way the costs to maintain a testing team are compensated easily and you deliver products of high quality -> Myth busted!

Myth 3: The customer is the tester

Some software companies work like “the customer is the tester”. They would deliver the software quickly, the customer will undertake his tests and that’s it.


You can’t just deliver some software to the customer and leave him fight with it on his own. The customer can’t foresee how complicated the required software can be and how complex it is to test it. One shouldn’t also forget that the customer is paying in order to get correct and functional software!

In case we talk about mass products delivered to customers that will be supported by a Customer Service Center we will soon enough find out that it is more expensive to maintain a huge Call Center then to involve a testing team during the software production. In this case too, we shouldn’t forget the aspect of image loss.

Thus, it is clear that the customer can’t be the tester. The customer is king, after all he is paying for everything! -> Myth busted!

Myth 3+1: Testers are responsible for the quality of the Software-Product

Testers are often held responsible for the quality of a product. If the quality is not the expected one, it’s the testers fault.


Testers are the ones measuring the quality of software. Decisive for the quality are the developers and if they did their job good enough and if they resolved the found bugs. You can’t just test quality into the software developed. Testers are of course the ones that have to find the bugs and the deviation from the expected behavior. Bugs are though not resolved from the testers. That’s the job of the developers.

Testers have to sometimes “fight” with the stakeholders. It is possible that bugs are found but stakeholders decide to go live with them. That can be due to time restrictions, political reasons, other priorities and so on. The job of testers is yet already done by finding the bugs and erroneous behaviors.

In projects it often occurs that testing teams get under time pressure and actually run behind schedule. It can happen that there is a go-live date that can’t be broken under no circumstances but the development team hasn’t delivered on time. This way the time available to the testing team get shorter. So it can occur that tests can’t be undertaken in every detail as actually planned and some bugs are not found. But still, the testers can’t be blamed for that.

We can see that the quality of software can depend on many factors. The performance of the testing team is one of them, but still not the only one, so that we can make the testers responsible of substandard quality. -> Myth busted!