Lately I’ve been reading about some new methodologies that claim QA resources should be reduced to a minimum.
These so called “advanced” methodologies, mainly related to Web 2.0, argue that although QA is a “necessary evil,” reducing it will allow the development process to be shorter and more dynamic and flexible, giving companies greater strength in the market.
IMHO these progressive approaches have progressed a bit too much. It seems to me they do not take into consideration all the risks involved in such an act.
They do present one proposed solution – developers should become more responsible for their code. They should strive to write without bugs and perform the minimal necessary tests by themselves.
This solution totally contradicts the main purpose of this approach – flexibility, dynamics and quickness – it will take a developer twice as much time to develop a new feature if he tries to fulfill the above tasks, and the development process will become even more complicated and slower as a result.
Although no one knows the feature better than the person who wrote it, a QA person is a trained professional and will be able to produce twice the productivity in half the time.
Our basic assumption is that not all bugs will be found. Therefore QA’s goal is to find as many bugs as possible in a designated time and make sure every bug gets the proper attention.
But as you reduce the QA effort, more and more critical bugs will slip through and find their way into the production site. Those bugs will never go away. They are only hiding, lurking somewhere in the system waiting for the first customer to find them. Such bugs have a tendency to reveal themselves at the worst place and always at the worst time.
Critical bugs need to be fixed at any stage, and it is a known fact that the later you find the bug, the more painful and expensive it will be to fix it.
My experience has shown me that whatever you save in QA you will pay in tech support, and big time. The equation is simple – the less QA you have, the more tech support you will need, and as a QA & tech support manager, I can see both sides of the equation very clearly.
Shorter QA time and effort will enable end users to enjoy a more dynamic and enhanced application BUT … a customer will always be less frustrated by an absent feature than by one that doesn’t work.
In conclusion, no matter how much QA time and effort you invest, you will always need tech support. But our main goal is to find the magic formulas that enable us to balance the equation between the two.