BT

Representing Agile Testing

by Dan Puckett on Apr 25, 2011 |

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.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT