1501 meetup

Preview:

Citation preview

Acceptance Tests and GherkinPresenter: Stephanie Vineyard

User Stories

• Simple, clear, short description of customer valued functionality

• Representation rather than documentation

What’s A User Story?

Card Conversation Confirm

3 C’s of user stories

User Story Template

As a [type of user], I can [goal] so that

[value]

Title:

Notes:Assumptions:

Estimate:Constraints:

As a [type of user], I want [goal] so that

[value]

Title:

Notes:Assumptions:

Estimate:Constraints:

Priority:

Example

As a [type of user], I can [goal] so that [value]

Title:

Notes:Assumptions:

Estimate:Constraints:

As a coffee shop visitor, I can checkout using my credit card so that I can purchase a selected beverage.

Checkout Using Credit Card

Notes: Support mc, visa, amex

25

Constraint: Must use Chase payment service13 pts

Acceptance Criteria

As a [type of user], I can [goal] so that [value]

Title:

Notes:Assumptions:Constraints:

Test with valid mc, visa, amex passesTest with valid other cards failsTest with expired card failsTest with invalid cvv failsTest with invalid zip fails

Checkout Using Credit Card

Requirements using examples

The essence of building a program is debugging the specification.

Frederick Brooks (1987)

• Specification by Example• Executable Specifications• Scenarios• Automated Acceptance Tests (AAT)• Behavior Driven Development (BDD)• Acceptance Test Driven Development

(ATDD)• Gherkin Syntax

Common Terminology

Requirements using Examples

Elements of this Technique

Tooling

Documentation

Collaboration

18

Building in Quality

Plan Collaborate Deliver

Build the right thing

Build the thing right

Specify the right amount?

How it all relates

An Example of using an example…

gher·kinˈgərkin/noun1. a small variety of cucumber, or a young green cucumber used for pickling.

Gherkin

Business readable, domain specific language

• Given < situation >• When < action >• Then < expected result >

Gherkin syntax

25

Developing Examples

1. Feature 2. User Story 3. Collaborate 4. Scenarios 5. Examples

Background: You are developing an online ordering website for a local company that grows, harvests and sells botanicals directly to customers.Feature: Calculate customer order

Feature

1. Feature 2. User Story 3. Collaborate 4. Scenarios 5. Examples

Calculate Order Feature

Create a user story

User Story: As a customer, I want to review shipping costs in my shopping cart before checking out, so that I can see if I will receive free shipping.

User Story

Stakeholders can rank

Team can estimate

1. Feature 2. User Story 3. Collaborate 4. Scenarios 5. Examples

Collaborate

31

How do I describe what I want?

How do I validate that this work is done?

How do I code this

feature?

What are the details

of this feature?

1. Feature 2. User Story 3. Collaborate 4. Scenarios 5. Examples

Feature: Determine shipping rates

Scenario 1: Standard Shipping Rate

Scenario 2: Free Shipping Rate

Creating Acceptance Tests

32

1. Feature 2. User Story 3. Collaborate 4. Scenarios 5. Examples

Scenario: Standard Shipping RateGiven I am a customerAnd my order amount is $49.99When I view my cartThen I see that shipping costs are $3.99

Scenarios

Scenario: Free Shipping RateGiven I am a customerAnd my order amount is $50.00When I view my cartThen I see that shipping costs are $0.00

Scenario OutlinesFeature: Determine shipping rate

Scenario Outline: Standard shipping rate• Given that I am a customer• And my order amount is <order amount>• When I view my cart• Then I see that shipping costs are <shipping cost>

Examples: | order amount | shipping cost | $49.99 | $3.99 | $50.00 | $0.00 | $75.00 | $0.00

Create your acceptance tests

• Imperative– Descriptive– Step-by-step instructions– Heavier reliance on the user interface

• Declarative– Informative– Abstracts details– Limits reference to specific user interface

behavior

Gherkin Styles

Feature: Validate userScenario: User with valid credentials returns to orderImperative (Narrative)

Given I am an unauthenticated userAnd I am on the login pageAnd I enter a valid name in the Name fieldAnd I enter the corresponding password in the Password fieldWhen I select the Login buttonThen I should see the welcome page

Imperative Style

Implementation Detail – what if decide to use Token-based authentication or single sign-on?

UI Detail – what if the user interface changes and you select name from a drop-down list or select a radio button?

Feature: Validate userScenario: User with valid credentials returns to orderDeclarative (Informative)

Given I am an unauthenticated userAnd I am on the login pageWhen I submit valid credentialsThen I should see the welcome page

Declarative Style

Feature: Validate userScenario: User with valid credentials returns to order

Side-by-side Comparison

Imperative (Narrative) Declarative (Informative)Given I am an unauthenticated userAnd I am on the login pageAnd I enter a valid name in the Name fieldAnd I enter the corresponding password in the Password fieldWhen I select the Login buttonThen I should see the welcome page

Given I am an unauthenticated userAnd I am on the login page

When I submit valid credentialsThen I should see the welcome page

— If the user interface is constantly changing, it is better to use imperative.

— Declarative is easier to maintain.

— Developers prefer the imperative style.

— If a stakeholder is concerned about the user’s interaction experience, use imperative.

— Declarative specifies implementation details.

True or False?

F

T?T

F

Automated testing is an Agile practice

• Frequent and immediate feedback on software quality

• Courage and creativity

• Always delivering working software

Test automation

Path to automation