Several members of the Agile community describe different styles for expressing user story tests and the testing of an entire theme.
Charles Bradley describes several ways of expressing story tests:
- Bullet points
- Write the actual and expected system behavior as a series of bullet points on a story card or on a wiki. This technique can work well for small or simple stories.
- "Test with..."
- Note any scenarios and/or data that you will need to test with. For example, "Test current password with incorrect/correct/blank." Like the previous method, this technique often works best with small or simple stories.
- "Test that..."
- Start with "Test that...", then write as much prose as you need to verify the system behavior. One of the easier styles to learn, this method can work well for simple tests and tests that can't be represented well by other methods.
- Given/When/Then
- Use three sections: Given, When, and Then. In the "Given" section, list the preconditions, test setup, test inputs, and system state. In the "When" section, list the trigger or state transition event. In the "Then" section, list the system behavior, expected output, and/or the next system state. This style can work well for tests that require lots of preconditions or that have a specific trigger.
- Specification By Example—Conceptual Form
- Create a table of test inputs and expected outputs. For the conceptual form, describe the data rather than using specific values. Tests that can easily be put into table format can potentially profit by using this method.
- Mix and Match
- Draw from different methods to best match the various aspects of your test.
Peter Stevens offers the "How to Demo" test form, which is essentially a simple workflow describing how to demo the completed user story to the Product Owner. He writes:
Creating the how-to-demo is part of grooming the product backlog, so it can be created either at the estimation/release planning meeting or in sprint planning 1, or somewhere along the way. It's part of the Conversation, so it shouldn't happen too far in advance.
Lisa Crispin describes using a mind-map to plan the testing that needed to be done to complete an entire theme. The theme she described took the team five iterations to complete, representing ten weeks of work. Crispin and another tester began by drawing on a whiteboard a mind-map of the testing to be done. They then discussed the mind-map with the development team, the Product Owner, the controller, and other stakeholders.
The testers referred to their mind-map many times during the implementation of the theme. Crispin writes:
At the end, we felt confident that we'd thought of and discussed all angles of the process, its potential impacts on other parts of the system, talked to all stakeholders about their individual needs and concerns, and done adequate testing not only at the functional level, but also performance and usability.