Intensity and Accountability

Most software development shops view the development team as entirely separate from the QA team. Hence you have sayings such as "throw [your code] over the wall" and "hand it off to QA". These teams are frequently managed by two entirely different people or departments. There are many consequences to this, a few of which I'll mention ...

• An adversarial relationship, of varying degrees, is created between dev and QA.
• The dev team views the delivery of their code to QA as the completion of their responsibility, and subsequently go into reaction mode with all their actions driven by unplanned and unexpected directives from QA (which means the dev team's pre-release "intensity" is often too low for management's taste).
• The process defined for handing off code to QA is usually either inadequate, or excessively bloated, if any process is described at all.
• The responsibility for actually getting code deployed bubbles up to the lowest level under which both dev and QA (as well as configuration management, deployment, support, etc.) are managed. As is true of all general staff structure organizations, bubbling the responsibility of making front-line decisions to a higher authority increases risk and decreases efficiency.

When this situation occurred in one of my recent contracts, I recommended that the developers retain ownership of their code until the final phase prior to release. The DBAs responsible for reviewing data model and stored procedure changes, as well as the QA department itself, become tools the developer uses in order to get his code delivered. This has quite a number of consequences, many of which are subtle or psychological in nature. A few of them are:

• A single, front-line individual is responsible for the entire effort.
• Availability of the DBAs or QA department must be planned on ahead of time, giving greater predictability and reduced risk to the process.
• The developers will initially be "cracking the whip" over the assigned tester in an annoying and distracting manner. Therefore, the QA department will be forced to design process and procedure that is practically defensive in nature, rather than whimsically idealistic.
• Since QA is just a tool for the developer to use, no longer a separate department, the developer is more likely to monitor, actively participate in, and facilitate the testing process. No more surprise demands.
• Since someone who is focused on task is less able to evaluate the overall set of tasks being performed, the close association of the developer with the assigned tester will provide a "super-ego" to the process, who is more likely to evaluate the overall process and identify risk (as opposed to QA telling the project manager the night before the release that they still have 50% of the project to test).
• The change in situation also has psychological implications on the team with regard to responsibility, focus, pressure, etc. that I consider desirable.

The company is in the process of making the change along the lines I suggested, so I'll let you know how it works out. So far, everyone up and down the management chain (including the testers themselves) finds the idea appealing.