Maybe the most important methodology in a project is the Acceptance Test-Driven Development (ATDD) or Story Test-Driven Development (STDD); it is TDD but on a different level.
The acceptance (or customer) tests are the written criteria that the project meets the business requirements that the customer demands. They are examples (like the examples in TDD) written by the project owner. It is the beginning of the development for each iteration, the bridge between scrum and agile development.
In ATDD, we start the implementation of our project in a different way to the traditional methodologies. The business requirements written in human language are replaced by executables agreed by some team members and the customer. It is not about replacing the whole documentation, but only part of the requirements.
The advantages of using ATDD are as mentioned:
- It provides real examples and a common language for the team to understand the domain
- It allows us to identify the domain rules properly
- It is possible to know if a user story is finished in each iteration
- The workflow works from the first steps
- The development does not start until the tests are defined and accepted by the team
The user stories of ATDD are like use cases in terms of name or description, but work in a different way. A user story does not define the requirement, avoiding the problem of ambiguity of the human language. The goal is to communicate the idea without problems for the rest of the team.
Each user story is a list of clear and concise examples about what the customer wants from the application. The name of the story is a sentence of human language defining what the function must do. Consider the following examples:
- Search available secrets around our position
- Check the secrets we already have stored
- Check who is the winner in a battle
They have the goals of listening to the customers and helping them define what they expect from the application. The user stories should be clear without ambiguity and should be written in human language, not in technical language; the customer should understand what they say.
Once we have defined a user story, some questions appear and they should be answered by associating acceptance tests for each story. For example, for the Check who is the winner in a battle story, some possible questions are as listed:
- What happens if they draw?
- What does the winner win?
- What does the loser lose?
- How long does a battle take?
And the possible acceptance tests are as follows:
- If they draw, no one will win or lose anything; they will keep their secrets
- The winner will earn 10 points and get a secret from the loser's pocket
- The loser will give a secret to the winner
- A battle takes three throws of a dice
Maybe the questions and answers from a user story will generate new user stories to be added to the backlog.
The algorithm of ATDD is like the TDD, but reaches more people than the developers. In other words, doing ATDD, the tests of each story are written in a meeting that includes the project owners, developers, and QA technicians because the team must understand what is necessary to do and why it is necessary so that they can see if it is what the code should do. The following image shows the ATDD cycle:
The starting point of the ATDD algorithm is the discussion. In this step, the business has a meeting with the customer to clarify how the application should work and the analyst should create the user stories from that conversation. Also, they should be able to explain the conditions of satisfaction of every user story in order to be translated into examples as we explained earlier, in the user stories section.
By the end of the meeting, the examples should be clear and concise so that we can get a list of examples of user stories to cover all the needs that the customer reviewed and understood for himself. Also, the team will have a project overview in order to understand the business value of the user story, and in case the user story was too big, it can be divided into little user stories, getting the first one for the first iteration of this process.
The high level acceptance tests are written by the customer and the development team. In this step, the writing of the test cases that we got from the examples in the discussion step begins and the team can take part in the discussion and help clarify the information or specify its real needs.
The tests should cover all the examples that were discovered in the discussion step, and extra tests could be added during this process; little by little we are understanding the functionality better.
At the end of this step, we will obtain the necessary tests written in human language so that the team (including the customer) can understand what they will do in the next step. These tests can be used like documentation.
In the develop step, the acceptance test cases start to be developed by the development team and the project owner. The methodology to follow in this step is the same as TDD--the developers should create a test and watch it fail (red), and then develop the minimum amount of lines to pass (green). Once the acceptance tests are green, this should be verified and tested to be ready to be delivered.
During this process, the developers may find new scenarios that need to be added into the tests or even, if it needs a large amount of work, it could be pushed to the user story.
At the end of this step, we will have a software that passes the acceptance tests and maybe more comprehensive tests.
The created functionality is shown by running the acceptance test cases and manually exploring the features of the new functionality. After it is demonstrated, the team discusses whether the user story was done properly and whether it meets the product owner's needs and decide if they can continue with the next story.