Test-first design and development is one practice in the agile toolbox that has proven its merits in recent years. The advantage of this approach is that, for every bit of code you produce, there is an automated test available. Hence, regression testing becomes easy, and the barrier to changing code for reasons of better design, better performance, or simply changed requirements is lowered.

This paper discusses the application of test-first one step earlier in the development cycle, by using an acceptance test-first approach in requirements engineering. The authors argue that, by expressing requirements as tests, the precision of requirement specifications is improved, and irrelevant or unusable features are weeded out via this less abstract form of description.

The paper starts with a quote from a requirements engineering textbook that argues for the use of test cases as a tool for testing requirements. From this starting point, the authors motivate the use of acceptance tests, present the difference in precision between traditional requirements and tabular specified acceptance tests, and, finally, arrive at the so-called equivalence hypothesis, which is stated as: “As formality increases, tests and requirements become indistinguishable. At the limit, tests and requirements are equivalent.”

In the remainder of the paper, this hypothesis is discussed and fleshed out. Some examples of requirements, expressed as acceptance tests, are given, and it is shown that they are essentially executable specifications. The authors use the framework for integrated tests (FIT) by Ward Cunningham to show that the tabular tests are as easy to understand as requirement specifications written in the usual narrative and textual form. Finally, they show that their approach scales beyond the simple specification of user interactions, and can even cover concurrency issues.

In the conclusion, the potential business impact of the approach is stated as cutting time and money from the test planning phase, and reducing the number of needless features in the application.

The paper is well written and highly motivational. The ideas presented are underpinned with good examples, and since there is even tool support available for the approach, I at least intend to read further and have a look at the FIT framework and its associated tools.