Linking Requirement and Acceptance Tests

Requirements Management Articles

Acceptance tests and requirements are linked. You can’t have one without the other. The tests clarify and amplify the requirements. A test that fails shows that the system does not properly implement a requirement. A test that passes is a specification of how the system works.

Acceptance tests as described in this chapter are not the traditional user acceptance tests, which are performed after implementation “by the end user to determine if the system is working according to the specification in the contract.” They are also not system tests that are usually independently written by testers by reading the requirements to ensure that the system meets those requirements. However, all three types of tests are related in that they are all black-box tests; that is, they are independent of the implementation.

Acceptance Test–Driven Development is collaborating and improving our understanding through the development of acceptance tests. By having these conversations up front, we save a lot of rework later. Acceptance tests clarify understanding because they require both concepts (the requirement) and examples (the test specification). By actually implementing the test, we ensure our understanding as well increase our efficiency.

Tests for business logic can be executed in many ways.
* Creation through the user interface of a transaction that invokes the business rule
* Developing a user interface that invokes the business rule directly
* A test implemented in a language’s unit testing framework
* An automated test that communicates to the business rule module

Our experience has shown that ATDD is perhaps the most impactful practice that development teams can do. Much of the value is in the conversations and definitions of the tests – something that all teams do. Hence, we strongly recommend it as a practice to adopt as early as possible. The added cost is not much since it’s more about when you do your work, rather than adding new work.

Source: “Essential Skills for the Agile Developer – A Guide to Better Programming and Design”, Alan Shalloway, Scott Bain, Ken Pugh and Amir Kolsky, Addison-Wesley,

This quote discusses the important relationship between requirements and acceptance testing. I remember reading in another book that you cannot accept the definition of a requirement if it is not associated with some tests to make sure that the delivered software satisfies the requirement. This is why approaches like Acceptance Test–Driven Development (ATDD) and Behavior-Driven Development (BDD) try to create a definition of the requirements that can be directly interpreted by software testing tools.

RSpec Behavior Driven Development Tool
RSpec Screen

Further reading

* Agile Acceptance Test-Driven Development: Requirements as Executable Tests
* Acceptance Test Driven Development (ATDD): an Overview
* Acceptance Test Driven Development (ATDD) Explained
* Acceptance Test Driven Development ATDD
* Benefits of Acceptance Test Driven Development
* Automated Acceptance Tests and Requirements Traceability
* “Specification by Example – How successful teams deliver the right software”, Gojko Adzic, Manning

Some Behavior-Driven Development (BDD) Tools:
* Cucumber is an open source behavior driven development (BDD) that works with Ruby, Java, .NET, Flex or web applications written in any language.
* NBehave is a framework for Behaviour-Driven Development for .NET
* JBehave is a framework for Behaviour-Driven Development (BDD) for Java
* RSpec is the original Behaviour Driven Development framework for Ruby.

Find a longer list of BDD tools on http://www.agilesoftwaretools.com/behaviordrivendevelopment.php

Requirements Management Articles
Articles Knowledge

Reviewing Requirements for Testability

Modern software development approaches like Agile support a strong collaboration between all member of the software development team, software testers and business analysts included. Even if you don’t use a method like Behavior-Driven Development (BDD) or Specification by Example, checking the fact that you will be able to actually test your requirements is a good […]

Read More
Requirements Management Articles
Articles Knowledge

Techne: New Requirements Modeling Languages

Techne is an abstract requirements modeling language that lays formal foundations for new modeling languages applicable during early phases of the requirements engineering process. During these phases, the requirements problem for the system-to-be is being structured, its candidate solutions described and compared in terms of how desirable they are to stakeholders.

Read More
Requirements Management Articles
Articles Knowledge

User Stories for Both Requirements and Testing

User stories are a technique taken from the agile development playbook that can easily be applied in traditional systems development and maintenance. User stories help you document needs in a structured way, from the users’ perspective. They’re a good basis for test cases, so as to support integrated requirements management and testing. In this article, […]

Read More

Copyright © 2009-2021 Martinig & Associates