Use ATDD agile development requirements on any project

Want to improve your project results without boiling the ocean?

At Equinox IT we are not zealots for any one particular software development methodology. Instead we take a very pragmatic approach, using various agile, lean and design thinking practices that work for us, and we continuously evolve these based on what we learn through each iteration.

Start small, start today

What we have found is that there are a number of agile and lean practices that you can use of any type of project. You don’t need to become an agile evangelist, undertake a significant change initiative and get management buy-in to start making improvements to your current projects. You can simply start today by trying a practice or two that you think will help you to achieve better results. We refer to this as agile with a little ‘a’ – the pragmatic use of agile development practices where it makes sense to do so.

ATDD is not as scary as it sounds

One practice that we are particularly fond of is Acceptance Test Driven Development (ATDD), which is also known as ‘specification by example’ or ‘example-driven development’. The name often throws people off, thinking it is intended for developers or technical testers. This is misleading, as the real benefit of ATDD is in minimising the likelihood of misinterpretation and ambiguous business requirements, thereby helping the project deliver more successfully to business need. As such, this practice is highly relevant for business and systems analysts and anyone else involved in software project requirements. While ATDD is an agile development practice, we believe that this practice can provide benefit for any type of project.

How your project will benefit from ATDD

With traditional requirements activities, a requirements document and specifications are written and then from this the test scripts and software code are prepared. What we find is that the requirements may not always reflect the business need. Also testers and developers may interpret the requirements in different ways as they undertake their steps. This can result in a software solution that is not matched to what is being testing, not matched to the original requirements and not matched to what the business needs.

Using ATDD a different approach would be used. As an analyst you would write the requirements in the form of an acceptance test. This leaves much less room for ambiguity between the business representative, analyst, developer and tester (who on our projects is the same person as the analyst). Each scenario is documented as an example stating the pre-conditions, action and expected result. A structured yet business readable language is used. At Equinox IT we use the language Gherkin, using the structure ‘given-when-then’ to describe the pre-conditions, action and result.

So using ATDD, an example Gherkin script could read like this:

While, this is example is for a calculation, ATDD can also be applied to non-calculation requirements. The structured human language script can be validated with business representatives. It then forms both the documentation of requirements and test specifications. Testing of these scripts can be automated and used to confirm that the software works as expected. Ultimately, we find that the software solution delivered is much more consistent with the business need when compared to traditional software project requirements approaches.

Then continuously improve

Whatever type of project you are working on we encourage you to give ATDD a go to help deliver working software that meets the business need. As you get better at this you may find other agile, lean or design thinking practices that can help you continuously improve your project results. If you would like any advice on this, please get in touch.