 |
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.
 |
|
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. |
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.
|
