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. Read on...
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.
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.
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.
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).
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'!
Let me know if I missed any more stupid excuses that people make justifying their decision not to hire more testers and not to do more testing. Happy Testing...
Its really a good Post. I got to know my friends that many of the companies not giving much importance to the testers. I used to felt bad at that time as im being a tester.
ReplyDeleteTesting is most important phase in entire software development life cycle.These days manual testing is being replaced by automated testing tools and thereby improving the accuracy.
ReplyDeletetesting automation tool
How to enjoy testing and give a defect free product.
ReplyDeleteRecently our team figured out that we are able to produce more and more bugs and simultaneously enjoying what we do. So do you wanna know how ? Here we go!
We started to have competitions on who would log most number of defects. Initially my teammates were really uncomfortable to log very minor defects. But i constantly told my teammates even though the defects are small, they are defects which would finally would be found by producers and customers( we are blamed for not finding the defects) We were team of 3 and this lead to a quality product where we were damn confident the not even a minor glitch was left behind. Recently we were assigned to individual project where only 1 QA used to test the game. Even after that we used to compare our defect count and try to find more defect. Isn't this an awesome idea :)