I went to an Agile Acceptance Testing seminar last week. The program of the seminar was announced as follows:

“Agile Acceptance Testing is a technique for closing the communication gap between business, developers and testers. A way to write specifications as examples which become executable. The specification are created together in a workshop and not handed over like traditional requirements”

To me, this is an ambitious goal. And I am happy to say that the seminar demonstrated successfully that frameworks exist to help teams succeed in reaching this goal.

Asking the "why" question

The scene of the conference was set right away with the introduction talk of Gojko Adzic who emphasized you should always ask the question why a particular feature is needed. Gojko quoted many examples from his book “Bridging the communication gap” where people asking for features in terms of solutions should always be questioned about why this particular solution is needed. In one example, the question of having a real time reporting system turned out to have a 4 hour response window… Asking the “why” question is an ideal starting point to formulate acceptance tests.

New story title template

It was advised to use instead of the familiar:

As a [actor], I want to [do action] so that [goal].

A slightly reordered template

In order to [goal], [actor] should be able to [do action].

Just to emphasize the “Why” at the start of the user story’s title.

Beyond TDD

There was a unanimous view from most presenters - 13 in total - that Test Driven Development was too narrow as a term. It clearly has a developer’s view point. More suited is a term like BDD for Behavior Driven Development. With a focus on ‘behavior’ the dual responsibility of both stakeholders and development is emphasized.

Behavior templates

The trick in all this is to express the user requirements in the following format:

Note that any analyst or user representative can ‘read’ and understand these requirements and after some “getting used to”, should be able to write specifications in this way.

In a series of steps, this high level description is then gradually translated into working test code. This Automated Acceptance testing should be part of the daily build and test runs. The advantages are obvious:

• Requirements can be written in plain text, making the thresholds for non-development people low.
• There is a one-to-one translation between the plain text and running test code, making sure that the system is actually performing what the specification intended.
• When the requirements change, tests will break.
• When the implementation changes, tests will break.

More explanation about the 6 steps to take can be found in the cucumber framework site.

Scrum requires solid engineering

This seminar was a clear illustration that applying scrum into your organization will require a number of good software engineering practices. Adequate release management, strict source control and automated testing are just a few of the principles you need to apply.

One of the speakers’ blog post on testing illustrates why acceptance testing is important. It is not easy and there are many traps a team can fall into: read more on Top 10 reasons why teams fail with Acceptance Testing.

Conclusion

AGILEMinds has done a great job in assembling a wonderful set of international speakers around this topic. With more or less 100 people in the conference room, it was clear that this topic has a great interest in the development community. The Acceptance Testing Days Video + Slides will be published by the end of April, so you can watch any of the sessions offline.