Continuous Quality

In Part 1 of this series, I will outline how automation can provide a great platform to pull quality and testing forward when the focus of the automation is informed by a few key principles. In Part 2 of this article, I will take the concepts presented in Part 1 and walk you through the details of implementing an automation infrastructure, including specific examples.

What the Heck is Continuous Quality?

What do I mean by "continuous quality"? Quality isn't an event that happens right before a project is done or before a product ships; quality requires the continuous focus of the team. Just as continuous integration enables the continuous feedback cycle around integrating code, continuous quality enables the continuous feedback cycle about the quality of the system or product being developed. Ultimately, continuous quality is about reproducibly building integrity in at all levels of the development and testing process through the effective use of automation.

As an engineer working in an IDE, you should be continually aware of how your code integrations are affecting quality. As a tester, you should have a say in the definition of done, visibility into the quality of the stories under development, and control over your testing environment. As a product manager, you should be able to understand and provide feedback, in short cycles, about how a customer will perceive the value and quality of the stories being developed. Finally as a team, you should have constant and objective feedback about how quality is trending with the ability to "Stop the Line."

Principle #1 - Agile's Discipline Around Short, Time-Boxed Development

In waterfall development, the goal of the testing phase is for quality to "come together" at the end of development, where I would argue it is much too late to materially affect quality. Also, there is typically little focus paid to the deployment or installation work until development is finished. Focusing on quality at the end of the development cycle puts the team in a position where fixing any issue often requires reconstructing the context around code that changed months ago. The problem is that at this point, everything is out of context. It's like asking what youhad for lunch three Tuesdays ago. Do you remember?

The short time boxes of Agile development (where small increments of work are taken from definition through acceptance) enable testing to be pulled forward. Because the feedback cycles between development and acceptance are compressed, issues are discovered and resolved while the code changes are still in context. Do you remember what you had for lunch today? I hope so. Involving testers in development from definition to acceptance is a start, but there are ways to make the feedback cycles even shorter through automation. Short time boxes AND automation help pull testing forward to the point where quality is continuously understood and acted upon.

Principle #2 - Feedback Cycles and Lean Thinking

Now let's take a look at Lean thinking to understand feedback cycles and how to compress them. According to Mary and Tom Poppendieck, improving cycle times involves limiting work to capacity, evening out the arrival of work, minimizing the number of things-in-process, minimizing the size of things-in-process, establishing a regular cadence, and using pull scheduling [1]. The basic cycle of development is captured in the picture below.

In this cycle, testers and product owners specify functionality, developers write code to implement that functionality, and the code gets checked into the source control management system. At some point in the cycle, those code changes are incorporated into a build. Testers and product owners use this