I have spent a good portion of the last 15 years trying to go back to the future. For the first 15 years I worked in companies where Quality was paramount and their common approach shaped my thinking and actions. Names like Fisher Price, Parker Brothers, Eastman Kodak, Wang Word Processing, speak to the power and importance of quality. With their respective demise I also learned another important lesson about quality. It is not just about how well the product is built. It is the value the product adds to a customer’s quality of life that separates a fad from a staple. This, it turns out, is the one item I have found that moves business and management to understand the importance – to their success – of having quality at the front of the train.

The most frustrating part of QA and test for me is investing huge amounts of time and care into assuring the quality of some item that has no value. I say this not as a QA manager, or Test Manager (I have been both) but as a Developer, Engineer and stockholder. After all the core specification for anything Agile is Value. In Theory of Constraints terms, Agile QA is about what Glodratt’s calls the inspection of parts before working and ensuring it is to specification otherwise you are wasting people’s skills on refining trash.

Today, what are we doing to assure we are working on the most viable item of value we can produce? From where I sit, we seem to think that magically all things we touch must have value otherwise they could not exist in our world. What a load of hooey. Bottom line, if you are working on something that contributes nothing to the value of the product then you are wasting your own time, your company’s resources, and your customer’s faith in your product.

Let’s look at the role of QA can play within the context of the Agile Manifesto and Principles.

1. We need confidence that what we are doing has value and that we can trace that value directly to the Product Vision and the Organization’s goals.
2. We need to make sure that we do as little work as possible to produce the value in the product. This is not saying that we do a slacker’s best. To the contrary it is saying we only work on those things we have a dead certainty as to what it is we need to produce in order to have it accepted as DONE.
3. It means that we have a way to delay to the last reasonable moment those parts of the product that we are not dead certain of.
4. It means that we have a way to identify what the value is before the part enters our plans.
5. Finally it means that we have an early decision and definition of what value the part brings to making the vision a reality.

The role of QA in Agile then is to be the Product Owner’s trusted advisor on assuring the Value of the Product moves in continuity from the vision to the customer’s compliments.

So what is to happen to test? If QA has a new role in Agile, Test has a new life. If the developers are aware of what the product is supposed to do then, in small projects/products test is already a teacher and shows developers how to develop tests that automate well; it is also a mentor to the ScrumMaster and the product owner giving them confidence on the coverage of the product. Now test has the chance to assist the Product Owner in judging the doneness of a delivery. If this in place when larger projects ramp up, Test actually gets to do its job.

As the product, project, scales teams deliver acceptable components along with the automated acceptance tests used to assure the component is DONE. These become part of the regression sanity smoke tests and free up the scarce test professionals to exercise and explore the interfaces and operating parameters of the product.

Can Test now move to iterations, scrums, and fast delivery? Interesting question and the early results are encouraging. More later.