In a previous post entitled “Agile testing: what it’s not“, I attempted to define how testing has been traditionally done; with the stage set as the status quo, my definition of agile testing hopefully will make a lot more sense. In the winter of 2001, a group of hip industry visionaries came together in an effort to codify various lightweight development techniques, which had, for the large part, sprung out of a collective frustration over the high rate of project failures which have plagued the software industry for years. In essence, these perceptive individuals knew there was a better way of doing things and they captured the succinctness of what has become Agile in what’s known as the Manifesto for Agile Software Development, which explicitly values: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan The Manifesto doesn’t discount aspects such as documentation, plans, or tools (in fact, the authors admit these have value); it simply states that collaboration and responding to change, for instance, are more important in the overall pursuit of project success. In many cases, organizations can see a direct link between these principles and software development; however, the link to software testing is often viewed (incorrectly) as tenuous. By examining the manifesto’s tenets closely, one can begin to discern that they are broad enough to fit all categories and phases one can divide the software life-cycle into. In fact, for those practitioners that have embraced Agile and successfully employed it throughout a software life-cycle have found, Agile testing boils down to two fundamental changes that differentiate it from traditional software testing. Those two facets are: software testing is no longer a phase — it is part of the life-cycle — in fact, in a broad sense, both testing and development combine into what is largely known as Test Driven Development everyone works collaboratively as one team rather than separate groups responsible for various aspects (i.e. everyone is accountable for quality) Thus, while the goal of software testing remains the same, the manner at which it is achieved changes slightly in favor of a more adaptive approach that seeks to keep all parties informed and responsible.You can now follow The Disco Blog on Twitter, baby! Software Development