Webinar "From user stories to automated acceptance tests with BDD" por Eduardo Riol, QA & Testing Community Technical Leader en atSistemas.

1. www.atsistemas.com
From user stories to Automated Acceptance Tests with BDD
Eduardo Riol

2. I’m Eduardo Riol, QA & Testing Community Technical Leader in
atSistemas, where we are enthusiasts of Software Quality Assurance,
Tests Automation and Testing best practices.
I started as developer in Java and .NET environments more than a decade
ago, but I’ve been involved the last eight years in Software Quality, both
products and development processes oriented.
Currently my interests are focused in the integration of QA activities in
Agile and DevOps environments, technical debt control and BDD.
Lately I research about other topics like Security and Blockchain.
twitter.com/eduriol
github.com/eduriol
linkedin.com/in/eduriol
Who am I?

3. 3
We are a dependable partner, with a long trajectory and a solid
future in the industry
of revenue in 2017
54,5 M€ estimated for
2018
Present in every
industry
Spanish capital
Presence in Madrid,
Barcelona, Cádiz,
Zaragoza, A Coruña,
Mallorca and Huelva
International vocation
And currently IT referent in Innovation
Expert Centers and cutting-edge
Technological Communities,
leaders in Digital Transformation
IT professionals
of proved Technical Solvency
growth in international
interannual billing at 2017
closure
atSistemas
45,6 M€
100%
1994Founded in
R&D
1000
16,5%

4. Houston, we have a problem!
“This is not what we asked for” Does that ring a bell?

5. Houston, we have a problem!
Chine
se
whisp
ers The Gossips, Norman Rockwell, 1948
“This is not what we asked for” Does that ring a bell?

6. We focused on developing software CORRECTLY…
Functional
testing Unit testing
Performance
testing
Integration
testing
Static analysis
Ethical
hacking
Process audits
UAT

7. … but do we develop the CORRECT software?
Features Used
The Standish Group estimate of features used in custom application development, 2014
Hardly Ever
50%
Often
20%
Infrequently
30%

8. Features Used
The Standish Group estimate of features used in custom application development, 2014
Hardly
Ever
50%
Often
20%
Infrequently
30%
… but do we develop the CORRECT software?

9. We don’t trust releases

10. Most of the time we don’t have an
acceptance tests suite robust and
complete enough to be trusted
We don’t trust releases

11. Lack of documentation
Individuals and interactions OVER processes and tools
Working software OVER comprehensive documentation
Customer collaboration OVER contract negotiation
Responding to change OVER following a plan
We are
uncovering better
ways of
developing
software by doing
it and helping
others do it.
Through this work
we have come to
value:
That is, while
there is value
in the items on
the right, we
value the items
on the left
more.
The Agile manifestoThe Agile manifesto

12. How often have you finished a project in which technical
documentation is up-to-date with what software really does?
Individuals and interactions OVER processes and tools
Working software OVER comprehensive documentation
Customer collaboration OVER contract negotiation
Responding to change OVER following a plan
We are uncovering
better ways of
developing
software by doing
it and helping
others do it.
Through this work
we have come to
value:
That is, while
there is value
in the items on
the right, we
value the items
on the left
more.
The Agile manifestoThe Agile manifesto
Lack of documentation

13. And collaboration within the team?
We have
Quality issues
Ain’t my problem,
Software Quality is
what testers should
care about, isn’t it?

14. Devs? I think those are the
guys in the 4th floor or
something
Dev people keep returning
unresolved bugs
And collaboration within the team?
We have
Quality issues
Ain’t my problem,
Software Quality is
what testers should
care about, isn’t it?

15. This problem starts from here
• Analysis
• Development
• Testing
• Operations
As separated phases, estimated
and planned from the beginning of
the project

16. This problem starts from here
As separated phases, estimated
and planned from the beginning of
the project
• Analysis
• Development
• Testing
• Operations

17. BDD: How Devs and Business collaborate
BDD is a collaboration model between Business users and
Development team…
… consisting of establishing conversations based in concrete
examples of the application use, with the objective of reducing
misconceptions and assumptions…
… discovering during the process the features that truly provide
value

18. • Examples describing a new feature are
translated to a simple and common language,
without ambiguities (for example Gherkin)
• Development team transforms these examples
to a series of executable specifications as
automated tests
• A software feature will be completed whenever
every specification executes correctly
BD
D
TDD
Write a failing test
N cycles
BDD: How Devs and Business collaborate

19. Then, what is (and what not) BDD?
• Writing requirements
in Gherkin language
• Automating tests with
Cucumber
• Documenting
functionalities after
programming them
• A collaboration model
• A discovering process
• Understanding
Business needs
• Describing software
with examples
What it is What it’s not

20. Three amigos
Business QA
Dev

21. Three amigos
1. PO talks with
Business about its
needs
2. The PO, a Dev and
a Tester meet to
elaborate scenarios
jointly
4. The scenarios
guide the dev and act
as automated tests
3. The tester
implements the
scenarios as
acceptance tests
5. Automated tests
provide feedback
about progress and
document the
application

22. A collaboration scenario
We want our application to
require a password with at least 8
characters, a number and a
capital letter
Don’t you mean you want
the application to require a
strong password?

23. Password strenght, xkcd, Randall Munroe
Password Security Accepta
ble?
secret Weak No
password Weak No
password1 Weak No
aBcdEfg1 Weak No
qwertY12 Weak No
dJeZDip1 Medium Yes
SeagullHedgehog Strong Yes
SeagullHedgehogC
atapult
Very
strong
Yes
A collaboration scenario
We want our application to
require a password with at least
8 characters, a number and a
capital letter
Don’t you mean you
want the application to
require a strong
password?

24. Discovering our Business
“In software development, ignorance is the constraint. You know a lot more about the
best way to build a particular solution after you’ve finished building it, but by then it’s
too late to take advantage of your knowledge.”
John Ferguson Smart, BDD in action, 2015

25. Implementing BDD: Describing scenarios
SCENARIO
Sending
Contact Form
Given John Doe enters contact form
And he fills the fields with his data and the
message
And accept legal clause
When he sends the query
Then the confirmation message is received
Given: Defines the context in which the
scenario is executed. In this step the starting
point for the example is established.
When: It’s the action that triggers the
example. It consists of an interaction with the
application, usually by a user, whose behavior
we want to validate.
Then: In this step the result expected by the
Business is defined, meaning the condition
that must be fulfilled for the scenario to be
considered correctly executed.

26. Implementing BDD: Automating scenarios
Scenario: Transfer money to a Savings account
Given my Checking account has a balance of 1000.00
And my Savings account has a balance of 2000.00
When I transfer 500.00 from my Checking account to my Savings account
Then I should have 500.00 in my Checking account
And I should have 2500.00 in my Savings account

27. Scenario: Transfer money to a Savings account
Given my Checking account has a balance of 1000.00
And my Savings account has a balance of 2000.00
When I transfer 500.00 from my Checking account to my Savings account
Then I should have 500.00 in my Checking account
And I should have 2500.00 in my Savings account
@Given(“^my (.*) account has a balance of (d+)$")
public void setupInitialAccount(AccountType accountType,
double amount) {
// Setup account
}
@When(“^I transfer (d+) from my (.*) account to my (.*) account$")
public void transferAmountBetweenAccounts(double amount, AccountType source, AccountType destination) {
// Perform action
}
@Then(“^I should have (d+) in my (.*) account$")
public void checkAccountAmount(double amount, AccountType accountType) {
// Assert amount
}
Implementing BDD: Automating scenarios

28. Exploratory
Testing
BDD levels: The Testing pyramid
UI
API / Services
Unit
Prevent errors / Provide value

29. UI (manual & automatic)
API / Services
Unit
Detect errors / Certify releases
Exploratory
Testing
BDD levels: The Testing pyramid
UI
API / Services
Unit
Prevent errors / Provide value

30. BDD in the software building process
Scenarios execution should be part of the software integration,
building and deployment process.
Each scenario should be able to be executed separately, without any
concrete order. There should be no dependency between scenarios.
Scenarios are a code asset to be maintained under version control
systems.
The software building and deployment process additionally becomes a
process for building and deploying documentation and reports.

31. Reports: feature readiness
A feature is considered
ready to be deployed in
production whenever its
scenarios execute
correctly.
Feature readiness
Your business does not care whether your tests pass or not. What they want to know is
if the functionality is ready to be deployed in production.

32. Reports: feature coverage
Feature coverage shows
the % of features with
every defined scenario
executing correctly.
Feature coverage

33. Warning!, BDD is not a silver bullet
Business implication: We need the stakeholders involved
since the beginning of the project.
BDD is thought for Agile: it is a collaboration model to
fostering an iterative discovering of the requirements.
BDD doesn’t like silos: if the organization works in
isolated silos and collaboration doesn’t flow, the
progressive clarification of goals disappears.
Risk of high cost in test maintenance: experience and
knowledge are required in order to design maintainable
functional specifications and implement them correctly.

34. Technologies for BDD

35. Nuestro catálogo de servicos
QA de GOBIERNO• Testing funcional
• Pruebas de Sistema
• Pruebas de Seguridad
• Pruebas de carga/rendimiento
• Análisis y control de la deuda técnica
• Definición y mejora de los procesos de
gobierno, ingeniería y calidad para la
Transformación Digital
• Formación en buenas prácticas de
desarrollo
• Implantación de una Oficina de Calidad
AGILE QA
• Apoyo metodológico
• Servicios de automatización en el
marco de un proceso de Entrega
Continua
• Automatización de pruebas
QA OPERATIVO

36. www.atsistemas.com
902 888 902
GRACIAS
Madrid
Oficinas Centrales:
C/Valle de Alcudia 3, Ed. 2
28232 - Las Rozas - Madrid
Selección y Recursos Humanos:
C/Acanto 22, Plta. 3
28045 - Madrid
C/Retama 7, Plta. 1
28045 - Madrid
Barcelona
Plaça de Catalunya 21, Plta. 2
08002 - Barcelona
Cádiz
Edificio Jerez Parque Empresarial, C/ del Desarrollo 2, Plta. 1
11047 - Jerez de la Frontera - Cádiz
Zaragoza
Centro Tecnológico TIC XXI, C/Bari 57, Plataforma Logística (PLA-ZA)
50197 - Zaragoza
A Coruña
Edificio Mans Polígono de Pocomaco, Parcela D22
15190 - A Coruña
Palma de Mallorca
Regus Palma Polígono de Son Castello, C/ Gremi de Sabaters 21, Plta. 2
07009 - Palma de Mallorca
Huelva
Parque Científico Tecnológico de Huelva, Edificio PCTH2000
21 110 - Aljaraque - Huelva