QATestLab 21, Garmatna str., Kiev, Ukraine ph.: +38(044)277-66-61 http://qatestlab.com/ contact@qa-testlab.com
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.
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.
(c) QATestLab, 2011
http://qatestlab.com/