What s Wrong with This Picture?

What's Wrong with This Picture?

Before anyone gets offended, I want to say that I have found myself on both sides of this debate. What people perceive to be wrong with this picture will depend largely on the type of development process they are following. In a carefully planned and controlled development effort, quality assurance would win and the innovation would be held up until it could be fit into the schedule. In a RAD/Agile shop, a dynamic creative process will not be stifled simply because it is difficult and inconvenient to update paper documentation. In a RAD/Agile shop, the innovation would most likely be put in place as quickly as it is available, and the quality assurance procedure that cannot keep up with technology and innovation is likely to be discarded.

For the past several years, I have hosted special collaborative Web sites that provide features such as single-source documentation, proactive notification to subscribers of changes, interactive discussions and live chats, task lists, and schedules with automatic reminders and notifications. I have trained several teams on how to use these Web sites to minimize the problems described here and to mediate disagreements. However, even after training, these same problems persist, even when updates are instant and notification is automatic. These problems are caused by our culture, and culture is difficult to change. Even though the technology exists to solve the problem, or at least improve the situation, it will not succeed unless the culture can be changed.

To determine how to achieve and maintain proper quality assurance, now and in the future, we need to evaluate what's lacking in the current quality assurance environment. The following section looks at some common, faulty perceptions of what quality assurance is and then examines six faulty assumptions of what quality is and how it should be measured with respect to software systems.