6. • Often software development results surprises at the
end
• The business being unable to define the desired
outcomes
• Ambiguity in the developer’s and tester’s understanding of
what needs to be built
• The business not able to understand the technical
challenges or unable to look at tester’s view on the
requirement
7. Introduction
• Three roles, three steps (document specification,
write code; develop the app, write test plan;
test the app)
• Three specs and three different lifecycles
• Mostly we maintain three different versions of system’s
need and many times find conflict among them
• Functional Specification document
• Source Code
• Test case and test plan document
9. Behavior Driven Development
(BDD)
• Exploring the unknown
• Sharing and understanding
• Individuals and interactions over processes and
tools
• Describes what business wants the system to do by
talking through example behavior.
10. Conversation Focused
• BDD is
• Conversation among
Three amigos
• PO/BAs
• Developers
• Testers
• Example based
• Value-Driven
• Outside-in
11. Ubiquitous Language
• To make sure that the whole team understand what's
wanted, the behavior is described in non-technical
language.
• Gherkin language (given, when, then)
• Gherkin is a Business Readable, Domain Specific Language
that lets you describe software’s behaviour without detailing
how that behaviour is implemented.
• Simple syntax, few keywords
• Feature
• Background, Tag
• Scenario, Scenario Outline
• Given, When, Then
• Localized to 35+ languages
12. Better collaboration
• If you are using any BDD tool and there is no
collaboration then it’s not BDD
• Improved collaboration among three amigos BAs,
Developers and Testers
17. DevOps
• As per wikipedia
• DevOps is more than just a tool or a process
change; it inherently requires an organizational
culture shift.
• This cultural change is especially difficult
because of the conflicting nature of
departmental roles.
• Operations seeks organizational stability;
developers seek change; and testers seek risk
reduction.
• Getting these groups to work cohesively is a
critical challenge in enterprise DevOps adoption
18. Devops
• Need better collaboration
• One team, One goal
• Deliver Value - > Stable Value -> Fast Value ->
Continuous Deliver Value
19. Devops collaboration
• Ops + Support participates in the continuous
improvement team dynamics
• Retrospective meeting
• Dev & Ops work together to anticipate Ops actions
on what will be delivered
• Ops + Support are aware of Devs process
(ceremonies, iterations, roles, etc.) and vice versa
20. Addition of 4th amigo - Ops
• Include Ops in BDD Conversation along with Three
amigos
• BAs
• Developers
• Tester
• Ops
22. Scenario discovery and analysis
• Ops + Support should participate in BDD scenario
identification.
• Ops able to inform about business stakes and
constraints, about their product and its
dependencies.
• Ops+ Support able to provide their perspective
• Requirements related to operations (production and
deployment) should get defined (e.g. logs, metrics).
• These should be applied for each User Story.
Requirements which are specific to a User Story are
defined before development (e.g. toggle feature).
• Type of tests they execute before deployment
23. Benefits
• Break the silos
• Common language
• Dev gain knowledge on product from Ops
perspective
• Support gain knowledge on new features by
manipulating the product
• Dev and Ops share their tools (monitoring tools,
jira, etc.), data (logs, etc.) and metrology (KPI,
dashboard, feedbacks) in a mutual way.