As a test professional in waterfall, I was used to getting the code much later and buggier than I expected and being under tremendous pressure to finish my testing before the go-live date hit. Then one day, I found out that there was a better way. Testers could be involved much earlier in the lifecycle, they could participate in requirements and design decisions as they happened, and the code could actually be unit tested before I received it! Heaven? Nope, agile.

The author walks you through the details of actually implementing a continuous quality automation infrastructure. He builds up an example that addresses both the key principles and feedback cycles.

I begin this story by declaring up front that I am not an "Agilist" or process evangelist. I am the senior software development executive in a company responsible for delivering products to the marketplace. Like my peers across industries, I am fundamentally held accountable by my company for consistently delivering business results. Process and methodologies are important in delivering this value, but in the eyes of the company they are secondary to meeting the needs of the business.

Agile is a methodology that is seeing increasingly widespread adoption, and it is easy to understand why - especially if you consider the developer and user view-points. But, for the Test/QA professional an agile approach causes discomfort - In the ideal world they would have a ‘finished' product to verify against a finished specification. To be asked to validate a moving target against a changing backdrop is counterintuitive. It means that the use of technology and automation are much more difficult, and it requires a new approach to testing, in the same way that it does for the users and the developers.