Embed Size (px)
Citation preview
Use it to describe User Storiesand Acceptance Criterias
1. Difficulties to localize feature documentation described in some US,
developed some sprints in the past.
2. Difficulties to keep feature documentation and tests synchronized.
3. Difficulties to have a unified language across the team(PO, QA and Devs).
4. Difficulties to check the health of all features.
Motivation behind this idea
BDD (Behavior-Driven Development): Way to create testable and
automated behaviors that add value to the client before the
existence of the source code, prevent behavior-based defects
and generate a set of regression tests based on these
behaviors.
What is BDD
The Main goal of BDD for us is give to non-technical and
technical team a unified language to describe the requirements
and keep it synchronized with test that will guarantee to
clients the quality of the product.
BDD for us
How it Works
1. PO get requirements from client.
2. PO write US in the BDD description style:GIVEN - WHEN - THEN
3. QA and DEV Team write corner cases scenarios.
4. QA and DEV Team write the test code for features
5. DEV Team implement the functionallity.
6. Client and PO Happy because are able to check the Cucumber Reports in order to be updated about the features progress.
Feature: Get BDD US description from RallyDev
Get BDD US description from RallyDev and save in a Cucumber descriptor file
Scenario: Get BDD US description from RallyDev and save in a file
Given The user have permissions to access RallyDev and it is up and running
When User run bdd_tool passing the parameters
Then A file should be saved in the BDD_Tests folder with the USs descriptions
Describing USs and Acceptance Criteria
Given(/^The user have permissions to access RallyDev and it is up and running$/) do
headers = RallyAPI::CustomHttpHeader.new()
headers.name = "Catbert BDD Tool Utility"
headers.vendor = "HP"
headers.version = "1.0"
config = {:base_url => "https://rally1.rallydev.com/slm"}
config[:username] = "[email protected]"
config[:password] = "#hp204205hp#"
config[:workspace] = "IPG-IWS-PTP"
config[:project] = "Print from URL"
config[:headers] = headers
raise AssertionError if RallyAPI::RallyRestJson.new(config).nil?
end
When(/^User run bdd_tool passing the parameters$/) do
$result = system("ruby #{File.expand_path('../.')}/bdd_tool_cli.rb -u '[email protected]' -p '#hp204205hp#' -s 'US15335'")
end
Then(/^A file should be saved in the BDD_Tests folder with the USs descriptions$/) do
raise AssertionError unless $result
raise AssertionError unless File.exist?("#{File.expand_path('../.')}/bdd_tool_cli.rb")
end
Test code behind the US Description
Feature: Show products catalog
Show a list of products
If there is no products in catalog should show a message "..."
Scenario: Get products
Given The storefront is open
When The user click in the list catalog link
Then The user should see the catalog list page
Scenario: Get empty catalog
Given The storefront is open
When The user click in the list catalog link
Then The user should see the message "There is no products for your country!"
Describing USs and Acceptance Criteria for Interfaces
Feature: Show products catalog
Show a list of products
If there is no products in catalog should show a message "..."
Scenario: Get catalog
Given The service is listening for requests
When The client request a list of products
Then The HTTP code response should be 200
And The response should be the JSON:
{ products: [ {name: "products1"}, {name: "products2"} ] }
Describing USs and Acceptance Criteria for REST API
Feature: Migrate Services from Plataform X to Y
Have everything working in Y environment.
Scenario: Check services in new Plataform
Given The regression tests pointing to new servers
When The regression tests execution are completed
Then The reports result should not be changed
Describing USs and Acceptance Criteria for eOPS
Report showing status of feature and scenarios
● Having documentation as tests, there is no chance of having tests and
implementation delivering something different than desired.
● The BDD documentation works as a contract that guarantee the client needs.
● The client could check the tests reports, in order to be updated about the
progress of features requested.
● An easy and centralized local to everyone clients and team consult the
feature status and descriptions.
The main results obtained from this approach
