Myths and Rakes: the Purpose of Testing is to Find Errors

Myths and Rakes: the Purpose of Testing is to Find Errors
May 06 13:00 2011 Print This Article

One of the biggest misconceptions of software testers is a myth that their job is to find errors. Let’s try to understand what a misconception is. Such an approach implies the following statement: completed testing means that all errors are detected. But we all know that this assertion is impossible.

Myths and Rakes: the Purpose of Testing is to Find Errors

Should I list the reasons – an incredible number of combination of user, environment variables, input data and so on. This number is almost infinite, and proves that the process of finding errors can never be completed. Even if you are able to undertake this comprehensive testing and fit in more or less reasonable period of time, your potential customers find by the time another alternative.

Worse yet, the myth creates a false target of tester – the more errors I find – the better “- they think they torture poor application in an exotic environment with incredible data. In principle, any user can fill up the application, if strongly try. But to be truthful normal users are more interested in what works in an application, rather than something that does not work.

Reports about the incredible errors cause chuckle from the developer and the disappointment of the customer, because it takes away time and resources away from the main goal – to make sure that the application does what the user needs. If you do not believe that users would donate to such “quality” for the sake of functionality, just look at the number of known bugs which have a popular product (for example, your favorite OS, office suite or a browser).

Also, this myth prevents continuous monitoring of the basic functionality, because the probability of finding errors in it is small enough and testers lose all interest in it. But in developing software that works now, does not mean that it will always work. And one small software bug in the vital functionality will be very expensive. Even if you have a huge list of known bugs, which you received when combing various boundary conditions and other things, he is unlikely to comfort the user / customer, when the main functionality is faulty.

Related Posts:

  • No Related Posts

About Article Author

view more articles
Nataliia Vasylyna

View More Articles
  • Cor van Rijn

    IMHO the goal of software testing is to reduce the risk that is involved once the application goes into production.
    This risk can be defined as the probability of unexpected behaviour of the application and the cost of that behaviour.

    It simply means that one should extensively tests where occurring errors hurt you the most (f.e. the brakes in a car !), and test less where it does not hurt or only hurts a little (f.e. the radio in a car).
    Furthermore the cost of testing should not outweigh the cost of failure.

    Furthermore continue to monitor and retest the functionalities that are being used the most frequent, if they are relevant to the success of the application.

  • cleanupinterior

    I’d must look at along here. That is it’s unlikely that any matter I do! I like examining a write-up which will help make people imagine. Moreover, appreciate it for permitting me to help comment!

  • http://www.cloudstaff.com/ Zora Ferrel

    Thank you for posting this informative article on the myths of software testing. The information are really helpful. Cheers!

  • http://www.process-box.com/ Clarissa Lucas

    A very good read about myths in software testing. The facts are really helpful. Thanks for sharing.