Test-Driven Development: Quintessentially Agile

Of the Agile Testing methods discussed so far, one seems to explore the limits of what Agile is supposed to be: Test-Driven Development (TDD). While some organizations may struggle with the concept of this “backwards” methodology, this approach does deliver one of the most collaborative and efficient product development processes possible.

With Waterfall, there are typically long delays and potential misunderstandings when writing a test against a  requirement defined many weeks previously. In TDD, you write the code to match the test, were the test (rather than the requirement) is the driving documentation created  in advance. Look at it this way: a product owner may be able to define a requirement individually, but in reality,only about 80% of the functionality has been captured. However, involving developers, testers, and other team members up front will provide necessary collaboration to drive more complete definition of the requirement.With TDD, the typical first step is to design and write an automated test (although in some cases it will be manual). Once the test has been completed, the developer is tasked to keep writing code against the test until it  passes. These automated (in some cases manual) tests continue to run as developers rework the code. AS soon as the  test passes , the code is refined further until it’s as streamlined and efficient as possible. Through this method, you’re eliminating the steps of writing a requirement, developing code, then writing a test, then running a manual test and finally automated test.  By starting with the automated test, you’re skipping all the previous steps, cutting documentation to approximately a third of what it was previously.

Collaboration is Key

With the TDD method, a large amount of collaboration is required at the beginning of the process.  Many of the waterfall “layers” that allow organizations to perform less than perfect requirements gathering are removed in this process, forcing teams to be extremely accurate up front.

For most teams, this additional effort needed to front end the process is worth it. With waterfall, faith and trust are put in the product owners and business analysts to understand the customers. This person writes a requirement, and then the developers and testers must interpret the requirement. With TDD, product owner, developers, testers and the entire team work together to develop the test that will drive product development. This puts them all closer to the real needs of the customer. Another benefit is more voices to provide honest feedback to the customer on whether the requested feature is workable and practical.

Though there are many potential benefits of aligning with TDD, it  is not for everyone. With a typical sprint of three weeks, there is not time for the usual layers of approval present in a larger organization. You will not find a strict, dedicated hierarchy in TDD teams, making it difficult to scale up and down quickly. Also, since automated test are written with the expectation of many failures in the beginning of the sprint, tracking and reporting results can also become a challenge.

But for firms that are nimble, or want to become nimble, the hardwired agility built into a TDD approach is often too attractive to ignore.

Leave a Reply

Your email address will not be published. Required fields are marked *

More Great Content

Get Started with qTest