Qaulity Assurance- do we need it?

For me QA has always been confusing at best. QA scope can include any of the following activities:

          • Testing
          • Code review
          • Document review
          • Process improvement
          • Process appraisal and auditing
          • Implementing engineering quality practices (e.g. TDD or Continuous Integration)
          • Producing documents
          • ISO or CMMI compliance
          • Coordination
          • Bug tracking

I am not deemphasize the importance of any of the above points. What I believe in is that they should be ingrained in the team work. To have high return, QA activities should have technical elements which require skilled professionals.

In the world of Agile development, QA activities should be embedded within the project framework and enforced by everyone. In traditional development we usually have a separate group for QA. This separation was coined by Watts Humphrey as “Ivory Tower” in his classic A discipline for software engineering. Watts has advocated that quality activities are best implemented by the engineers and practitioners instead of a separate group. Quality is the responsibility of everyone.

When I use visual board, especially which involve multiple departments, I always found that QA is a bottleneck. QA becomes a required stamp for pushing the software out rather than a value add activity. Moreover, it creates lower sense of ownership on the product quality as engineers tend to leave issues for QA to discover.

What about if we eliminated the QA altogether? We just tell practitioners that they are responsible on the product quality. QA activities are ingrained in the Agile development framework. Practitioners should agree with the project manager on the Definition of Done (DoD) that commensurate their effort with the required quality level. Instead of being a separate stage on the board, QA activities exist at every stage. Every stage has its own required skill set and the people who work in this stage know how to improve the quality of their own deliverables.

For example:

Systems analyst: prepares acceptance test cases up-front and gives it to the developers. This activity by itself can have major impact on quality which can far exceed any down stream QA activities.

Designer: use design patterns which can have dramatic impact on quality.

The previous quality activities can only come from empowered people who are motivated and not expecting a downstream stage to take care of the quality of their own work.

Empowering every stage is at the heart of self-organization for the overall team. For example, an experienced developer might assist developers in code review. A business analyst would speak-up when requirements change occur and be proactive in making decisions.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s