iceScrum | Acceptance test states – iceScrum

iceScrum Blog Get news from iceScrum Team about Agility, Scrum

Acceptance test states

May 30, 2013

Hello everybody,

We are glad to introduce a major addition to acceptance tests. In iceScrum R6#5 and greater, acceptance tests now have states: To check, Failed and Success.

Acceptance tests workflow

Acceptance tests follow simple rules according to the state of their parent story. They can be created, updated and deleted by the Product Owner(s) and all the team members.

When a story is Done, its acceptance tests cannot be updated anymore. A Done story can be declared “undone” and its acceptance tests can be updated again as long as the sprint isn’t closed. This is a good occasion to recall that closing a sprint is a meaningful action that makes all its elements read-only, so it must be done carefully.

Another rule to keep in mind is that all tests associated with Done stories must have the Success state. Consequently, when a Product Owner declares a story as Done, its To check and Failed tests will be declared automatically as Success.

If you come from a former version of iceScrum, tests associated with Done stories will be automatically migrated to the Done state.

Integration with stories workflow

Acceptance tests are listed in story details, which is convenient when working on a story. However, we think they bring important information that should be accessible even if you don’t browse a particular story. Thus, a specific icon is displayed on stories that have acceptance tests. Its color summarizes its acceptance tests states and the number of acceptance tests grouped by state can be displayed by hovering over it.

Acceptance tests can be used in iceScrum in order to express any condition that may help the Product Owner(s) determine whether a story is Done. Consequently, when all tests are declared as Success by a Product Owner, iceScrum suggests that he declares the story as Done.

What’s next?

We think about new features regarding acceptance tests, namely integrating them into the iceScrum API (ICESCRUM-538) and providing a BDD template (ICESCRUM-533). However, before starting further developments, we would like to hear your feedback!

Do you like these new features? Do they fit your workflow? Are they unnecessarily complicated or, on the contrary, too simplistic?

Published in

  • Kagilum
    About the Author:

Leave a Reply

Your email address will not be published. Required fields are marked *