Managing Agile Project

Requirements with
Storytest-Driven
Development
Author : Rick Mugridge
From : IEEE Computer Society 2008
Presented by : K.W. Lee, 05.03.2008

1
 Outline
1 Introduction
2 Storytest v.s. Test-driven Development
3 Expressing Storytests with FitLibrary
3.1 Workflow Storytests
3.2 Business Calculation Storytests
3.3 Sad-path Workflow Storytests
3.4 Business-constraint storytest
4 Conclusion
2
 1 Introduction (1/4)

• In storytest-driven development,
customers write storytests – executable,
business-oriented examples – for each
scheduled story

3
 1 Introduction (2/4)

• Storytest-drven development:
– encourage clear communication of essential
business needs using concrete examples
– Clarify the domain and scope for all project
participants
– Enabling conversations that build shared
understanding among team members
– Help developers determine when new
functionality is complete as well as if any
existing functionality has been broken
4
 1 Introduction (3/4)

• Existing tools for storytest-driven

development:
– Fit framework (http://fit.c2.com/wiki.cgi?IntroductionToFit)
– FitNesse (wiki-based tool)
– FitLibrary (by author, extends Fit to improve
business-level expressiveness)

5
 1 Introduction (4/4)

• storytest-driven development is a
complementary form of test-driven
development(TDD)
• Developers take a storytest as the starting
point for their next piece of work, using TDD
when they drive changes into the application
code
• Questions arise might lead customers to
augment the storytests to cover cases they’ve
missed or to clarify of refine the terminology
6
 2 Storytest v.s. Test-driven
Development
• Similarities:
– Depend on advanced automated testing
techniques as well as traditional testing
approaches
– Ultimately more about designing than testing
• Differences:
– How they express executable examples

7
 3 Expressing Storytests
with FitLibrary
• FitLibrary:
– Extends Fit to improve storytest
expressiveness
– Encouraging a domain-driven design
approach in which the example directly
express the domain objects and business-
domain language

8
 3.1 Workflow Storytests (1/2)

• Payroll system:
– “An employee is paid a weekly wage based
on the hours worked”

9
3.1 Workflow Storytests (2/2)

Identifies the target interaction

context/domain object
Object
Specifies an assumed starting
State as a set of property-value pairs
Object Properties

Specifies a sequence of operations

In the given state’s context
Method
Specifies the system’s expected
(payEmployeeWithIdForHoursWorked)
resulting state
Figure 1. A simple workflow
storytest describing the action of
paying an employee, along with
related taxes 10
 3.2 Business Calculation
Storytests

Figure 2. This example storytest, which shows how the

organization determines ordinary and overtime hours, illustrates a
calculation rule 11
 3.3 Sad-path Workflow
Storytests

Figure 3. An example of a rejected action. In the “Add a new

contract” story, the contract is invalid because its overtime rate is
too low 12
3.4 Business-constraint
storytest

Figure 4. A business-constraint
storytest. The second row
shows the failure: the
contract id violates a
13
uniqueness constraint
 4 Conclusion (1/2)

• Storytest-driven development:
– Avoid problems that arise from the inevitable
speculation involved in upfront specification
– Reduces the need to derive independent
tests
– Reduces effort and the likelihood of
translation errors
– Helps developers determine when added
functionality is complete
– As a thinking aid
14
 4 Conclusion (2/2)

• Challenges of the storytest-driven

development:
– Managing and organizing very large suites of
storytests
– Keeping storytests consistent with the underlying
application code’s structure and naming
– Assembling a team with all the needed skills to
support high-quality storytest development
– Finding the right abstraction level for storytest

15