Wednesday, June 4, 2014

ATDD: is it only for agile?

For some reason I have lately been involved in a lot more discussions about ATDD than normal. One in particular set me off and resulted in this blog. Over the last few years I have been a big advocate of ATDD. Up until recently all of my discussions have been in the context of an agile environment. Given the nature of agile and the Red-Green-Clean attitude you would think that ATDD would be a logical evolutionary step. WRONG!! But I still press the discussion and eventually even developers realize the value of writing Acceptance and Integration tests first.

On a recent assignment I was place on a waterfall project. Having come from 3 years of agile projects it was quite a culture shock for me. More so than I ever thought it would be. In the midst of all this chaos I decided to do the unthinkable in a waterfall project: talk with the developers. Specifically, I showed them my gherkin scripts and asked for their input. Much to everyone's surprise, they worked with me to refine and clarify a few steps. I also did this with the Analyst; who was also open to working with me. I never got everyone in the same room, but did get everyone at least in the same chapter of the book, and even occasionally on the same page.

So this got me thinking: can you do ATDD in a waterfall environment? Fortunately for my sanity my life back in the waterfall world was short-lived. Unfortunately, I didn't get an opportunity to fully flush out and test my hypothesis. But I have put a lot of thought into this and believe beyond any doubt that the answer is YES!! You can do ATDD in a waterfall environment with, surprisingly, little change to the process.

The V-Model below shows a typical, traditional waterfall development cycle. It all starts with the business need which (should) generate a series of Acceptance Test scripts. Making this work for ATDD is simple: involved the team in creating & reviewing these scripts so everyone knows what to shoot for. Using an agile term, these Acceptance Tests become the teams definition of "done".
With Acceptance Tests now in place the Analysts and Testers can work together to create the System Tests based primarily on the Acceptance Tests. These tests become your teams Requirements documentation. Developers and Testers can use the System Test as the basis for the Integration Test layer (the new Design documentation) what becomes the basis for the Unit Tests.

If this seems like a leap (getting rid of the Requirements and Design documents) you can still write them. Just base the Requirements Doc off the Acceptance Tests and base the Design Doc off the System Tests. My argument against writing these documents is waste. Much (if not all) of what is detailed in these documents is already detailed in the scripts. After all, the Analysts helped create the Acceptance and System Tests and the developers helped create the Acceptance and Integration tests.

At this point the developers have a VERY precise idea of what they need to build as they have been involved or reviewed the entire testing stack. As code is written they know specifically which test(s) it will make pass. If the code does not contribute to moving a test toward GREEN, don't write it. As code gets migrated up through the various environments, tests will be executed and (hopefully) passed in very rapid succession. After all, the developer knew what the tests were ahead of time.

While this process might take longer to get down to writing the actual code, test execution should be extremely fast. In agile shops where I have implemented ATDD into a CI environment, the full stack of automated tests for the specific change are executed upon code check-in. And almost always pass. If most of your testing is manual, it should still go relatively quick because your 1st pass rate should be extremely high. This will enable you to get though a large percentage of your tests in a short amount of time.

The best way I can summarize ATDD is a professor. Which professor would you rather have: The one who gives you 12 weeks of lectures then a test at the end of the class? Or the professor who gives you the final exam on Day 1, then 12 weeks of lectures then the final exam? I'm taking the later and if I get anything less than a 100% on the final exam, shame on me.

No comments:

Post a Comment