Getting Value from the Quality Department (Part 2)

In this post I want to discuss the problem about Quality terminology and how it is chronically abused in the IT industry and in software development in particular.

Somehow in software development, the term quality is now generally taken to mean testing, and worse still it is often limited to testing after the event. In other words, once the code has been written and integrated, a group of people run a batch of test scripts using an automated tool and look for problems.

Without wanting to belittle the role of the testing team, this is not quality or quality assurance. This is testing, and it is a part of the software development lifecycle just like analysis, design and build phases. Any book on Software Engineering will explain this. Nowhere is it written that quality equals testing. You don't test for quality, you build quality into the system and you build an organisation based on quality principles. Once you move away from those central tenets you may as well pack up and go home. But look through the job adverts on any recruitment page and you will find positions such as Quality Engineer, Quality Assurance Manager, and in ninety percent of cases the associated job description talks about testing; developing test scripts, using testing tools, and more often than not having ISEB qualifications.

At my girlfriend's former place of work they even used to run testing bootcamps for graduates, which turned non-IT graduates into certified testers in four weeks. In my opinion, any organisation that works in such a fashion is certifiable itself.

If you read the ISO 9000 set of standards, which despite its faults, is still a reasonable place to start in a discussion about quality, you'll read about Quality Management which incorporates Planning, Control, Assurance, and Improvement. You really have to dig quite deep into the standards before you get to any serious mention of testing, and by that time you should have worked out that it is one of set of tools available to an organisation, along with reviews, audits, inspections, and other verification and validation methods.

Which brings me onto the subject of audits. I've worked in a number of organisations where the quality team only performs audits. Armed with nothing more than a checklist and set of pre-prepared questions, the person doing the audit goes into the project and runs through the questions, ticking the boxes. I use the phrase 'person doing the audit' advisedly. These are not necessarily trained auditors. Even those that are, often appear to have little understanding of the domain, whether it is project management or even software development.

Often the people assigned to the quality team are those with least experience of anything - it used to be common practice to place graduates and new starts into the quality team to keep them out of the way. Nowadays the quality team simply doesn't exist because it's just been made redundant to save costs.

The point is that audits performed by people without the necessary training, understanding and experience of the problem domain cannot add value to the process. We'll cover this in more depth in a future post but an organisation that relies on this type of audit, to identify problems after the event is unlikely to add any value to the organisation, and by that account, sets itself up to fail. A Quality Manager in this position deserves to be looking for a new role.

At the heart of these issues is the failure of the organisation to really address what it is trying to achieve. If the organisation sets itself objectives it needs to consider how to achieve those objectives, and it's very rare for one activity to work in isolation. Different methods and techniques (and tools where appropriate) need to be considered, and each needs to be evaluated from a value and cost benefit perspective. This is where the Planning element of Quality Management fits it. It's not enough to create a Test Plan or an Audit Schedule. A Quality Plan needs to align to organisational / programme / project objectives and customer requirements and it needs thought and expertise.

My challenge to today's quality teams is to put themselves back in the forefront of organisational operations and be counted as people who make a real difference by adding extraordinary value to the organisation and not restrict themselves to one dimensional entities who only do one thing, and don't even do that very well.



Print this post