Do you know the difference between a desirement and a requirement? via @ElegantCoder
Great article from David about “evolutionary architecture” and a nice example about it from the Microsoft Word ribbon.
David explains desirements and requirements as:
A desirement is a non-compiled request for software to change. Examples include specification documents, Team Foundation Server Work Items, index cards, and hope expressed with Microsoft Word.
Everyone can state a desirement and throw it on the bottom of the wishlist.
The interesting part is when a desirement gets closer to be a requirement (bubbles up) and the team discusses about the details and writes acceptance tests with the business to confirm them.
A requirement, on the other hand, is an automated test proving desired behavior exists in software. Requirements (tests) must pass before software may ship.
This leads to creating a ATDD Ready Backlog, which is a great way to make sure you have “always releasable software”.
Full article from David Starr:
Video: Elisabeth Hendrickson Discusses Agile Testing
Does ATDD really save you time?
ATDD + TDD significantly improve code quality and reduce maintenance costs,
and also contribute to faster project delivery and thus reduced project costs.
The article cites 2 studies:
- teams using agile development practices including in particular ATDD and TDD delivered projects 31% faster with 4 times fewer defects
- TDD significant improves the quality of the code (in terms of the defect rate)
There is always a cost involved in learning something new… and the gains might take some time to cristalize!
Acceptance Test Driven Development (ATDD) is a very effective development practice that essentially involves writing specifications in the form of documented and automated examples. These automated examples become automated acceptance tests that validate the features being delivered. The process of writing these examples encourages teams to focus on where the business value of a feature is coming from, which in turn helps developers aim for the most appropriate solutions in business terms.
code written using good TDD practices is significantly easier to understand and maintain.
Same experience here
Full article by John Ferguson Smart
Creating an ATDD Ready Sprint Backlog in Scrum via @rjocham
Getting Started with ATDD: Overcoming the Biggest Mistakes Right from the Start via @mgaertne
ATDD vs BDD via @lunivore