Use ATDD as an advanced extension of TDD, keeping the software's development
guided by the principles of satisfying the customer's needs through acceptance
criteria and automated testing.
BDD, ATDD, UTDD, DSL's ... when will it all end...
The drive toward business-driven testing has never been stronger. Developers
are seemingly now finding a higher and higher bar when it comes to customers'
expectations of quality and features. Our tools are getting better, and we can
deliver more software, faster. But, our methodologies haven't necessarily
changed enough to satisfy today's customer expectations.
Enter Business-Driven Design...
Business driven design is a concept that enables us to take business
requirements and current priorities and turn them into a software design through
Acceptance Test-Driven Development. The business requirements that drive the
need for the software are turned into specific criteria that allow the business
to decide what the criteria are that will allow them to use a feature and have
it meet their business need. Rather than the old-school way of gathering
requirements, and having a requirements document and a functional specification,
we now turn to individual small criteria that decide if the software is
acceptable to meet the need. Some of the criteria map directly from functional
requirements, and others may not have been captured in a traditional
requirements gathering and specifying model.
Domain-Specific Languages (DSL's) are key to success in Acceptance
Test-Driven Development. DSL's give us a way to communicate with the customer
and domain experts in their terms. When we capture criteria in this manner, it
becomes quite clear to those with domain knowledge, what is meant and what is
desired. There is no need for a "translator" between the customer and the
developers (this used to be called "Business Analyst"). The developers model the
code in terms of the language the customer already uses. This mechanism leads to
better communication, better encapsulation, and better object-oriented
development.
Acceptance Test-Driven Development [ATDD] gives us a mechanism to use DSL's and direct customer involvement in making sure
the software we deliver meets the needs. When we take the criteria and turn them
into automated acceptance tests, it is far easier for the customers to see that
they are getting what they asked for. It's also easier for the developers to
have a target to shoot for, and have a goal to meet. This way, they are more
focused on delivering a specific unit of functionality that the customer needs
rather than (as so often happens) some "new feature" that they thought might be
useful.
Much care needs to be put into the way that acceptance criteria are gathered
and then automated. If there is something that is missed, it could critically
affect the design. This is an opportunity for customers and developers to
collaborate and get it right. The customer needs to understand that if it isn't
on the acceptance criteria list, it isn't going to be in the software...
Performance criteria, interoperability with other systems, and other criteria
like these are often missed. Customers should have many opportunities to review
and re-review the criteria before they are approved. Even still, sometimes
things are missed. This is why it is important for the customer to be involved
at all stages of the development process. The customer shouldn't just be
involved in the criteria gathering, then come back later for their product. If
things are missed, they will likely become apparent and turn up in daily work.
If the customer is there to be consulted, decisions can be made about how to
integrate missed criteria, and how to capture these better in the future.
Business-Driven Design is a business-centric, collaborative, agile mechanism
for delivering quality software to today's demanding customer.