Interestingly, many organizations still firmly believe that BDD is all about “Testing”. In this article, I am going to share my experience on what people, whom I met in various forums, think about BDD from a testing point of view.
First thing first, let’s be very clear that BDD is different and testing is different. Like I said in my previous article, BDD is collaborative work. Various stakeholders collaborate and work together to harvest the fruits of requirements. Also, BDD is all about mindset.
On the other hand, “Testing” plays a small part, and there is no defined process for testing. In an ideal scenario, a tester plays an important role. He/she will collaborate closely with Business Analysts/Product Owners and Developers to understand the requirements and write edge cases to see how they can break the system, which eventually converts to acceptance criteria.
Everyone has different opinions when it comes to BDD and its process. A massive debate might occur like who should write acceptance criteria scenarios (business analysts) until who automates the acceptance tests (developers). You can read about the roles and responsibilities in a BDD project article that I wrote here.
From my personal experience, I firmly believe that testers should automate acceptance tests. Again, it’s debatable. As per some books and based on other’s experiences, they think developers should do partial testing. I agree with this to some extent.
But practically, developers are so occupied in their deliverables and unit testing. I have seen many developers showing less interest in automating the acceptance tests because of various reasons like delay in delivery, more sprint work, last-minute changes, etc., and this will eventually, lead to riskier product delivery. It can take us to loads of production bugs occurring if the developer spends time in writing step definitions or automated acceptance tests.
To avoid this, SDETs (or QE or Testers) will always be very handy. They help to automate the acceptance tests using tools & frameworks like Selenium, Cucumber, SpecFlow, Serenity, Cypress, etc., which suits very well them.
Doing so doesn’t mean if testers are automating acceptance tests, BDD = testing. In a nutshell, BDD is all about collaborative work, and testing plays a part in it.
Top comments (0)