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 catherine.burke@cfpb.gov and stephanie.vineyard@excella.com .

Thank you for joining us.