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.

1. Use it to describe User Stories
and Acceptance Criterias

2. 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

3. 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

4. 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

5. 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.

6. 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

7. 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] = "geison.goes@hp.com"
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 'geison.goes@hp.com' -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

8. 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

9. 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

10. 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

11. Report showing status of feature and scenarios

12. ● 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

13. Contact me
●
○
●
○
●
○
●
○