Behaviour driven development aka bdd
-
Upload
prince-gupta -
Category
Technology
-
view
97 -
download
1
Transcript of Behaviour driven development aka bdd
BEHAVIOUR DRIVEN DEVELOPMENT AKA BDDSOFTWARE THAT MATTERS
BDD
WHY ? WHEN ?HOW ?
WHO BRING BDD ?
He is a technology and organizational consultant who helps business leaders, managers and software teams deliver quickly, successfully and sustainably. Dan’s background in software delivery, Lean operations, coaching and organizational change.
DISCONNECTS IN LAUNCHING OF A PROJECT
the business being truly able to define the desired outcomes
the developer’s understanding of what needs to be built, and
the business’ understanding of the technical challenges their requirements may present.
BDD HELPS TO CONNECT THEM
the business being truly able to define the desired outcomes
the developer’s understanding of what needs to be built, and
the business’ understanding of the technical challenges their requirements
may present.
WHAT ?
BDD is a process designed to aid the management and the delivery of software development projects by improving communication between engineers and business professionals. In so doing, BDD ensures all development projects remain focused on delivering what the business actually needs while meeting all requirements of the user.
KEY BENEFITS
All development work can be traced back directly to business objectives.
Software development meets user need. Satisfied users = good business.
Efficient prioritisation - business-critical features are delivered first.
All parties have a shared understanding of the project and can be involved in the communication.
A shared language ensures everyone (technical or not) has thorough visibility into the project’s progression.
Resulting software design that matches existing and supports upcoming business needs.
Improved quality code reducing costs of maintenance and minimizing project risk.
BDD APPROACHES
Practice of using examples written in ubiquitous language to illustrate behaviors (how users will interact with the product).
Practice of using those examples as the basis of automated tests. As well as checking functionality for the user, this ensures the system works as defined by the business throughout the project lifetime.
CO-ORDINATES OF BDD
19.0760° N, 72.8777° E
CO-ORDINATES OF BDD
Starting with a Goal
Impact Mapping
Value and Complexity
Analysis
Planning In Examples
Usage Centred Design
Ubiquitous Language
3 Amigos
Development Through Examples
The BDD Loops
STARTING WITH A GOAL
Every Behaviour Change should help
the Business to achieve its goals
Projects should delivered in sets of
Capabilities aka Working Features.
Understand exactly what you want the software to achieve
from a business perspective.
S.M.A.R.T GOAL
Specific
Measurable
Attainable
Relevant
Time-bound
S.M.A.R.T GOAL“We are going to generate more revenue
by making more sales”
“We are planning to achieve a 15% increase
in revenue through our online channels in 6 months”
Not S.M.A.R.T
S.M.A.R.T
Having a SMART goal not only helps to focus the project, but allows the impact of the project to be measured.
IMPACT MAPPING
Now we have sets our goal its time for Impact
IMPACT MAPPING Don’t add features to applications just for sake of more features. Its not always a case that to achieve a goal you have to add a new
feature. It is important to understand that not all of these features need the
same level of attention, care, or even development practice, and it can be easy to spread the development team’s attention too thinly across an entire backlog.
IMPACT MAPPING
Impact Mapping is a technique that helps you to outline all the alternative ways to reach your decided goal by analyzing users’ behavior. We assume that software cannot achieve business goals on its own. The only way software can get us closer to the goal is by supporting particular human behaviors.
LEVELS OF IMPACT MAP
One or More Ways To Support or Prevent These Impacts
One or More Impacts
One or More Actors
Business Goal
LEVELS OF IMPACT MAP
Customer or Team that could help or hinder the project from achieving the goal.
Actors
LEVELS OF IMPACT MAP
Each actor could have multiple ways to help or hinder achieving the goal, we call
these impacts..
Impacts
LEVELS OF IMPACT MAP
What the project or delivery team can do in order to support or prevent particular impacts from happening.
Support or Prevent Impacts
VALUE AND COMPLEXITY ANALYSIS
Value analysis helps us to quickly identify low-cost, high-value
features in the backlog.
Complexity analysis helps us to choose the right development and
collaboration approach to the project as a whole, as well as each
individual feature.
PLANNING IN EXAMPLESImagine we have been given a task to add an ‘include VAT
and delivery cost to the total price of the customer basket’ feature to an existing ecommerce project with
following set of business rules:
VAT is 20%
Delivery cost for small
basket (less than $20) is
$3Delivery cost for medium
basket (more than $20) is
$2
PLANNING IN EXAMPLES
Big ?Rules do not specify whether to add VAT before delivery
cost to the basket total or after.How should you handle a situation where the basket
delivery cost is exactly $20? What happens if there are multiple products in the basket?
PLANNING IN EXAMPLES Given a product is priced at $15, when I add
it to the basket, then the total basket price should be $21
Given a product is priced at $25, when I add it to the basket, then the total basket price should be $32
Given a product is priced at $20, when I add it to the basket, then the total basket price should be $26
UBIQUITOUS LANGUAGE
Almost impossible, to form a two-way communication between groups of people that operate in different business spheres.
They can stumble upon situations where both sides use the same language and even words, but imply a different meaning.
UBIQUITOUS LANGUAGE
Share $ Share
Design a share feature
UBIQUITOUS LANGUAGE
BDD attempts to eliminate the cost of translation by reducing the size of feedback loops and using the example-based conversation about each feature before they are built.
But just asking for examples is not enough, because different sides will use different language to produce examples, eventually causing discrepancies.
The solution for this problem is the concept the BDD community borrowed from DDD (Domain Driven Design): ubiquitous language.
INTRODUCING THE 3 AMIGOS
One of the core ideas behind BDD is that no single person has the full answer to the problem.
INTRODUCING THE 3 AMIGOS
3 Amigos
Business Roles Developer Tester
INTRODUCING THE 3 AMIGOS
Business Roles – Product Owner or Analyst
• Business value and risk evaluation domain.• Their insight and input is extremely important if you want
to deliver software that matters.• These people will generally ask questions like ‘is it
valuable? Do we really care about this?’
INTRODUCING THE 3 AMIGOS
Developers
• In the most part, remain in the so-called ‘solution’ space.• Input will give you an invaluable context into how much
detail the feature should have in order to be implementable.
• Tells if it is feasible .
INTRODUCING THE 3 AMIGOS
Testers• Usually represent the ‘problem’ space.• They see flaws happening in the system even before
development commences.• Plays crucial role while analysing negative impact in
application.• Identifies blanks in requirements.• Even sometimes their remarks can help developers to
understand whether feature is needed to develop from scratch or can be achieved with simple twiks.
3 AMIGOS
The core premise of BDD is not to replace these different expertise, but to move them all in one room and have a meaningful discussion about each feature before development starts. This process is called the Three Amigos or an Example Workshop and must be conducted before the team or a developer commits to deliver the feature in question.
DEVELOPMENT THROUGH EXAMPLES
Feed an example to an automation tool (such as Behat, Cucumber or SpecFlow).
Feature Files
Will transform it into the automated specification.
Step Definitions
Can then use this automated specification to drive the application development.
Development
GHERKIN FORMAT & SYNTAX
Gherkin files are plain-text and have the extension .feature Keywords:
Feature • And Background • But Scenario • * Given • Scenario Outline When Then
FEATUREThe feature keyword is used to group a set of tests
(scenarios) The text on the same line as the keyword is considered the name
of the feature All text between the initial line and a line that starts with
Scenario, Background, or Scenario Outline is considered part of a feature’s description.
It is conventional to name a .feature file by taking the name of the feature, converting to lowercase and replacing spaces with underlines feedback_when_entering_invalid_credit_card_details.feature
COMING UP WITH FEATURES: THINK OF YOUR USERS
In order to identify features in your system, you can use what the authors describe as a “feature injection template” In order to <meet some goal> as a <type of user> I want <a feature>
This is good advice The functional requirements of a system are determined by asking the
question for each type of user
what goals are they trying to achieve? what tasks must they perform to achieve those goals? how does our system support those tasks?
SCENARIOS
Scenarios follow a pattern Configure the system Have it perform a specific action Verify that the new state of the system is what we expected
We start with a context, describe an action, and check the outcome
SCENARIOS Gherkin provides three keywords to describe contexts, actions,
and outcomes Given: establish context When: perform action Then: check outcome
Example Scenario: Withdraw money from account Given I have $100 in my account When I request $20 Then $20 should be dispensed
SCENARIOS Additional steps to the context, action, and outcome sections using
the keywords and and but They allow you to specify scenarios in more detail
Scenario: Attempt withdrawal using stolen card Given I have $100 in my account But my card is invalid When I request $50 Then my card should not be returned And I should be told to contact the bank
These keywords help increase the expressiveness of the scenario
SCENARIOS In creating scenarios, a key design goal (indeed
requirement) is that they must be stateless; as the book says “Each scenario must make sense and be able to be executed
independently of any other scenario” You can’t have the success condition of one scenario
depend on the fact that some other scenario executed before it Each scenario creates its particular context, executes one
thing, and tests the result
SCENARIOS
Having stateless scenarios provides multiple benefits Tests are simpler and easier to understand You can run just a subset of your scenarios and you don’t
have to worry about your test set breaking Depending on your system, you might be able to run tests in
parallel reducing the amount of time it takes to execute all of your tests
SCENARIOS
Having stateless scenarios provides multiple benefits Tests are simpler and easier to understand You can run just a subset of your scenarios and you don’t
have to worry about your test set breaking Depending on your system, you might be able to run tests in
parallel reducing the amount of time it takes to execute all of your tests
To Be Continued . . .