Accpetance Tests are executable specifications. They verify a product’s correctness from a business perspective.
According to Andy Dassing (http://tech.groups.yahoo.com/group/fitnesse/message/10115)
Acceptance Tests insure the right code is built … while Unit Tests insure the code is build right.
Acceptance Tests are written in the language of the domain.
An Acceptance Test should verify a single aspect of a User Story.
When all Acceptance Tests pass, the system is complete.
An extract from Mike Cohn’s User Stories Applied concerns me because I don’t know what artifacts I have available when maintaining the software.
Use cases are often permanent artifacts that continue to exist as long as the product is under active development or maintenance. Stories, on the other hand, are not intended to outlive the iteration in which they are added to the software.
After the software is build how do I maintain the software? How do a find out what the system should do if the story has been ripped up? If the story is not intended to outlive the iteration, what about the acceptance tests? If a user story changes surely I would use the existing story and acceptance tests to understand the impact of the change. The code can not be the only documentation for a system as only a small part of the team (the developers) can understand the code.
One of my biggest concerns about agile is that it is all about developing software are not about maintaining software; the maintenance cost over the life time of a piece of software is far bigger than the upfront development cost.
Agile allows a project to start without needing a complete set of requirements. Agile acknowledges the fact that customers do not know all the requirements of the system before the process begins. As the project progresses, everyone learns more about the system under construction; ideas and understanding changes. Acknowledging that change is inevitable while providing a way to manage this change is one of the strengths of an agile process.
When looking at the goodness of a User Story, see if you should INVEST in it
Independent – each story should stand on its own
Negotiable – stories are in invitation to a conversation; there must be flexibility and room for change. The bigger the story the more details need to be negotiated
Valuable – the story must provide business value; that is its only reason for existing
Estimable – to be useful a story we must be able to estimate it; estimation and tracking are core aspects of an agile process
Small – at most a couple of staff-weeks of work. Too big -> too hard to stay to know what the story is really about.
Testable – if a story is not testable we will not be able to determine if it done; a story is complete once it has passed all its tests.
I found a very insightful article on an agile metric at http://xprogramming.com/xpmag/jatRtsMetric by Ron Jeffries called A Metric Leading to Agility. The metric is Running Test Features (RTF)
My take aways:
We are just starting to use an agile methodology and I am finding out as much as I can to make it successful. I will be very interested in how useful we find this metric.
Format: I as a (role) want (function) so that (business value).
The main purpose of a User Story is to be a reminder to have a conversation.
A good way to get the initial User Stories is to consider the goals that each user has for using the software.
To avoid blending solutions with requirements strive to specify the UI as late as possible.
http://www.agile-software-development.com/2008/01/example-of-user-story.html
The Conversation section provides more information about the story – the invitation for a conversation.
The Confirmation section provides the test cases for the story- how the story will be confirmed.
Both the Conversation and the Confirmation represent the requirements for the story.
User Stories are written to facilitate release and iteration planning as well as an invitation for a conversation.
While Use Cases are written as a result of analysis, User Stories are written to initiate an analysis conversation.
I love this quote from http://techdistrict.kirkk.com/2009/09/11/agile-architecture-presentation/
The goal of architecture is to minimize the impact and cost of change. To do this requires we create flexible systems with the ability to adapt and evolve. But with flexibility comes complexity, presenting architects with a paradox. As we design more adaptable systems, the additional complexity reduces their ability to survive. Eventually, the software rots, the architecture crumbles, and the system fails. Therefore, we must find a way to increase adaptability without decreasing survivability.
Mentioned in Dispatches 