Showstoppers Inc(4): The Test and Quality guy

Dark humor? It's more like dark vibes that I'm getting after writing this piece.But one thing for sure, no exaggeration here. Whatever has gone into this piece is fully true to the best of my experience.But as they say, truth is not palatable. But this is the dire truth prevailing in indian software scenario. It's sweat shop where primary concern is cost. And because of this, everything else goes for a toss.

Back to the scene of an IT office. A typical IT company has two quality departments: Quality assurance and Testing. They strive for ensuring quality in the software developed in the company. The first is involved in laying out processes in order to attain maximum quality in the software developed and second one does quality checking in order to ensure that the product is defect free.

Or so it was supposed to be (and I'm back). Because quality assurance is clueless on how to improve the quality and after all the testing efforts, the product goes out to the market with some glaring defects, the ones that the customer sees with their eyes closed. Again, these are no exaggerations, only raw fact. You will come to know that there is a quality assurance department only when it's time for quality audit, which happens almost once in a year. For the rest of the time, it's only them and God who knows what they do. There will be occasional PPTs (Power point presentations) regarding a new quality policy which never make it out of the PPTs.

Now let me tell you about the implementation of the quality policies.The aim of the quality department is to bring out standard and best practices to be followed in the company. Which means regardless of the project requirements, these policies will be imposed on you. Believe me when I say no two IT projects are same. So when those standardised policies are forced, it's either the quality or the project that survives.


Testing is no better. But at least it is practical. Testing tries to find errors in the product either testing the product manually or with the help of automated tests. Till this, everything is fine. Problem comes when the knowledge of the testing guys about the working of the software is limited. Since every aspect of development cannot be documented as an easy reference basis (Design docs are an average 100 pages), figuring out the correct behavior of software is a problem. Consulting the developer is not encouraged after a certaiin number of times. This leaves the tester on his own device to find out the correct behavior and wrong behavior. This leaves a lot of room for slippages of bugs which ultimately lands up in the customer's desk.

Heck, I started out talking about the characters and now I'm talking about the departments. Maybe the departments shape the way the characters behave. Each department have been endowed with some tools which are extensively by the characters. A tester will always see every problem as a bug, for the quality assurance guy, adding one more level of approval is the panacea for everything the developers will always complain about insufficient inputs.

Well, it's like this only. This brings to an end to the series. Hope this will help you dealing with an IT guy next time you meet one.

Thanks and bye