Nothing is more difficult than competing with a myth.

Francoise Giroud

Many myths continue to thrive in software testing, leading to insidious problems in the industry. In this article, we challenge them and present to you the truth to make informed decisions.

Myth 1: Testing is Expensive

Reality: Testing is not cheap, but not testing is even more expensive. A study by IBM demonstrated that fixing a production defect is at least six times more costly than testing. Defects also lead to a bad customer experience and possible loss of customers.

Myth 2: Testing is Time-Consuming

Reality: Test can be time-consuming when it is considered an afterthought. Testing processes can happen parallelly during the SDLC phases. The QA team should start writing test cases and begin planning as soon as the software specification is made available. When the developers finish coding their modules, the testers can perform unit testing and integration testing. System testing indeed takes time because it is a manual process. But if you plan well, you can ensure that the release is not delayed unnecessarily.

Myth 3: Only Fully Developed Products are Tested

Reality: There is no doubt that testing relies on the source code, but testing processes and planning can begin as soon as the software specification document is available. Your QA team can start writing tests as soon as the software specification is available without waiting for the developers to complete coding.

Myth 4: Complete Testing is Possible

Reality: Software is inherently complex, and practically, no amount of testing can fully test a software application. Almost all software applications depend on other software libraries or components which means that bugs in those areas will be manifest to end-users.

Myth 5: A tested software is bug-free

Reality: This is a widespread misconception believed by clients, managers, and even novice developers. Even after an experienced tester has reviewed the application, no one can say with utter certainty that a software application is 100 percent bug-free.

Myth 6: Missed flaws are due to testers

Reality: This is not always true. Developers have a habit of changing the code without notifying the QA group because they believe it was "just a small change." Sometimes the time allocated to testing is not enough to do thorough testing. In some cases, the documentation is ambiguous and open to interpretation resulting incomplete or incorrect test cases.

Myth 7: Testers are in charge of the quality of the product

Reality: Software quality has multiple dimensions and is challenging to achieve. To be sincere about quality means dedicating enough time and resources to it. Unfortunately, in many instances, this is not the case. The testing team is often the scapegoat because it is easy to ask them: "How did you not test this basic thing?". The answer is not easy as it appears.

Myth 8: Test automation always decreases the time

Reality: Yes, automated testing can decrease time if used appropriately. In some cases, like malware and vulnerability scanning in security testing, automation can significantly reduce time without much human effort. But in most cases, automation requires a non-trivial setup, massive test data, and entering scenarios. If requirements are changing, automated testing can be slower and end up wasting even more time.

Myth 9: Anyone can test a software application

Reality: People outside the IT industry believe that anyone can test software and that testing is not a creative process. Testers, however, know very well that this is a myth. A good tester can write faster, fewer, and more effective test cases than a bad tester. During ad hoc testing, a good tester can easily outshine an average tester. Not everyone can be a detective!

Myth 10: A tester's only job is to find bugs

Reality: The job of the QA team is to reduce the overall cost of quality and secure customer satisfaction, which means ensuring high quality in all the applicable software quality dimensions, not just bugs. It starts with examining functional suitability to testing end-user usability. But if a team hires testers only for hunting defects, that is all they will get.

Conclusion

There are misconceptions in every field, and software testing is no exception. We hope that we have helped you bust at least a few of these myths. We don't expect you to take our word for granted, but hopefully, you will challenge the story and discover the truth for yourself.

Do you know of some other myths? Let us know.