Elaborating stories using acceptance tests involves defining the criteria for stories before turning them into code. This is the approach we often teach in agile courses.
For example, if I have the story:
As an Iphone user I want to SMS my friends to that I can share my experiences with them
Then the team come up with a series of tests along the lines of “given the user is on the SMS screen, when he/she presses the send button then the SMS will be sent”.
|The user is on the SMS screen||The user hits the cancel button||The Iphone will ask “are you sure”|
|The user is on the SMS screen||The user presses the content section with his/her finger||The keypad will be displayed|
|The date is leprechaun’s birthday||The user enters any text||The iPhone will convert the text to Leprechaun Gaelic.|
These acceptance tests are an excellent way to define the solution space for the developer and are often used in conjunction with any or the remaining approaches I will describe.
More often than not, teams use acceptance tests as a base but provide more information for stories.
Generally speaking I would add a simple “narrative” if the subject matter expert is not sitting with the developer. This is a short summary of the context of the story (one or two paragraphs of text).
I also find a simple sketch or model (with comments) to be of real value to capture some of the understanding, rather than listing everything in acceptance tests.
In addition to this, sometimes I find that some complex business rules end up as 28 acceptance tests when one decision table (or diagram) can cover the same information. So I replace several of the tests (which would otherwise be in “Given … When … Then…” format with a decision table like the following one:
|User setting||Refuse to send SMS||Attach location settings||Create audit record||Confirm send|
|Child emergency use only and number entered is not parents||Yes||Yes||Yes||No|
|Undercover cop or criminal||No||No||No||No|
It is not the role of any one person to create the acceptance tests. Rather, they are created through the collaboration of the tester, business analyst, subject matter expert and developer.
If the same test keeps appearing then convert it to a standard, so that it is taken into account by default when coding or testing.
When doing acceptance tests in conjunction with other information, do the tests first and then see if any can be added when other approaches to elaboration have been completed. Doing the tests first often clarifies understanding quickly and saves work in narratives, etc.
Watch out for
Acceptance tests are not a contract. The developer should question and add to the tests during development as questions and decisions emerge.
Acceptance tests are hard and very useful. If you are finding it hard to create them then skipping them will often result in development and testing taking longer rather than saving time.
The above list is not a finite list of information to provide. Teams should feel free to create data models, lists of constraints and risks, references to development standards etc. The acceptance tests are the framework for understanding not the complete understanding.
Some teams start to fall into what I call “panic waterfall” where developers expect every nuance to be documented. But the rule of sum should be to only document what cannot be reliably communicated through a conversation while the developer is working. That’s why I like the acceptance test approach – it allows the team to think about the outcomes before starting on the code, while leaving room for exploration by the developer while creating the code.