While testing often tests and acceptance criterias terms are used wrongly in an interchangeable way.
However, they are not the same thing, do not serve the same purposes and knowing their difference will prevent making some mistakes.
Acceptance criteria: Communication
An acceptance criteria is here to describe an expectation about the application.
It is often created in collaboration with the business team that has the expertise about the area in question and due to that it is written in plain english so non tech people are also able to understand it.
However, as it is important to be exhaustive while listing assertions we have about the application.
This is why acceptance criterias need to describe an atomic behavior.
AAA Framework
For that it is possible to use the AAA framework which relies on dividing our acceptance criterias into tree parts:
- Arrange: The objective is to set an initial state for the test to insure each run will provide the same output.
- Act: The idea is to run the logic tested.
- Assert: The objective is to make sure the final state from the application is the one expected.
An easy way to respect this pattern within your acceptance criterias is by using the Gerkhin syntax.
Gerkhin syntax
This syntax is centered around certain keywords that differentiate the different steps:
- Given: The text here will have to describe the arrange step.
- When: The sentence will describe which logic to test.
- Then: It will describe the final state.
To make this more visual here is an example of an acceptance criteria written using Gerkhin:
Given the sitemap option is equal 'sitemap.xml'
And the URL is 'http://example.org/wp-sitemap.xml'
When getting full URL
Then URL 'http://example.org/sitemap.xml' should be returnedAutomated Test: Awareness
While it might be a bit confusing at first the only task of a test is to raise awareness.
To understand that we need make a clear difference between the acceptance criteria and the test.
The role of a test
While the test is implementing the acceptance criteria, it is not its role to be used to communicate as it is already the one from the acceptance criteria.
Instead its role is to validate or invalidate this behavior so the person executing the test know that a decision will have to be made.
Either the expectation about the application have changed and the acceptance criteria and the test should be changed.
Either the expectation about the application remained the same and the code is faulty and need to be fixed.
Automation versus manual
Automating a test is not always the best solution as gains you will get from it might not be covering the initial time investment and effort to maintain the test.
That is why when testing it is important to estimate the value and benefits that automation could bring you.
Spotting a critical part of the application or a potential fragile test are an easy way to make a decision on whenever testing manually or with automatic tests but this is not always so easy.
To be able to rapidly have benefits automatic tests it is important to prioritize tests to write that way we will put 20% of efforts to achieve 80% of the value.
Then later on when we will be able to afford more tests we will then continue until we gain no value from automating the remaining tests.
Writing a good automated test
As said previously the role of test is to bring awareness.
However, in the case of an automated test it is key to keep it easy to understand as the test will also bring the context within the developer will have to take a decision.
If the test is unclear then most of the value from the test will disappear as the intent from acceptance criteria won’t be clear and no decision will be taken or worse the test gonna be dropped losing all of its value.
Naming the test well, using the AAA framework inside the tests or using sub functions or generators to hide a part of the complexity from the test can be a great way to keep the test intention clear even month or year after it has been written.
Leave a Reply