Quality assurance is too often used to just identify a lack of quality and to find deviations from the norm. This is logical in organizational cultures where responsibility is something to be managed carefully. However, wouldn't it be better if QA would be supportive towards an overall strategic goal of improving quality? For this you need a sense of shared responsibility across the organization and its processes. Then QA can work to start improving quality by improving processes, procedures and practices, making sure to prevent problems instead of identifying them. Taking responsibility instead of shifting it. That's proactive QA.

We all have our examples of exciting projects turned into nightmares. Creeping deadlines, tsunamis of defects, applications that fail to deploy or performance bottlenecks that just cannot be found. And always do these kind of situations occur at times when they are least welcome. Right before the project deadline, during the holiday season or when you had planned that nice weekend getaway.

A lot of effort is put into testing and verifying applications these days. A number of formal testing methodologies have been formulated. A Dutch product for instance is TMAP. Sure it makes sense to define how you wish to approach your testing. However, one of my major gripes with approaches like that is they are very formal. And in the case of TMAP it approaches software development as a staged, waterfall process. In this process the testing department is a divine institution, detached from reality, whose prime purpose is to uncover defects in the product of 'the others'.

In my opinion this approach is exemplary for a lot of testing departments out there. They are missing the point, two points actually. The first is that they do not acknowledge that testing must be part of the overall QA effort in an organization, not an isolated activity. On any project and any organization that takes software development seriously, a vision on how to approach the matter of QA is necessary. Testing is just a part of this. Having and overall vision we can ensure the money allocated for QA is spent wisely.
The second missed point is that testing and QA can not and should not be detached from the development work. Doing so promotes a 'we vs. them' culture where there is no sense of common responsibility. Ever been on a project where the testing team was doing nine to five and the developers 24x7? Or even worse, I've seen projects where the testing team was sitting idle for months, waiting for something to test to come into their domain. What a waste!

Old school QA results in doing testing and QA detached from and after the actual creation process. All that can be done then is to discover and signal the flaws in the product. Which then need to be fixed. I call this reactive QA. There is no way QA can do anything substantial about a lack of quality, they just signal it. Others will then have to fix them. Adding another non-value adding creation stage.
The contribution of reactive QA to the overall success and quality is limited. No structural process improvement occurs as a result of it.

It would be much better if QA would be employed proactively. If QA was working in cooperation with development or production teams to improve the product. From a process perspective the role of proactive QA can be formulated as: "assisting the production and development team to improve the process while it is being executed". QA must in this scenario take an active, participatory role. QA and testing in particular cannot afford to be standing on the side observing and commenting on what is produced. Now they share in the responsibility for creating a great product.

There are two very low level examples of proactive QA that people familiar with Agile and Extreme Programming are already familiar with. Pair programming and Test Driven Design. Pair Programming is a form of QA where the QA agent sits with the programmers and together they formulate the best solution of the issues at hand. No separate code review is necessary, since two pairs of eyes are already looking at the code as it is being written.

In Test Driven Development the application development is driven by pre-formulated and often automated test. The most prominent advantages here are the automated regression test are available even before the software has been shipped. Developers tend to pay more attention to the testability of their code and a better correlation with the functional and non-functional requirements to the code is hardly imaginable.

Another example of proactive QA that is not so much tied to software development is a Process Coach. At Xebia we have a number of people working with our clients as an agile coach. They help the client's organization make the transition to working agile and to organize the people in agile teams. We have found that is of limited use and less effective to practice agile if the environment is not. Agile coaches help the people on the project to improve their way of working and their practices to become more agile and more effective.

In summary, proactive QA is a big change from conventional reactive QA. The role, competencies and responsibilities of QA people change dramatically. Implementing this can be challenging, since it requires a cultural change. The benefits are enormous. The involvement of QA in the actual creation and their contribution to in process improvement does really improve quality when it matters: before errors are made.

Filed under Agile, Project Management, Quality Assurance | 4 Comments »