It's amazing how many product teams never give enough importance to testing (and testers). And the excuses you hear are even more astonishing; albeit funny. With all the free and open source testing tools, services, sites, blogs and books available, one can no longer have any more excuses not to perform software testing on their product before they release it. It might come as a surprise to some, but in most cases many developers do not get the opportunity to work with a truly competent tester and hence they don't know what that is like. Ignoring the importance of testing and testers in a team is such a hideous false economy that it is hard to believe so many organizations and people still believe in it and hence have to resort to these stupid excuses for not having enough testing/testers.
I realize that it may be hard to rank these (dumb) reasons that people like to use for not doing enough testers (and hiring enough testers) but here are the top 5 stupid reasons people don't hire testers.
1. My Product isn't Finished Yet
In today's rapid development age where methodologies like agile scrum and sprint are mainstream, how more absurd could your excuse be than this one? Even if you work in an environment where several Beta versions are released first before the final product, will you be willing to risk losing your customer's trust and your reputation by releasing versions that are laced with defects?
Also, will you be willing to bet that your star programmer doesn't leave you and join another organization with a dedicated testing team and proper QA methodologies in place, because he got fed up reading through and fixing hundreds of customer reported bugs everyday? The sooner you realize the importance of finding and fixing bugs earlier in the product cycle, not only will it save you revenue but also your reputation.
2. Quality is Everyone's Responsibility; No Dedicated Testers are Needed
Such excuses usually come from teams that (at least believe that they) follow the mantra ""Quality is everyone's responsibility"", and hence they jump into this inappropriate misconception that you can actually get great results without dedicated testers. Theoretically, this all works. But the problem begins when everyone starts assuming that every other guy in the other cubicles are already testing the product and hence it is okay if he skips it.
An extension to the above excuse that I hear frequently is that the programmers will become lazy and end up writing buggy code if they know there is a testing team responsible of finding the defects. But let's face it; programmers are either lazy or they're not! A programmer who takes pride in his work will rigorously test his code no matter whether or not you have a dedicated team of testers.
3. We have Budget/Time Constraints.
Who doesn't? Do-it-yourself testing by your programmers can save you some dollars and can even be effective (if theyâ€™re imaginative). Also, it is still cheaper to hire an average tester than it is to hire an average programmer. And if you don't hire testers, you're going to end up having your programmers doing testing.
From my own experience, not only the programmers are mediocre when it comes to testing but they also tend to overlook errors in their code as compared to a tester testing it. Everyone has budget constraints. But great product teams are good at realizing the importance of a dedicated QA team on board and they know it is more of an investment than an unnecessary expense. And here are some things to consider if you're worrying about testing on a tight schedule.
4. My Product is Perfect. It doesn't need Testing.
Actually, NO! If your product is perfect then either it is not a product or isn't actually perfect. In either of the cases, this means that all products need testing as long as they are complex enough to qualify as good usable products (software, website, web application etc).
5. A separate QA team can build an 'Us vs Them mentality', which is not Healthy
I've worked in teams where test and dev reported to the same manager, and also in teams where the testers reported to dedicated test managers. In my experience, both of these can work well provided the office politics is kept under control and the team's manager is responsible at ensuring so. Good teams realize that a dedicated testing team is essential to the team's overall success and that the QA team not only saves the programmers a lot of time (and credibility) by helping them fix defects before they find their way to the customers but also save the stakeholders substantial revenue that would otherwise be spent on fixing the bugs in a post-release scenario and would require subsequent patches to be released; not to mention the frustrated customers and angry investors.
As per the 'Us vs Them mentality', it is in the hand of the team's managers and the stakeholders and how they manage their resources. There is a reason why people still use the old saying -- 'garbage in is garbage out'!