In the chapter about user stories, I explained that they should not contain every details for the feature. Yet the development team needs these details in order to provide value. The details are discussed between the whole team members and you write them down using acceptance tests.
An acceptance test represent a specific scenario for the given user story. They are written by the business analysts and the testers. The developers take no part in the writing since these tests are business focused and are not technical at all.
The acceptance tests are written during the development phase of the user story, this is mandatory since they must passed in order to validate the entire user story.
These tests must be kept and run each time a new build of the application is made. Because working on a new user story can have impacts on previous ones and you want to make sure that they are not broken. Therefore you should find a tool that allow you to run your whole acceptance tests suite automatically.
A common language
Earlier I said that the acceptance tests are written by non-technical people. This allow you to make them understandable by everyone, your whole team is able to read them.
To do so, you can use the gherkin language which has been created to answer this problematic. This language uses a Given-When-Then structure to define the steps of a scenario.
Let’s see an example with the following basic user story:
As a visitor, I want to login, in order to access the website.
I will now create two different acceptance tests with the gherkin syntax for this user story.
Given a visitor, When I log in with an existing account, Then I am able to access the websiteGiven a visitor, When I log in with an undefined account, Then I am not able to access the website
With these scenarios I get more details for the expected behavior of the application regarding the user story to develop. You can use acceptance tests to test incorrect behaviors.
One of the benefit of the gherkin language is that you can use it with several testing framework to automate your tests suite and then you can run them automatically. You can use Cucumber to do so, or Specflow with .NET, this will bring your acceptance tests to a whole new level.
Acceptance tests as proofs
Acceptance tests allow the team to prove that the user story is working as expected. You have a list of scenarios defining the behavior of the feature. And by using an automated tool, you can detect any regression quickly.
These tests are bound to the code written by the development team and therefore are up to date. If the code of the application is updated so are the tests or else it is likely they will no longer pass.
Acceptance tests as documentation
The other benefit I like about acceptance tests is the fact that they can provide documentation for the application. Every members of the team are able to read them to gain understanding of the expected behavior, very helpful for newcomers.
And since it is written by the business analysts, it uses the correct terms for the business domain. This should help the whole team to communicate by using the same vocabulary. It’s a step toward the use of an ubiquitous language for a Domain-driven design (DDD) approach.
Acceptance tests are complementary with the unit tests, they provide a good understanding of a feature and are readable by everyone. They bring the business analysts and the developers closer to each others by providing them a share ground. Using acceptance tests require a good collaboration in your whole team.
In my opinion having them is a big plus to avoid regression, like all automated tests they provide a good safety net for future developments.
See you next time!