||How do I do it? What do I need
to get started?|
Driven Development is a practice that can yield good returns on the time
invested. Customers will be pleased with the software they receive, bugs will be
fewer, and delivery times will be shorter. However, there are a few things that
are needed to make this practice effective in an
- People must be bought-in to the concept that test driven
development is a good thing.
- Management must support this practice, for if not, it will be a
much more difficult thing to accomplish.
- Developers must be willing to put aside their "classical"
training and try something new.
- Testing Tools
- If we can't write an automated acceptance test for our product,
we can't do ATDD. We need a tool designed for testing the particular type of
product we are shipping.
- Story Test IQ [STIQ] is a great tool for automated testing of
web applications. Straight Selenium RC under C# code, driven by NUnit also works great, in my experience. VSTS has some good tools also, as do Fiddler, and probably
lots of other products.
- The framework must be in place on day 1 of the iteration to
begin writing acceptance tests. If it isn't available, we won't be able to do
- Developers need the skills to be able to envision what is to be
delivered, and be able to write automated test scenarios for the acceptance
- Testers need to be able to validate that the tests cover enough
of the functionality through testing the criteria, and provide other functional,
integration, load, and performance tests in addition to the developers' unit
tests and acceptance tests.
- Management needs to be able to direct the right resources at
tasks, no matter whether they are Development or Test tasks. Sometimes it's best
to blur the lines between the disciplines to make this practice most
- Customers need to be aware that they are actually going to get
what they specify (and perhaps ONLY that much). Education on criteria evolution
is almost always required for customers. Don't be surprised if only 50% of the
criteria are discovered in sprint planning and story generation for the first
couple of iterations.
- TDD takes discipline, and ATDD even more so. This is not a
practice for an organization just beginning down the road of TDD. Put in at
least 6 iterations of using strict TDD first before trying ATDD. The experience
gained with using TDD will naturally flow into ATDD, and the organization and
the customers will see the benefits.
- Good things don't happen instantly. It takes some time to see
the benefits of ATDD.
- Be patient for a few sprints. It should take approximately
three iterations to get it dialed in.
- Customer Cooperation
- Customers must be available for providing their criteria for
- Customers generally are not experts in this type of
"specification" of criteria, and must often be helped through the process at
first, to generate usable criteria.