#59-The Structure of an Acceptance Test

This episode is about the creation of acceptance tests, who should write them and how they should be structured, to get the maximum value from them.

Transcript

The Structure of an Acceptance Test

The writing of acceptance tests is a collaborative process that should involve different people from every aspect of the organization that has knowledge to contribute to the creation of a product or feature. It should be done as part of planning, alongside other activities such as the writing of use cases, performing commonality-variability analysis, creating context and business-process diagrams, and various other analysis techniques. 

But if acceptance tests are written before the product is created, then the activity is not really a testing activity. You cannot test what does not exist.  In this mode, the creation of acceptance tests is a definition of the behavior that is to be created. This is true at the systemic level in a process like the waterfall, or at the feature level in an agile process. In either case the acceptance tests should be structured in such a way that they capture the behavioral value of the system in an accurate and precise way. This should be done collaboratively to ensure that every point of view is represented that has a stake in the outcome of the process. 

Behavior can best be defined as a cause and effect relationship, within a known context. This is something everyone understands at a fundamental level, because it guides how we live. In his groundbreaking work on behavior driven development, Dan North suggests the process of defining three things: given, when, then.

“Given” defines the context within which the behavior should take place. 

“When” defines the triggering activity that causes the behavior to happen. 

“Then” describes the result of the behavior when it is properly operating. 

Here is an example: 

Given user X is logged into the system with administrative privileges,

When X requests the activity log for the day, 

Then the activity log is downloaded to X’s local  workstation. 

The context is the user logged in with the proper privileges, the cause is the request for the activity log, and the effect is the downloading of that log. This can be expressed in a number of different ways other than plain text.

For example one could create a spreadsheet where the columns are various givens, the rows are various whens, and the intersection of those rows and columns are the resulting then or behaviors that the system can create.  This would not only be efficient when there are many permutations of the behavior, but also would be easily usable by business analysts that are comfortable with spreadsheets.

Organizations that do complex scientific work often have symbolic representations and equations  that they understand well and that can be used to express all three aspects of an acceptance test.  

The recommended way to select the best representation for your organization is to start by defining who your stakeholders are and what language they have facility with.

This is because an acceptance test should be something that anyone can write, anyone can read and understand, and that anyone can update later. Unit tests, which are typically written in computer code, would not be appropriate for business analysts and product owners to try and interact with. If however the stakeholders to a given feature or product were other developers, say in a devops product, then unit tests could certainly be used to express given, when, then. 

My second agile tip was about not choosing an acceptance testing automation framework before you know what that language is. This is because different frameworks for automating acceptance tests are good at automating different forms of expression. Anything that you can imagine can be automated with the right tools even if those tools must be created by the organization itself. 

But regardless of the form of expression that works best, always remember that the underlying concept of Given, When, Then is always there, and should always be clear to all concerned.