The Communication Problem Solved with Cucumber Mary Thorn
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
The Communication Problem Solved
with Cucumber
Mary Thorn
About me(Mary Thorn)
l QA Manager at iContact.
l Over 15 years of QA experience working in the following areas: Healthcare, HR, Agriculture and SaaS-based products.
l Have a broad testing background that spans automation, data warehouses to web-based systems in a wide variety of technologies and testing techniques.
l Heavy interest in Agile Testing Methodologies and direct experience leading Agile teams in the SCRUM Software Development Lifecycle (SDLC).
l 5 years of experience with building automation frameworks
Agenda
l Introduction
l The Communication Problem
l What are Acceptance Tests?
l Simple Example
l Acceptance Testing with Cucumber
Acceptance Criteria for Presentation
Goal: Presenter would like to have a successful presentation
Acceptance Criteria: 1. Verify the attendees stay awake 2. Verify the attendees are happy with the
presentation
The Communication Problem
The Challenge: l Today, the most difficult problem in software
development is knowing what to build, not how to build it.
l Knowing what to build, requires knowing why it is being built. In other words, understanding the goal.
The Communication Problem
The Problem: l Stories typically concentrate on the what and
the how, not the why. Goals and examples are usually missing.
l Stories are usually a list of imperative requirements (acceptance criteria).
l Imperative requirements are usually interpreted in subtly different ways by each person. If goals and examples are absent, misinterpretation is much more likely.
The Communication Problem
Example: l Requirement: Draw a star with 10 points.
OR
The Communication Problem
Solution: Specification by Example l People understand requirements best using
concrete examples.
l Examples clear up ambiguity and misunderstandings.
l Examples expose missing requirements.
l Examples force everyone to think harder about a problem.
The Communication Problem
Specification by Example l This is the basis of acceptance testing and
Behavior Driven Design (BDD).
l It is critical that everyone participates in creating the examples so that the understanding is shared.
l Ultimately, acceptance testing is less about the example itself and more about the conversation required to create the example.
What does this have to do with automated
testing?
What are Automated Acceptance Tests?
In a nutshell, automated acceptance tests are
executable examples that define the system's
specifications.
What are Automated Acceptance Tests?
Acceptance Tests are l Formal examples that define requirements.
l Executable.
l Self-explanatory and readable by all team members.
l Tests of business rules.
l A living specification of system behavior.
What are Automated Acceptance Tests?
Acceptance Tests do NOT l Test pieces of code in isolation. They are not a
substitute for unit and integration tests.
l Verify the entire system.
l Verify all permutations of a piece of functionality.
l Use mock objects except to remove a dependency on an external 3rd party.
What are Automated Acceptance Tests?
Benefits: l Higher quality b/c everyone shares the same
understanding of the requirements and builds it right the first time.
l Tests become the system's regression suite.
l Create an objective verification of “done-ness” for a story. A story is done when all tests pass.
l Create transparency into progress on a story.
l Manual testers are part of the automation process.
l Allows for more exploratory testing b/c happy path is automated
Simple Example
Acceptance Criteria: Transactions are rounded to the nearest cent.
Original Value Rounded Value $0.021 $0.025 $0.029
$0.02
$0.02 $0.02
Simple Example
Why was there confusion?
The goal was missing...
Goal: Create a currency conversion system.
The Concrete Example clarified what was meant by the acceptance criteria. Refined Acceptance Criteria: Transactions are always rounded down to the nearest cent.
Simple Example
l This simple example is a REAL EXAMPLE in a system that was well-tested and approved by all parties.
l Attacker was able to steal > $15,000 starting with a single cent using this process...
l $0.01 → 0.0051 € rounded to 0.01 €
l 0.01 € → $0.0196 rounded to $0.02
l A seemingly minor ambiguity in the requirements was very expensive.
Take Aways
l Concrete examples drive understanding and consensus.
l To create good representative examples, everyone must understand the goal of the story.
l For technical people to properly understand the goal, they must understand the business domain.
What does Cucumber have to
do with this?
Cucumber
• Cucumber lets software development teams describe how software should behave in plain text. The text is written in a business-readable domain-specific language and serves as documentation of requirements, automated regression tests and development-aid - all rolled into one format.
• Cucumber works with Ruby, Java, .NET, Flex or web applications written in any language. It has been translated to over 40 spoken languages.
Automated Testing Cucumber Framework
Components: Cucumber (Framework)
HTMLUnit (Browser Emulator)
Celerity/Selinium/Watir (Browser Emulator API)
Features (Tests written in sentence format)
Step Definitions (Backend code to support Features)
Automated Testing Linking it all together
Command line – Rake TAGS - @abc
Cucumber Framework - Tags
Feature File - Sentence
Step Definition File – Matching Sentence
Terminal Result Output-
Browser Emulator Celerity/Selinium/Watir – Execute Command
Automated Testing Process
Process: • Product Owner writes acceptance tests in feature file
scenarios.
• During grooming the team discusses the scenarios and asks questions.
• Once story is committed to work the developers write tests and then code and then run tests.
• QA expands the scenarios in the feature files.
• When testing is complete PO acceptance is done by running the acceptance tests.
Cucumber
A Cucumber test consists of 2 components:
1. The Feature files which contain the test Scenarios.
2. The Step Definition files which contain the Ruby “glue” code that connects the tests to the application.
Cucumber
Feature File Overview: l Written in plain text
l Define the test suite and contain the actual tests which are called Scenarios
l Written collaboratively by everyone on the team (PO, QA, and Dev)
l QA can run these manually.
Cucumber
Feature Files: l Suite is defined by keyword “Feature:” followed by a
description.
l Individual tests are defined by “Scenario:” followed by a unique name. Scenarios are concrete examples of how we want the software to behave.
l Tests have 4 reserved words that begin each line: Given, When, Then, And.
l “Background:” that is run before each test so that you don’t have to repeat steps.
Cucumber
@Cucumberpresentation Feature: User would like to have a successful presentation Tests the following acceptance criteria: 1. Verify the attendees are awake 2. Verify the attendees are happy with the presentation @Attendeeawake Scenario: Verify the attendees are awake Given that I am an attendee When I have drunk caffeine Then I will be able to listen to the presenter @Attendeeishappy Scenario: Verify Attendees are happy Given I am the presenter When I talk slow And my content is interesting Then the attendees will be happy
Cucumber
Wrap up:
• Cucumber is a functional test automation tool for lean and agile teams.
• It supports behaviour-driven development, specification by example and agile acceptance testing.
• You can use it to automate functional validation in a form that is easily readable and understandable to business users, developers and testers.
• It helps teams create executable specifications, that are a goal for development, acceptance criteria and functional regression checks for future changes.
• Allows teams to create living documentation, a single authoritative source of information on system functionality that is always up-to-date.
• Allows manual testers to be involved in automation, as well as, frees them up from testing the “happy path” to be able to real exploratory testing.
Cuke4PHP
QUESTIONS?
Related Documents
![[Agiles 2011] Agile communication with near-shore](https://static.cupdf.com/doc/110x72/55cf7a9dbb61eba3768b45fd/agiles-2011-agile-communication-with-near-shore.jpg)
![Communication Support to Scrum Methodology in Offshore ...830110/FULLTEXT01.pdf · The problem with agile method is when applying in offshore development [15]. In offshore development,](https://static.cupdf.com/doc/110x72/5ec5ee00e9422601c50f7ff0/communication-support-to-scrum-methodology-in-offshore-830110fulltext01pdf.jpg)
