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.
|
