Introduction to Acceptance/Customer Tests as Requirements Artifacts

	Introduction to Acceptance/Customer Tests as Requirements Artifacts

Home \| AMDD \| Best Practices \| Architecture \| Requirements \| Analysis \| Design \| Documentation \| Models \| Modeling Style \| Contact Us \| Mailing List \| FAQ

Acceptance tests (also called Customer tests or Customer Acceptance Tests) describe black-box requirements, identified by your project stakeholders, which your system must conform to. In traditional software development acceptance tests are typically thought of as testing artifacts, which they are, but when you step back and think about it acceptance tests really are first class requirements artifacts because they describe the criteria by which stakeholders will determine whether the system meets their needs. In short, they're executable specifications. Business rules, features, technical (non-functional) requirements, and even detailed usage requirements can easily be captured as acceptance tests. Mike Cohn likes to call acceptance tests "conditions of satisfaction". Ron Jeffries measures project progress via the Tested Feature Metric, and the only way you can capture this metric is by having an acceptance regression test suite.

Figure 1 and Figure 2 each depict acceptance test descriptions (both test descriptions are shortened for the sake of brevity, both would need to be expanded with more steps, and/or support by other test cases, to truly validate the functionality described). As you'd expect, each test has instructions for setting up and then running it. Additionally, a description, test ID (optional), and expected results are also indicated. In the case of Figure 2, the definition of a "standard wildcard search" would appear in your organizations user interface guidelines (remember, follow the practice Apply Modeling Standards).

Figure 1. Acceptance test for validating a business rule.

ID	T0014
Description	Checking accounts have an overdraft limit of $500. As long as there are sufficient funds (e.g. -$500 or greater) within a checking account after a withdrawal has been made the withdrawal will be allowed.
Setup	Create account 12345 with an initial balance of $50 Create account 67890 with an initial balance of $0
Instructions	Withdraw $200 from account #12345 Withdraw $350 from account #67890 Deposit $100 into account #12345 Withdraw $200 from account #67890 Withdraw $150 from account #67890 Withdraw $200 from account #12345 Deposit $50 into account #67890 Withdraw $100 from account #67890
Expected Results	Account #12345: Ending balance = -$250 $200 Withdrawal transaction posted against it $100 Deposit transaction posted against it $200 Withdrawal transaction posted against it Account #67890: Ending balance = -$500 $350 Withdrawal transaction posted against it $150 Withdrawal transaction posted against it $50 Deposit transaction posted against it Errors logged: Insufficient funds in Account #67890 (balance -$350) for $200 Withdrawal Insufficient funds in Account #67890 (balance -$450) for $100 Withdrawal

Figure 2. Acceptance test for validating part of a user interface.

ID	T0015
Description	The customer search screen allows user to perform standard wildcard searches on first and last name.
Set Up	Remove all customer records from the database. Add the following customers: John Smith James Doe Robin Saunders Jim Saunders Sally Smith Scott Davidson Beverley Williams Bob Roberts Rob Williams Robert Smithers Bobby Snookerby Sandy Davington Janice Sinters
Instructions	Display the Customer search screen. In the First Name entry field, enter "%ob" In the Last Name entry field, enter "S" Press the search button.
Expected Results	The following names should be displayed in the search result box: Robin Saunders Robert Smithers Bobby Snookerby

Acceptance tests should be fully automated so that you can run them as part of your application's regression test suite. The FITNesse testing framework is a popular choice for doing so.

Why is it important to recognize that acceptance tests are first-class requirements artifacts? Because if you follow the single source information practice and capture requirements once, as acceptance test, instead of twice (as some other requirements artifact and as acceptance tests) you can dramatically reduce your traceability needs on your project. Furthermore, your acceptance/customer tests are effectively executable specifications, providing value both in the form of detailed specifications and as tests which validate whether your software conforms to those specifications.

Suggested Reading

		The Object Primer 3rd Edition: Agile Model Driven Development with UML 2 is an important reference book for agile modelers, describing how to develop 35 types of agile models including all 13 UML 2 diagrams. Furthermore, this book describes the techniques of the Full Lifecycle Object Oriented Testing (FLOOT) methodology to give you the fundamental testing skills which you require to succeed at agile software development. The book also shows how to move from your agile models to source code (Java examples are provided) as well as how to succeed at implementation techniques such as refactoring and test-driven development (TDD). The Object Primer also includes a chapter overviewing the critical database development techniques (database refactoring, object/relational mapping, legacy analysis, and database access coding) from my award-winning Agile Database Techniques book.
		Agile Modeling: Effective Practices for Extreme Programming and the Unified Process is the seminal book describing how agile software developers approach modeling and documentation. It describes principles and practices which you can tailor into your existing software process, such as XP, the Rational Unified Process (RUP), or the Agile Unified Process (AUP), to streamline your modeling and documentation efforts. Modeling and documentation are important aspects of any software project, including agile projects, and this book describes in detail how to elicit requirements, architect, and then design your system in an agile manner.
		The Elements of UML 2.0 Style describes a collection of standards, conventions, and guidelines for creating effective UML diagrams. They are based on sound, proven software engineering principles that lead to diagrams that are easier to understand and work with. These conventions exist as a collection of simple, concise guidelines that if applied consistently, represent an important first step in increasing your productivity as a modeler. This book is oriented towards intermediate to advanced UML modelers, although there are numerous examples throughout the book it would not be a good way to learn the UML (instead, consider The Object Primer). The book is a brief 188 pages long and is conveniently pocket-sized so it's easy to carry around.

Let Me Help

I actively work with clients around the world to improve their information technology (IT) practices as both a mentor/coach and trainer. A full description of what I do, and how to contact me, can be found here.