Making the Move to Behavior Driven Development RYAN YACKEL | DIRECTOR of PRODUCT

Making the Move to Behavior Driven Development RYAN YACKEL | DIRECTOR OF PRODUCT

• Testing Experience: CGI Group, Macy’s IT

• BDD Experience: PM for qTest Scenario, Cucumber Training

• Hobbies: Love Coffee & Comics

Ryan Yackel Director of Product

Our Vision Transform the Way Global Enterprises Create Quality Software

• Corporate Headquarters: Atlanta, Georgia

• Global Offices: London (Sales), Vietnam (Development)

• Customer Growth: June 2014: 150 customers | Jan 2018: 600+ customers

• Funding: Raised $50m equity

• Key Customers: USAA, Nordstrom, Office Depot, Verizon, Amazon, Samsung, Cisco, Visa, Lowe’s, Sony

• Technology Partners: Atlassian, CA, TestPlant , Neotys, GenRocket, Katalon, APIFortress

• Channel Partners: cPrime, Clearvision, Go2Group, Rightstar, Capgemini, MouSoft, Aservo, Column Technologies

© 2018 QASymphony – Confidential & Proprietary Agile Test Management Organize and manage all test activities in one central location. Real-time integration with Jira Agile and DevOps Workflows and other Agile ALMs. Exploratory Testing Event driven rules engine Intelligently capture designed for workflow exploratory test sessions to automation for qTest products. create robust documentation and automated test scripts.

The #1 Enterprise Testing Platform for Agile Teams

Enterprise BDD for Jira Centralized Test Automation Jira add-on that integrates with Centrally manage, schedule, qTest Pulse to scale BDD, and and report on test automation ATDD in their DevOps pipelines. BI & Analytics Hub executions across complex Advanced reporting and BI environments. hub for all testing activities across the enterprise. © 2018 QASymphony – Confidential & Proprietary Come See Us!

Why BDD? History and Industry Principles of BDD Demo Workflow Assessment of BDD Q&A

…rather it is “How are you approaching your test automation with development?”

Test Driven Development brings several major benefits to organization, most notably:

1. Move Testing Up Front – prevents having to rush testing at the end of the cycle 2. Bake in Automation from Day 1 – protects against getting behind with test and automation coverage 3. Build More Testable Software – requires developers to think about testability, and create more robust software 4. Push to Customers When Ready – allows you to push software to customers just in time, as it is developed

Test-first Approach

Test-First methodologies were coined “Test Driven Development”. Less technically focused versions called Acceptance Test Driven Development (ATDD) and Behavior Driven Development (BDD) also emerged:

Test Driven Development (TDD)

Acceptance Test Unit Test Driven Behavior Driven Driven Development Development BDD Development (“Technical TDD”) (ATDD)

RISK LEVEL

Acceptance Freaking Out Tests Oh, no…

Integration Semi-Confident Tests I think we got this covered

Unit Tests Super Confident We for sure have this covered.

Festering Problems Code Code Automation Confusion

Automation frameworks without feature visibility create business confusion around application coverage. • Automation becomes pure code, without clear understanding of test coverage What Are • QA doesn't know if test coverage is sufficient We Testing?

Communication Breakdowns Code INSERT PHOTO ON TOP Features and requirements change during Agile and DevOps sprints. If automation is disconnected from these features, we Code might be testing a changed feature set without know it. Code Automation Scripts • Changes are discovered after automation is completed • Automation is never updated to reflect adequate coverage Code Code

39%

TDD 16% ADOPTION BDD ADOPTION

1. Increased collaboration

2. Easier transition to test automation

3. Structured organization and guidance

4. Better alignment between businesses and customers

5. Alignment between Product / Dev / Test

+ “We collaborate, we record that collaboration in some form of Driven specification and then we automate + that specification to drive out the implementation.” Development

Behavior Driven Development

Collaborate Owner, Dev, Test, design acceptance criteria

Record Full Testability Document common syntax for all

Automate Execute test scenarios that validate behavior

Almost Always, Stories Have LITTLE Information

1. Write the story on a yellow card 2. Write each rule/acceptance criteria on a blue card 3. Write examples on green cards under each rule 4. Write any questions on red cards 5. Keep going until everyone understands the story 6. Stop after 30 mins

© 2018 QASymphony – Confidential & Proprietary source: Matt Wynne - https://cucumber.io/blog/2015/12/08/example-mapping-introduction Record - Specification by Example Three Amigos Living Documentation Feature: Serve Coffee in BDD Coffee should not be served until paid for Coffee should not be served until the button has been pressed If there is no coffee left, then the money should be refunded Dev Scenario: Buy Last Coffee Given There are 1 Coffees left in the Machine Product And I have deposited $5 Tester And I previously have $100 in the bank Owner When I press the coffee button Then I should be served a coffee

Briefing Estimate Prioritise Story Prepare Title Description Priority Value Proposition Measures Estimate Ready Sketch Specification A/C Notes Refine Workshop NFRs Key Examples Design Notes Wireframes Assumptions Done

Scenario Definition Build Review & Demo Explore Scenario Automate Automation

Feature Implementation PO / Customers Review Value returned Metrics Developers Monitor Evaluate Bugs Review New Stories Testers

Tests Cases Test Scenarios

Step 1, 2, 3 Given…When…Then

Requirements Features / Specifications

Static Behavior Living Documentation

Separate Teams Embedded Teams

Step Expected Actual Feature: Serve Coffee Description Result Result Coffee should not be served until paid for Coffee should not be served until the button Walk up to machine Machine is present has been pressed If there is no coffee left, then the money Select Coffee Buy Coffee selected Columbian Coffee should be refunded Selected Enter money Machine takes Machine only took Scenario: Buy Last Coffee money cash Given There are 1 Coffees left in the Machine Press Button Coffee Comes Coffee didn’t And I have deposited $5 out come out…maybe And I previously have $100 in the bank I didn’t have When I press the coffee button enough money? Then I should be served a coffee

Example of BDD Within Continuous Integration BDD in DevOps

BDD

Gina Product Owner

Joseph Test Engineer

? ?

Gina Joseph Ryan Product Owner Test Engineer Developer

Changes Synced in Real-time Gina Fail feature for TDD Product Owner

Joseph Ryan Test Engineer Developer

Source: http://hanwax.github.io/assets/tdd_flow.png Gina Automate to Pass Product Owner

Add Automated Steps & Implement

Joseph Ryan Test Engineer Developer

Source: http://hanwax.github.io/assets/tdd_flow.png Assessment

How do I understand business value? Report

How do I automate BDD process? Workflow How do store & manage test scenarios? Management How do I enforce BDD Structure? Collaborate

Increased Customer Value

SETUP NO REPORTING SOFTWARE STORE FOCUS ON FEATURES PROCESS AS CODE LEARN CORRECT GHERKIN SMALL DECENTRALIZED TEAM CI EXAMPLE ADOPT WORKFLOWS MAPPING CUCUMBER

1. BDD is an extension of TDD

2. BDD is about continuous conversation, not test automation

3. Organizational buy in is a must for success

4. Start lean, and prove it out before mass adoption

5. Alignment between Product / Dev / Test