Hello Everyone and welcome to Introduction to Behavior Driven Development.
In this presentation, we will go throgh the basics and a demo of BDD to gain a better understanding.
So let’s get started.
So what is BDD?
It's an agile development technique that encourages collaboration between developers, QA, DevOps and Business Analyst
Let's start off with a TYPICAL workflow "without" BDD in the picture.
On left side we have key stakeholders working on a new software feature
Business Analyst: Product Manager and/or Project Manager
Developer
QA
DevOps
So here is the overall Process!
Business analyst collects feedback from customers and internal partners and uses business language to convey and document the requirements
Engineering capture these requirements in their own structure and start implementing them
QA for example
Documents requirements into test suite and test case structure
Test failure are very cryptic and usually require QA to decipher them
This results into what’s called the cost of translation since everyone is using a different language
Ultimately the entire team is hoping that they built the right software
And the negative feedback can be lenghty and costly (even with smaller releases).
Bottom Line
Customer expectations get lost in translation
Since internal stakeholders use different vocabulary to describe requirements and customer expectations
Here is the workflow "with" BDD in the picture.
Business Analyst, Developer, QA & DevOps gather to formulate and document requirements into “BDD Scenarios”
These Scearios are written in plain English and capture requirements with specific examples
So for example, this time when a test scenario by QA fails, developers are already aware of the context and easily understand nature of failures
As a result Feedback is quicker
Eventhough scenarios are not initially implemented, you can start to keep track of the overall progress of feature
Bottom Line
We have a common language that everyone can understand to communicate requirements and examples
As a result, feedback is quicker and easier to understand
More importantly, we can make educated “release” decisions based on common reporting format
High-level business rules tend to be relatively stable, and changes to them will be driven by the business rather than by technical constraints. They describe the test requirements (i.e. end user's desired behaviors).
Mid-level business flow layer describes the user's journey.
Lower-level technical layer outlines the implementation details, such as spark streams, elastic search queries, and how a low-level library is called, tend to change more frequently. It interacts with the system under test
Integrate BDD in CI
Setting up JUNIT
Scenarios in JIRA
Defining and associating scenarios with JIRA stroies
Reviewing, importing & syncing between git repository
Using Baseline for Scenarios
Separating data from repository
How to store expected results and credentials for each environment