Engage Quality Assurance

In a recent project there was a lot of discussion how to introduce Quality Assurance (QA) into an "agile" project. One key learning from the sprint retrospectives was that more formalism and more "process" would be required to achieve the desired quality of the product. The challenge was to find the right balance between needed formalism and unwanted organizational overhead and bureaucracy on one side and responsibility of each individual and non-effective & proven not-to-work selforganized QA by the development team itself on the other side.

Many discussions were going on with the customer and within the team and I was lucky to read a book by Coplien/Harrison (Organizational Patterns of Agile Software Development) by that time that brought my personal opinion to the point.

I would like to share the core statement with some personal additions and remarks here:

The engagement of the customer, requirements engineering and development is the key element of QA!

Developers might feel that they got everything right, but "a good dose of customer reality" can help them to bring the perspective that development of 100% perfect software is impossible.
It happens too often that organizations defer quality until "later" or make the mistake to equate QA with testing, which occurs later in the development process. The production of high quality work and early feedback is key to address fundamental quality problems and finalize a project successfully.

Remember: QA is not equal to Testing!

It is very important that developers perform their own testing but it is also a fact that they get blindsided very often by their own design thinking in terms of what needs to be tested. Further, they may use testing as their quality criterion. In contrast to the ideals of XP, test development shouldn't be blindsided by the developer perspective and QA needs to be seperated and independent in the interest of objectivity.

Remember: You can't test quality into a product - you can only build a product and test its quality!

QA needs to be established as a central role and needs to be legitimized by the organization. QA organization should be outside the context of development but needs to be tightly coupled with development as soon as development has something to test. The test plan creation can be done in parallel with the coding.
The planning and reporting of tests should not be accountable to the development organization. The sense of accountability for the development organization is to deliver a quality product that is free of bugs (minimized the bugs) that an QA organization might find.

Remember: Developers declare the system to be ready for testing!

QA needs to work closely together with architecture and requirements engineering as well in order to understand the needs and challenges the system will face in future. The QA people need to have the skills and the experience to "look behind" the things expressed explicitly in requirements/needs and specification documents and identify the core of the needs/pains and requirements and make sure that this is reflected in the system.

Remember: QA should be engaged early in the project. The system of quality is prevention, not appraisal!

In order for a separate QA to be effective, it must have frequent and positive interaction with develoment. It is not just the developers' responsibility to engage the testers - but the testers must reach out the developers as well.

Remember: Quality is free ... :-)

Yours,
Wolfgang