Follow on: Development vs. QA - Why disagree?

I like the bold questions raised by jason in his blog "Development vs. QA - Why disagree?". For the last half decade (especially after dot-bust), quality has gained an overwhelming visibility in the software industry and the awareness is growing day-by-day. Numberous studies have proven the exponential relationship between the life of bug and associated cost. Sustaining costs are increasing far beyond original development costs. Therefore, companies are trying to crush new bugs, as soon as they find their way into the code. And hence, the pressure is on developers to test their own code!

I don't see the testing goals between development and QA as conflicting. I see the conflict more because of differences in role, availability of test beds, and more importantly the will! Developers generally don't want to do testing - they always write the perfect code!

The QA is way too on the other side of the wall. 99% of QA teams are involved in black-box testing of features as customer sees them. So, Quality organization is always more close to the end-customer as compared to the development.

To me - both practices are inefficient. We all know that by testing in the end, QA cannot build quality in, it's the development team that needs to write a quality code to start with. I am a firm believer of TQM principles and Deming 14 points. To improve quality, all processes must be standardized, engineering principles must be put in place, and there should be tools that ease the adoption of all these processes. Processes without tools create too much work and chaos!.

The solution is to have a QE team, a team that is more close to development (report to the same director, or even the same manager!) , responsible for all the functional testing. QE team can catch bugs early in development cycle and QA team can focus only on non-functional requirements as part of the system testing.

Developers don't want to be QA!! They restrict themselves to Unit testing and some basic functional unit testing. Another complecated issue is the deployment that is generally not automated. Lack of automated deployment breaks down the Continuous Integration cycle and developers' motivation to automate post deployment test scenarios. Using tools like MockStrutsTestCase and CactusStrutsTestCase, developers have started to look into some level of pre-deployment functional unit testing (including in-container testing) - but again, that's streatching the limits of Unit testing, as jason said.

QA is black box. But there is a limit to what QA can test - with limited resources, especially time. Once feature freeze is done and all the code is checked-in, nobody wants to give QA couple of months just to make sure they can complete the test cycle. The complicated nature of software, with all the reuseable code and interdependencies, fixing one bug late in the game has a huge potential to give birth to two or more bugs (it's like the Samuel monster from Helloboy!)

Watch Watts S. Humphrey's video for more info on why testing in the end is a bad bad thing to do.

Trackback URL: Follow on: Development vs. QA - Why disagree?