What is BDD?

Behavior Driven Development is a disciplined technique for building software in which the Product Owner, a Programmer, and a Tester collaborate on system behavior, also known as, acceptance criteria for the future that is about to be implemented.

Initially we had waterfall models, wherein the role of Development team starts after the requirement finalization, and after Development is completed, then comes into picture, the QA/Testing team.

Then Iterative and Agile models were introduced, where though the time reduced in which the builds were released, but the testing time given to Testers (Specifically Automation Testers) was not sufficient enough.

So there came in the concept of BDD, where we follow the shift left concept.

Biggest Challenge in software development is trying to understand the requirements of customers. BDD encourages creating a shared understanding and collaboration by writing simple, scenario based, single source specifications that business people can understand and quickly agree to provide clear tracebility.

Syntax in Gherkin is used as follows:





This was about BDD, but to make it successful, we will be using Devops.

Since customer satisfaction and our loyalty towards them is very important ,we use DevOps because it improves the way that a business delivers value to its customers, suppliers, and partners.

DevOps follow the concept of CICD – Continuous integration Continuous Development.

Example/Benefit of CICD: Let’s say a small portion of the software is developed, and the build is integrated on Jenkins, the testing team has test cases ready written in simple English format (Gherkin) as discussed in BDD section.

The manual testers would start testing the application after deployment on production like environment and the automation testers would start building there automation scripts. Bugs would be found and reported and automation scripts would be ready (for say 20 Test cases) .Now the second build revision is out, so when it comes to the test, the 20 test cases can be automated and need no manual testing.

This process helps early identification of bugs, less rework and early results


Automated Environment Provisioning


Testing In Devops Using Automated Environment Provisioning


There are many companies which use cloud services in which there would be systems available with different hardware configurations and with different combinations of software’s (SVN, Eclipse, Selenium, QTP etc).

These machines can be used for specific time and the company will have to pay for the usage hours.This would in turn reduce a large amount of hardware and software costs and will provide a good ROI.


Establishing and connecting all the service components to enable the service operation can be a complex project. This delays service delivery to the business and potentially results in errors that add to audit expenses. Automated Environment Provisioning ties together the components that make up the service to execute a complete end-to-end deployment of the service in a single, fully-automated process

1 favorite thumb_down thumb_up 2 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist

Outline/structure of the Session

We will talk about:

  • Details on BDD
  • Testing using Devops
  • Linking of BDD and DevOps
  • Awareness for Automated Environment Provisioning
  • Why is Automated Environment Provisioning useful

Learning Outcome

- People will understand the benefits of Testing In DevOps 

- People wittl understand the benefits of Automated Environment Provisioning.

- Implementation of DevOps will help in identification of bugs, less rework and early results and to gain customer loyalty.

- Implementation of Automated Environment Provisioning in projects will reduce the project cost , provides good ROI to the organizations.

Target Audience

Testers(Manual and Automation)

schedule Submitted 2 years ago

Comments Subscribe to Comments

comment Comment on this Submission
  • Schalk Cronjé
    By Schalk Cronjé  ~  2 years ago
    reply Reply

    How much of this proposal is a practical demontration?


    Given that you proposed this as 20min, there is very little time to explain things like BDD etc. It looks like you will have to just jumpr right in and seom the juicy stuff, then leaving the attendees with some pointers to do some further reading of their own.

    • Niroz Shah
      By Niroz Shah  ~  2 years ago
      reply Reply



      In this topic we would not be giving out any practical demonstration. It would majorly include the theoretical part explaining audience the BDD and DevOps concept,Testing done using DevOps .  Devops is still in market but very few know about it and very few use it.So we will emphasize on why DevOps is important and why to use it.

      Also will be briefing on the concept of Automated Environment Provisioning. In this we will just give them details of what it is and what are the benefits  of it.

      And I will change the time mentioned. Will increase the time to 30 - 45 minutes along with Q&A session.



      There is no practical demo, but we will talk based on a slide deck abstracted out ofthe whitepaper