As I elaborated in two previous hip posts entitled “Agile testing: what it’s not” and “Agile testing: what it is” agile testing boils down to two fundamental aspects — it’s about a whole life-cycle and whole team approach to testing. Note that the whole life-cycle gig is distinctly different than traditional processes, which often label a timeframe dedicated to testing (almost always after coding is “finished”). Rather than wait until the end of some period to begin testing, in an agile influenced testing organization, testing is done throughout a life-cycle. Interestingly, the asset that both facilitates collaboration and increases testing productivity is the story. A copasetic story both captures a feature (or requirement) and provides a means for validation; plus, stories are, by their nature, quite easy to collaborate on. In fact, rather than breaking into different groups to diligently define requirements documents, design documents, and test strategies, teams that instead focus on collaboratively authoring stories often times find a much more streamlined approach that lessens the inevitable impedance mismatch that occurs when different groups leverage different mediums (or documents).In a broad sense, the approach of collaboratively leveraging stories to both define features and verify them can be seen as Test Driven Development. Indeed, depending on your view point, Test Driven Development (or TDD) can be seen as a developmental practice focused on unit testing; however, broadly defined it captures the mantra of agile testing — that is, the story defines both the feature and a means to test the feature. Whether that feature is tested via a unit test or a hip functional test doesn’t matter, man — the point being is that all parties are leveraging the same asset to drive the test. And best yet, the test itself is defined in language that customer can understand and indeed define if they choose to. Because testing becomes a whole life cycle approach, a fundamental shift occurs with respect to test assets. As opposed to traditional processes where assets differ in implementation, definition and even storage, in an agile testing environment, all tests are assets defined collaboratively and stored along with source code. That is, functional tests are living assets that are managed and versioned just like code. This process has a secondary benefit — QA becomes involved in what’s known as Continuous Integration. Briefly, Continuous Integration (or CI) is the process of continuously verifying software assets. By doing so, defects can be found early — where they are considerably less expensive to address. Thus, CI provides a means to shorten the feedback loop and permits teams to find and fix issues as they arise, which is fundamentally different to finding and fixing defects after a long coding process.What’s more, in order for QA to effectively leverage CI, automation is a must. That is, CI is an automatic process that doesn’t rely on human interaction; thus, for QA assets to be exercised along side of developmental assets, automation must be utilized. While teams will often inquire as to how much automation must be leveraged, there isn’t a hard and fast number; suffice to say, it’s healthy to grow automation assets over time. There will always be some level of manual tests — whether they be exploratory in nature or simple human verifications (things look correct) but the more automation leveraged, the better. Thus, embracing a whole life-cycle approach means embracing stories as a means to clearly enunciate features and how to verify them treating test assets like code assets through SCM CI automation at all levels and granularity The whole life-cycle approach which stresses stories, CI, TDD, and automation has a number of benefits including: lowering the overall cost of addressing defects because they are found quicker imbuing a stronger sense team camaraderie because QA collaborates with development and stakeholders closely and assets are shared across boundaries, baby Agile testing’s whole-life cycle approach tends to break down traditional barriers that inhibit efficiencies and ultimately leads to better software quicker. Can you dig it, baby?You can now follow The Disco Blog on Twitter, baby! Software Development