In 2018, I constantly had issues with my clients on what was the final state of my projects.
Since then I introduced acceptance criteria to my workflow, and it is much easier for me now as I have a clear scope for my projects and a clear way to check if the scope is done
What is an acceptance criteria
A well-formed acceptance criteria is always composed of three parts inspired from the AAA framework, which eases the test implementation:
- Arrange: That state aims to describe the initial state from the test to make sure it is reproducible.
- Act: This part describes which logic from the application needs to be executed in the test.
- Assert: That last step verifies that the final result matches what was expected.
Communicate with acceptance criteria
As acceptance criteria are written in plain English, it is possible for non-technical people to understand it that way it is a great interface between technical and business people.
That way it is possible for everyone involved to work together as one team but more importantly, to be able to communicate asynchronously without needing each other to be there at all times.
For the non-technical people this system allows them to rapidly check the status of the project by simply looking at which acceptance criterion has been implemented and also correct any errors they find in the acceptance criteria themselves.
For the developers, on the other hand, it is much easier now to implement the test as we are sure the project requirements are well defined from the start.
Moreover, as it is still automated tests, it is also possible to check for regression easily just by running the test suite again.
Define acceptance criteria
To define an acceptance criteria, there is one golden rule: the client should always validate them.
It is important as any gap between acceptance criteria and the reality of the project requirement would make all testing efforts useless.
To define an acceptance criteria, you need to first listen to the clients’ needs and break them down into a list of features.
Once this is done, then we can start defining our by listing out each possible state using a pseudocode language called Gherkin.
In Gherkin syntax each sentence starts with GIVEN, which is the equivalent of the Arrange step from the AAA framework. In that step we need to describe the initial state from the test case.
Once we finished describing the initial state, we can then move on to the WHEN, which is the equivalent of the Act step and describes what logic should be tested.
Finally, the last step of the Gherkin acceptance criteria is the THEN statement, which is the Assert step where you check if the final result matches your expectations.
Once you are done writing all these acceptance criteria, it is now time to make the client validate them and circle back to create acceptance criteria if the client doesn’t validate it.
Implement acceptance criteria
Once both parties have validated the acceptance criteria, it is now time to implement them.
For that we need to define a developing workflow which will be used to write your code and test correctly.
A tendy workflow is Test-Driven Development.
However, executing it perfectly may not be the simplest thing for beginners as they end up lost in the process instead of focusing on the quality of what they write.
That is why I often recommend coming back to the basics and the three rules which structure TDD:
- Implement the test before writing any code: This is to make sure you are not testing your code and that you are basing them on your acceptance criteria.
- Make sure that the test fails before you wrote any code: This check is here to make sure the job wasn’t done previously and that implementing that code will be effective work for the company.
- All tests should pass once you finished writing code: this allows keeping track of what matters for us inside the application and makes sure that we won’t break anything while refactoring or adding new features in the future.
You don’t need to be perfect at all times by overall you need to try respecting that order as much as possible while working, and you see testing will pass from a painful task to a pleasurable one.
Conclusion
As you saw, adding acceptance criteria to your workflow can be a game changer as it will help you and your clients to be more autonomous but also more independent while working on a project together.
If you are interested in applying this concept for yourself, please check out the checklist below which is resuming the full process.
