Making testable requirements a reality Lessons learned by an Agile team
Greetings
§ Transition to Scrum
§ Testable Requirements
§ Automated Testing
2
Transition to Scrum
3
Common Misconceptions
Chaos
4
Agile
Best practices for scrum transition
5
Respect
Openness
Commitment Courage
Focus Whole Team
Continuous Improvement
6
Reflect
Adapt
Changes for Business Analysts
§ Continuous engagement throughout project lifecycle
§ Short intervals, light weight requirements
§ Adapt business analysis techniques and deliverables
7
Testable Requirements
8
The essence of building a program is debugging the specification.
- Frederick Brooks (1987)
9
Writing Testable Requirements
§ Collaborative Conversations ¨ Develop shared understanding of the requirements ¨ Elicit examples of expected business value
§ Acceptance Tests ¨ Driven by business need ¨ Implementation details for the feature
¨ Business specific language
10
Light-weight, living documentation
§ Describe working software
§ Update when ¨ Requirements change ¨ New features are implemented
¨ Defect discovered
11
Gherkin Acceptance Tests
12
Collaborative Test Writing
Build the right thing
Build the thing right
13
14
gher·kin ˈgərkin/ noun 1. a small variety of cucumber, or a young green cucumber used for pickling.
https://www.flickr.com/photos/ogil/
Gherkin syntax
¨ Given <situation> ¨ When <action> ¨ Then <expected result>
15
16
User Story Acceptance Criteria
As a Meeting Facilitator I want to buy a caffeinated beverage So that I am alert for my afternoon meetings.
1. There is a shop nearby to buy caffeinated beverages
2. The caffeinated beverage of my choice is available in the shop
How a User Story Becomes Acceptance Tests
How a User Story Becomes Acceptance Tests
Feature: Caffeinated beverages for meeting facilitators Scenario 1: Buy a cup of coffee § Given that I prefer coffee
§ When I enter a coffee shop
§ And I place my order
§ And I pay for my order
§ Then I receive a cup of coffee
17
Scenario 2: Buy a cup of tea § Given that I prefer tea
§ When I enter a tea room
§ And I place my order
§ And I pay for my order
§ Then I receive my cup of tea
How a User Story Becomes Acceptance Tests
18
Feature: Caffeinated beverages for meeting facilitators Scenario Outline: Buy a caffeinated beverage § Given that I prefer <beverage>
§ When I enter a <shop>
§ And I place my order
§ And I pay for my order
§ Then I receive my <beverage> Examples: | beverage | shop | coffee | coffee shop | tea | tea room | high caf soda |convenience store
Gherkin style
19
§ Imperative style ¨ “How” you want machine to
act, and “what” happens as a result
Moved from Towards
§ Declarative style ¨ “What” you want machine to
do, and “how” is determined by the computer
Where we’re going
20
Test new features
§ Definition of Done
§ “Did we build the right thing?”
§ Execution of business facing Acceptance Tests
21
Regression Testing
§ Challenges of manual regression testing ¨ New features create more complexity in application ¨ Dull, repetitious activity
¨ Time to execute manual tests increases as new product features are added
§ Opportunity cost of manual regression testing ¨ Delays release of new software
¨ Delays discovery
22
Automated testing is an agile practice
23
What makes test automation an agile practice?
§ Provides frequent and immediate feedback on software quality
§ Courage and creativity with a safety net
§ Always delivering working software
24
Path to automation
§ Automation takes time and effort
§ Separate software development project
§ Balance level of effort to automate with value provided
§ Prioritize test automation efforts
§ Management support required
§ Return on investment ¨ More efficient software delivery team ¨ Higher quality software
25
You can reach us with more questions or for other information at [email protected] and [email protected] .
Thank you for joining us.
