Upload
hani-massoud
View
215
Download
0
Tags:
Embed Size (px)
Citation preview
Writing Requirements
RightHANI MASSOUD
1
© 2
01
4 H
an
i Ma
ssou
d. A
ll righ
ts rese
rve
d.
Table of Contents
Behaviour-driven Development (BDD)
Testable Requirements (the BDD way)
Benefits
Investment
2
© 2
01
4 H
an
i Ma
ssou
d. A
ll righ
ts rese
rve
d.
Behaviour-driven Development
“Behaviour” is a more useful word than “test”Dan North, father of Behaviour-driven Development
http://dannorth.net/introducing-bdd/
Behaviour-driven Development (BDD) emerged from insights gained
during Test Driven Development.
This presentation explains a BDD approach to writing requirements that
specify the desired system behaviour.
3
© 2
01
4 H
an
i Ma
ssou
d. A
ll righ
ts rese
rve
d.
Testable Requirements
Describe system behaviour within a business context
Define Business Context
Why does the business want this system?
Who are the users and stakeholders of the system?
What business process will the system support?
What features should the system have?
Describe System Behaviour
Feature User Story Scenarios Examples
The examples are the Acceptance Tests for the system
4
Testable requirements are
the responsibility of the
Business Analyst with the
support of the Business Users,
Developers and Testers.
Recommended Reading:
• Specification by Example, Gojko Adzic,
Manning, 2011
• Lean-Agile Acceptance Test Driven
Development, Ken Pugh, Addison
Wesley, 2011
• http://dannorth.net/introducing-bdd/
© 2
01
4 H
an
i Ma
ssou
d. A
ll righ
ts rese
rve
d.
Testable Requirements
5
Feature Description 1st Release /
Iteration
Product
Catalogue
In order to make sales
As a Sales & Marketing Director
I want Visitors to be able to view products
online
1 / 1
Shopping
Cart
In order to make sales
As a Sales & Marketing Director
I want Shoppers to be able to manage Products
in their Shopping Cart
1 / 1
Daily Deals In order to make sales
As a Sales & Marketing Director
I want Subscribers to receive Daily Deals
1 / 2
Online
Payments
In order to make sales
As a Sales & Marketing Director
I want Shoppers to be able to make online
payments for their Products
1 / 3
Etc…
Features
Feature Name: <put name of feature >In order to <achieve some goal >As a <put title of stakeholder for this goal >I want <to do or enable something>.
We identify features by thinking from
the point-of-view of the stakeholders
(rather than the users).
What features do you want to buy?
Identify Features for Stakeholders
Feature Description Template
Features Stories Scenarios Examples
© 2
01
4 H
an
i Ma
ssou
d. A
ll righ
ts rese
rve
d.
Testable Requirements
6
User Stories
Title: <descriptive name of story>
Narrative:In order to <attain benefit>As a <user role>I want to <do something>.
We identify stories by thinking from
the point-of-view of the users (rather
than the stakeholders).
How will you use the system?
Identify Stories for Users
User Story Template
Note: Typically, the title describes the <do something>
part of the narrative.
Feature Story Title Story Narrative Release /
Iteration
Product
Catalogue
View Products
by Category
In order to find Products of
interest to me
As a Visitor
I want to browse Products
by Category.
1 / 1
Product
Catalogue
Add Products
to my Cart
In order to buy Products
As a signed in Shopper
I want to add Products to
my Cart.
1 / 1
Etc…
Features Stories Scenarios Examples
© 2
01
4 H
an
i Ma
ssou
d. A
ll righ
ts rese
rve
d.
Testable Requirements
7
Scenarios
Title: <descriptive name of scenario>
Description:Given <some initial context>When <an event occurs>Then <expect some outcomes>.
Scenarios are variations on a Story. Think of
the possible dimensions that affect a Story
(e.g. normal scenarios, negative scenarios,
special cases, different products, different
user role, etc.)
Identify Scenarios for each Story
Scenario Template
Source: http://dannorth.net/introducing-bdd/
Story Scenario Story Narrative Release /
Iteration
View Products
by Category
Visitor views
Products by
Category
Given a Catalogue with
multiple Categories
When the Visitor selects a Category
Then the system should display the
Products for the selected Category
1 / 1
View Products
by Category
Visitor views an
Empty
Category
Given a Category with no Products
When the Visitor selects the empty
Category
Then the system should display a
friendly message to ask the user to
select a different Category.
1 / 1
Etc…
Features Stories Scenarios Examples
© 2
01
4 H
an
i Ma
ssou
d. A
ll righ
ts rese
rve
d.
Testable Requirements
8
Examples
Typically, Examples take the form of data tables that describe the initial state (Given), the event (When) and the expected outcome (Then) for each Scenario.
Comprehensively illustrate each Scenario
with worked examples.
Examples help improve communication
between business users, developers and
testers. Examples are also the User
Acceptance Tests for each Scenario.
Comprehensive Examples by Scenario
Examples Template
Recommended Reference: Specification by Example,
Gojko Adzic, Manning, 2011
User Role User Name User Email Status
Visitor Bill Cosby [email protected] Not signed in
Shopper Fred Astaire [email protected] Signed in
Etc…
Categories Products
Shoes Glitter Strap, Flat Trendy, Snake Eyes
Dresses Sundowner, Dark Lightning
Hats Top Hat
Tops
User Action Description Selected Category
Bill Cosby (Visitor) Select a Category to browse in
the Product Catalogue
Dresses
Products
Sundowner, Dark Lightning
Given the following Users in the System
And the following Categories and Products
When the User performs the following action
Then the system should display the Products from the selected Category
Features Stories Scenarios Examples
© 2
01
4 H
an
i Ma
ssou
d. A
ll righ
ts rese
rve
d.
Testable Requirements
9
Features Stories Scenarios Examples
Living Documentation
Examples are functional
specifications and automated
acceptance tests at the same time.
They can be executed against the
system and will be Green if the test
passes or Red if the test fails. Unlike
traditional functional specifications
(which are typically incomplete and
out-of-date before the system goes
live) these are “Living” specifications
that show what the system does.
Investment in these documents is an
investment in smart documentation.
Testable Requirements are
“Living” documentation
Functional Specification is
executable. So we can run it to see if
the System behaves as specified.
© 2
01
4 H
an
i Ma
ssou
d. A
ll righ
ts rese
rve
d.
Benefits
Testable Requirements (Specifications)
Improve communication between business users, developers and testers
Are Automated by Developers and become Acceptance Tests of the system
System must pass all tests BEFORE start of UAT
UAT can reuse automated tests and add manual exploratory testing
Automated tests are necessary for DevOps
Are reusable for Regression Testing
Are “living documentation” of the system’s capabilities
10
© 2
01
4 H
an
i Ma
ssou
d. A
ll righ
ts rese
rve
d.
Investment
Behaviour-driven Requirements (Specifications)
Training – Behaviour-driven Development training, Developer tools training, etc.
Tools – Selenium WebDriver, Jasmine, Protractor, etc. (most are free, open
source projects but commercial products are needed for Mainframe, Cobol
and other legacy applications, managing test data stores, etc.)
Development - Additional development time and effort to build automated
tests
Maintenance – Automated Specifications are code and require maintenance
along with other parts of the application.
11
© 2
01
4 H
an
i Ma
ssou
d. A
ll righ
ts rese
rve
d.
Thank You
Hani Massoud
http://au.linkedin.com/in/hanimassoud/
12