Testing in Agile: The Heart of Quality

What is quality?

I wonder what you are thinking right now. Is quality about testing? Conformance to requirements? Customer satisfaction? Number of bugs? Number of test cases? That feeling deep inside when you recognize work well done? Or maybe that other feeling when you are bracing for disaster, knowing you didn't have enough time to do things right?

A number of definitions exists. Some say quality is conformance to requirements and is measured in the number of rejects from customers (ISO 9000). But do we really always know the exact requirements down to the very last detail, scenario and behavior in all circumstances? And even if somebody tried to document every single requirement, how do we know they are right? Working on wrong requirements might build 100% conformance, but will never create great quality.

In manufacturing quality means uniformity, but we create software and software is not about uniformity, it's about variance. Unlike manufacturing, we are dealing with an endless variety of use cases, inputs, settings, permissions, platforms and operating systems. Software is a living organism that behaves differently at different times during the day, depending on number of users and background processes.

Some people think quality is a degree of customer's satisfaction. ISO 8402:1994 says it's "the totality of characteristics of an entity that bear on its ability to satisfy stated and implied need". In Agile world however, the stated needs might change pretty fast and as for the "implied" needs... God knows what they are and who's in a position to make a guess. Remember when Microsoft bought LinkedIn and changed the site's look and feel? The users were outraged, their needs were ignored or misunderstood and the activity plummeted.

And yet others say quality is a measure of performance. If you compare two products over time you'll notice differences in speed, reliability and durability. But how do you set goals and how do you measure these things before the product is shipped?

Yes, it's hard to give quality a definition. Probably all of them are correct and quality is really about conformance, satisfaction and performance. But which is the most important characteristic of Quality?

What is the heart of Quality?

If you ask me, I think quality is about knowledge. It's all about two simple questions, or rather, the answers.

Sounds simple? Yes.

But think again. In a complex software product the number of workflows and their combinations is endless. Different users expect different behavior. Product performance depends on infinite combinations of data, load and volume. Is it possible to know every scenario, predict product behavior and test it to confirm the hypothesis?

But here's the thing. In the heart of Quality lies Knowledge. And the road to it goes through Learning. A great Quality Engineer knows and understands the product to a point where they know how it should behave in a multitude of scenarios and situations. They can identify with the user and know what's best for them. And they also know how to put the product to a test. How to run it through a limited number of use cases to reveal its true nature. How to question the requirements and make sure they are right. Understand stated and implied expectations. Measure conformance and performance.

Most importantly, they can learn their product and make it learnable for others.

Please like and share with your network! Comment, share your thoughts and send me your questions, follow me on LinkedIn and Twitter to read my articles on practical Agile.

My other posts in "Testing in Agile" series:

• Testing in Agile: A Quick Tutorial on Defects, Bugs and Everything in Between
• Is Manual Testing Primitive?
• Testing in Agile: Never Again Say "Deadline"
• Testing in Agile: The End of QA as We Know It
• Testing in Agile: The Sprint Is Too Short!