Because it’s my bag, I’ve been asked on more than one occasion the question: “what is agile testing?” — that is, what does Agile mean to traditional QA teams? Usually, the person asking the question is looking for a one word answer; however, it isn’t that easy. While I will answer the question over the course of a few posts, perhaps before describing what agile testing means, it might help to define what traditional software testing is. By doing so, the comparison unveils rather stark, yet quite exciting differences. The comparison also maps a path that leads to a greater understanding of how agile testing both addresses the challenges of software testing and complements a highly efficient software development life-cycle.Software testing, in the traditional sense of the phrase, is usually a phase towards the latter cycle of product development; that is, it happens somewhere before product delivery and after the development team finishes writing code. In fact, in many cases, traditional software testing is last check that “ensures a product is ready for delivery” (i.e. that the code is of high quality, has few to no defects, is ready for customer interactions, etc). Yet, as anyone who has ever lived through this process knows it’s impossible to imbue quality into something that’s already been built (that is, quality is something that’s built in, man) the longer the development cycle lasts, the harder it is to fully test the finished product (that is, at some point the time required to fully test a software application exceeds the expectations for delivery) the cost of going through the “find and fix the bug” cycle is by this time increasing by the day (i.e it is a well known facet of software development that the cost to address a bug increases at a tremendous rate the longer it resides in software) Plus, this last step before going live often becomes a veritable gate (sometimes even referred to as the “quality gate”), which frequently pits two competing expectations (and their respective organizations) against each other. On one side, development is motivated to push their product live and QA is motivated to fix issues before pushing the product live (which means more work for development!). Thus, one side is appearing to push one way and the other side is appearing to push the other way. In many cases, this competing interest yields walls that unfortunately act as a barrier to efficiencies, which then pits IT against the business (who is motivated to push quality features live quickly). Now three organizations are pushing against each other! Thus, traditional software testing’s goal of providing a means to ensure high quality code is released is quite noble; however, in reality, this hip goal is quite challenging to do well in an efficient manner. You can now follow The Disco Blog on Twitter, baby! Software Development