Rimu Research


Immediate Storytest Feedback


Paper and Talks



Towards Executable Specifications

You've been applying Storytest Driven Development, but you are not satisfied with the results, given the effort. Here's some possibilities of what may be happening:

  • The storytests often arrive too late to be used to drive development.
  • They are expensive to maintain.
  • They run slowly, so feedback is delayed. They're run less often than the ideal.
  • The storytests are difficult to read and organize, and the Customer team have mixed feelings about their value.
  • There are business domain  issues that are not easily resolved, even with repeated discussions between your Customer team and the developers.
  • There are overlaps between the storytests and unit tests and it's unclear when to use which.
  • You wonder whether there are better ways to do it.

One of the common problems is with the form of the storytests:

  • Perhaps you write them in terms of the UI, because that's the "obvious" thing to do
  • So you leave writing or completing them until after coding and after the UI is stable, because there is uncertainty around the UI when you write stories.
  • So you're unable to use the storytests to effectively drive the development process
  • The storytests are brittle and large, because of all the UI details. Hence they're expensive to change as the system changes.
  • There is a lot of duplication, which makes changes worse. Trying to run the tests in a fixed order to reduce redundancy leads to tests being inter-dependent. Thus a test is more likely to break due to a change elsewhere.
  • It's easy to get lost in the details of a particular storytest, and so miss the bigger picture of the business domain and the business rules concerned.
  • It's difficult to find the storytests that are inter-related. You'd prefer to run only the ones that are relevant to the changes that have been made recently.

Here are some coaching possibilities...

Copyright, Rick Mugridge, Rimu Research, 2006 .. 2009.