Intro to BDD

Editor's Notes

• #2: 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.
• #3: So what is BDD? It's an agile development technique that encourages collaboration between developers, QA, DevOps and Business Analyst
• #4: 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
• #5: 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
• #7: 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
• #9: 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