 |
Do you find yourself in meetings where stakeholders debate the expected outcome of requirements even after the user stories have been created? This is a case of misalignment due to test scenarios not being understandable by all stakeholders, both technical and non-technical folks. Or, do you witness different stakeholders allege not being included at the start of the process?
Both of these problems are precisely what the BDD approach intends to address.
What is Behavior Driven Development (BDD)?
BDD is an approach that focuses on how users will interact with the application. Based on this, the application is designed, developed, and tested. It helps to have the perspectives of both technical and non-technical stakeholders to generate test cases that assure a high-quality application. Since the focus is on the business requirement, examples are used to illustrate the different behaviors of the application.
This approach builds over the TDD and acceptance testing approaches. The Gherkin language is typically what comes to mind when discussing BDD, where the scenarios are documented in the Given-When-Then format. This is a popular way of writing BDD test scenarios for user stories. However, it is essential to note that BDD is primarily a thought process rather than a programming language or a tool.
Advantages of BDD:
- Since the scenarios are documented in a language that is understood by both technical and non-technical stakeholders, the communication between them is better.
- All stakeholders are involved early on in the process. This ensures that varied perspectives help finalize an affordable approach that is the most suitable to the business requirements.
- Suitable for teams that operate in agile environments and have continuous integration and continuous development.
- Due to the early alignment of the product’s design and approach, a lot of redundant coding and confusion can be avoided in the development stage.
- This approach helps maintain the quality of the application along with meeting client expectations.
- The test scenarios that are portrayed in the form of examples are discussed with the client to get feedback. This is a continuous process that helps the development of an application that holds true to the client’s ask.
How does BDD affect testers?
By now, we have understood that BDD is a collaborative process. So the question arises as to how do testers come into the picture? Does anything change for them?
In the older software development models, testing was usually treated as a good-to-have activity. However, with modern software development ideologies, testing has been recognized as one of the key activities. In BDD, testers get a place at the table right from the start of the process. You tend to see the 3 amigos concept here – the product owner, developer, and tester interact to finalize the action plan on the requirements. Not losing sight of the primary goals, meaning business requirements, is crucial for all involved.
Things that a tester can bring to the table:
As someone who understands the system and how to challenge it to reveal bugs, a tester has a lot to offer to the BDD process. Once the product owner shares the business problem, the tentative solutions are discussed. Even at this stage, a tester can add crucial insights into the plausibility of the solution. When defining the BDD scenarios, testers can leverage their experience to write the cases in plain English, which everyone can understand. When designing these test cases, testers can highlight specific details that are missing and get them clarified. Such fine combing of requirements through brainstorming helps develop a well thought out and (hopefully!) bug-free solution.
Does it affect testing strategies?
On the contrary, BDD helps get that precious alignment among the stakeholders right at the start of the cycle. Through the test cases that are written, new scenarios, as well as corrections to the prewritten scenarios, can be incorporated. Once the scenarios are agreed upon, they can be automated or manually tested. In fact, once these scenarios are available, the task of testing based on these scenarios can be delegated to other testers who may not be familiar with the system. This can help save time and resource bandwidth for experienced testers.
Why BDD doesn’t work in some organizations?
This title might raise some eyebrows since BDD is a very popular approach in the software industry. It turns out that in many cases, a team thinks they are following the BDD culture. However, in reality, they’re just using Gherkin to write their test cases and don’t follow the core BDD concepts.
It’s too common to see a picture when BA (business analysts) gather domain knowledge and train developers while also creating functional documents. Manual QA create test cases, which oftentimes the development manager will forget to review. Then during the sprint, QA gets the feature ready to test later than planned, leaving testers with barely enough time to complete testing and sign off. At best, automation for this feature will start during the next sprint.
It’s similar to how many companies nowadays say they’re using Agile. When digging into the core of why Agile doesn’t quite work for them – it turns out they’re still measuring work in human hours and setting hard deadlines.
Similar to Agile, with BDD, it’s crucial to follow the whole process religiously and don’t forget the core ideas that we’ve talked about in the previous sections. Otherwise, you might be disappointed with the results.
Automation testing and BDD
So far, we have seen that BDD involves documenting test scenarios in a human-readable format. This saves time in getting alignment among stakeholders. There are tools in the market that help automate BDD cases.
- The business writes test cases in Gherkin language
- Developers code the feature
- QA engineers automate the Gherkin test cases
- The business writes test cases in plain English
- Developers code the feature.
Once the feature is ready, simply run the test cases you’ve written in step 1 without any additional modifications. Since testRigor does not rely on details of implementation, you do not need to use XPaths, CSS Selectors, and so on. “Add to cart” button is just that, nothing else.
Additionally, the tools need to be common and easy to onboard so that both technical and non-technical stakeholders can view the test cases and make changes if needed. With testRigor being a cloud-based application, a simple login on the website is needed to access the necessary test cases.
Conclusion
The BDD approach facilitates the discussion and brainstorming of the requirement amongst stakeholders prior to putting it into the development cycle. This helps ensure that the application satisfies the client’s needs. Best suited for agile environments, this approach allows developers, product owners, and testers to participate in the design process from the beginning. In the meantime, testRigor might be your best friend when implementing BDD within the organization.
We highly encourage you to sign up for a free trial and try things out for yourself or request a demo where our friendly team will help you answer any questions – and design the best solution for your team.
