Acceptance Test Driven Development (ATDD)

Article author: Dmitry Kurdyumov

Participated in Agile transformations in the largest companies in Russia (Alfa Bank, MTS, X5 retail group), with international experience in a startup abroad.

Working with product development teams, I have often seen two scenarios for writing requirements for a product under development, and both scenarios are skewed one way or the other:

1. A lot of focus in the requirements is given to the functional and technical part, that is, to describe how it will work from the technical part in the absence of an important part of the requirements about the user and his needs and scenarios. Relatively speaking, when a customer has another requirement, instead of first understanding how it will work on the part of the user, we immediately start thinking about the technical implementation and run to do it as soon as possible. This leads to the fact that at the start we miss important user scenarios and do a lot of superfluous and unnecessary things.

2. Or the flip side, when we spend too much time analyzing business requirements, creating huge tolmuts of documentation, with UML diagrams and a thorough study of everything. There is an overabundance of such requirements, so that in the end no one reads them or reads them obliquely. And it is even more difficult to change and maintain such requirements.

In this article, I want to share a lightweight approach to business requirements creation (acceptance-test driven development or ATDD) that focuses the team on users and the business and improves understanding of what we are doing. And in addition, builds quality into the development process.

ATDD is acceptance test based development. The point is that before we write code, we create acceptance scenarios so that we can already write code for them. And it is important to create them closely with the business. As a rule, the ATDD approach assumes that we get together with a business customer (or a product, which is the voice of the customer and stakeholders) and a team (including analysts, developers and testers) and model use cases together, and then write code for these scenarios . Scenarios are not written from the technical implementation side, but from the user side, to take into account important needs.

Why is it worth getting together with the whole team, including developers, testers, designers, and everyone else?

First, your team gets all the requirements from the source and better understands what needs to be done. Secondly, you need less time to explain the requirements to the team later and you will not act as a broken phone. Thirdly, the quality of the scripts and their completeness will be better, since everyone participates. And fourthly, the whole team will be able to ask interesting questions from different angles and analyze scenarios together.

Sometimes it takes weeks to develop the requirements, and another weeks to get it right to development, and then another weeks to redo it, because the context in development could be lost. Here, for such a working session, you can devote a couple of hours a week to the whole team and have the same and complete picture for the whole team.

How to do it in practice?

At the beginning, any business requirement should be formulated in the user story, that is, in the context of

  • Who will interact with the product (person)

  • What will do (action)

  • Why does he need it (goal)

Let’s say you have a user story:

I, as a user of a mobile bank, want to understand my expenses for the period in order to optimize them. Having such a user story, we in the team already better understand the context of what needs to be done and why.

And then with the help of the Given – When – Then framework, we begin to formulate acceptance tests.

  • Given – describes the state of the system at a given time.

  • When describes an action.

  • Then – what changes after the action is performed.


If I am a bank client and I have an expense for the period of X rubles.
When I make a purchase for Y rubles,
In expenses, I should see the amount of expenses for the period (day / week / month) of amounts (X; Y).

If I am a bank client and I have an expense for the period X rubles,
And, when I return a previously completed purchase for Y rubles,
In the expenses for that period, I should see the amounts (X; Y) -Y.

And so on. In the process of dialogue between the business and the team, scenarios are born.

What are the benefits as a result:

  • The main advantage of this approach is that it starts a dialogue between the business and the team and provides a user perspective.

  • The next advantage is that you don’t just start coding implementing abstract technical requirements from the analyst, but you write the code and immediately test yourself. That is, you make the acceptance scenarios work out. These scripts are also easy to automate so you can test yourself until the test is done.

  • At the end of development, it is easier for the customer, the team, and the product to accept the work, since you speak the same language and you created these scenarios together. There are fewer conflicts and ambiguous requirements.

The main risk is not to go into unnecessary details. Don’t try to think through every detail, highlight the main scenarios that you want to see in the first version of your new solution, and then improve with new scenarios in the next versions.

If you see that there are too many scenarios, that they do not fit in a sprint, divide the user story into several and do it sequentially. Also, do not forget that these scenarios can be prioritized.

How to get the most out of ATDD?

In addition to ATDD, use a Test-driven developemnt (TDD) approach when developing new functionality.

TDD completely changes traditional development. Instead of writing code, you first write a unit test for a small functionality. And then write code until the test passes. This approach allows you to build quality into development and make the testing process not a stage in development, but a continuous process of quality control.

Also TDD is the source of technical documentation for the team. Well-written unit tests provide a working specification of your functional code – and as a result, unit tests actually become a significant part of your technical documentation. Similarly, acceptance tests can form an important part of your requirements documentation.

What we end up with:

In the beginning, we create acceptance tests together with stakeholders and customers along with the team. Next, we focus on them when developing the code. We supplement the development process with unit tests, which are written before starting to write code and check that a test is run for each function in the code. At the end of development, we get together as a team and business, look at a working solution and collect feedback.

If you liked the article, come to Telegram channel Dmitry.

OTUS will host an open class soon “Problem customer”where we will discuss:
— Types of stakeholders and how to identify?
— Conflict (what is it, how to deal with it)
– Strategies for dealing with conflicting stakeholders – work on yourself and self-control (what if the problem is me?)
Registration available link.

Similar Posts

Leave a Reply