Continuous Quality

the deployment part of development now becomes part of the feedback cycle, and the team gets feedback when a code change breaks the packaging or deployment of the build artifacts. Before this level of automation, the ability to deploy or install a build is unknown until someone manually makes an attempt. If something goes wrong, the code responsible for the problems is likely to be out of the team's context. If the feedback comes as a direct result of a specific check-in it is easy to understand what is causing the problem and decreasing quality. The feedback from automated functional testing can help a team limit work to capacity, even out the arrival of work, minimize the number of things-in-process, minimize the size of things-in-process, and establish a regular testing cadence.

Manual GUI and Regression Testing

The next area to focus your automation effort is the infrastructure to allow testers to pull builds for manual GUI and regression testing. This is the part that allows testers and product owners to be completely in control of their testing environment. In teams that lack this level of automation, a tester or product owner typically has to ask someone in development or operations to make a build available, which can be a slow and contentious process that is frustrating and distracting to all involved. To implement this level of automation, you'll need a repository of build artifacts, and a way to deploy or install from that repository. The remaining areas of batching are removed with this level of automation.

{C}

With this level of automation, there is no batching in the feedback cycle and, more importantly, the team can move to pull-based scheduling for testing. Pull scheduling empowers each person to clearly understand what he or she should do next to have the biggest positive impact on the business and have the ability to act on that understanding[2].As functionality is being developed, testers and product owners are in control of determining, with developers, what build would be most effective to test and get quality feedback to the team.

In Part 1 of this series, I outlined how automation and Lean principles reduce cycle times in a way that allows quality and testing to be pulled forward. In Part 2 of this article, I will take these concepts and walk you through the details of implementing an automation infrastructure, including specific examples.

About the Author

Zach Nies brings close to 20 years of engineering and product development experience to Rally's innovative products. Prior to joining Rally, Zach served as Principal Architect and Director of Systems Architecture for Level 3 Communications and founded a small start up which was quickly acquired by the publicly traded Creo, Inc, now a division of Kodak. He also served as Chief Software Architect at Quark, where he provided the overarching technological vision for the company. Zach's product vision has won numerous industry awards, including Jolt Product Excellence awards, Seybold HotPicks and the prized MacWorld Best of Show. Zach has served on standards bodies such as the W3C's HTML working group and currently serves on the board of directors for Agile Denver. At the age of 13, Zach began commercially publishing software and, at age 16, started a successful consulting business. A Boettcher Scholar, Zach received his BS with distinction in Computer Science Engineering from the University of Colorado at Boulder. He spends his spare time tuning his golf swing and spending time with his family.

[1] Poppendieck, Mary and Tom. "Managing the Pipeline." Poppendieck.LLC. 7 Oct 2007. http://www.poppendieck.com/pipeline.htm.

[2] Poppendieck, Mary and Tom. Lean Software Development,