Categories: Uncategorized

by nocodebdd


Key Considerations for Rolling Out BDD in a Project

Rolling out BDD in a project requires careful planning and a well-structured process. As a tech consultant on a large project, I had to make several changes to their BDD process and automation suite implementation. Some changes were straightforward, while others proved more challenging. If you’re considering implementing BDD in your projects, regardless of size or organization, here are some important points to consider:

BDD Testing

Using BDD solely for testing is not its intended purpose. BDD is about a collaborative process of analyzing requirements, deriving shared and agreed upon scenarios with stakeholders, and then implementing and executing those scenarios. By skipping the collaboration process and using BDD only for automation, you miss out on the full benefits of the approach. For additional information on this topic, I’ve written a blog post that you may find helpful:

Implement a process for collaboration

BDD requires collaboration, yet many teams have no process or only a loosely structured one. Consider using an established process like OOPSI, which helps teams focus on the business outcome and encourages involvement from all team members, including the 3 amigos.

Here is an article I have written providing an overview of OOPSI:

For more detailed information, I highly recommend checking out this excellent article by Jenny Martin, the creator of OOPSI:

Challenge Acceptance Criteria (AC)

It’s important to analyze all acceptance criteria (ACs). Simply implementing the given ACs without validating them may not be the best approach. As a software team, you have a better understanding of how the software will pan out and are therefore better equipped to analyze the criteria for validity or suggest better options. By analyzing and validating all ACs, the team can ensure that the implemented software satisfies the required outcomes and meets the needs of all stakeholders.

Here is an excellent article related to this topic. Though it mentions it about testing, it actually applies for the entire software team and the snippet from that article summarises this very well


The point is that ACs are an incredibly incomplete description of a system’s behavior. Even if you write thousands (which you shouldn’t), or combine them with pages and pages of documentation on non-functional (or cross-functional!) requirements, they are still just dispersed waypoints in a long journey. Real testing, whether done by the role of quality assurance, quality engineering, or generic engineers, must use common sense, judgement, user empathy, and critical/analytical thinking to continuously evaluate the state of the software against its value proposition.

In-sprint Automation

In-sprint automation is critical for agile teams that want to deliver value-adding software that keeps them competitive. Read this article to learn why in-sprint automation is so important.

Here is a detailed article, I wrote, explaining why this is critical:

Exploratory Testing

QA teams add real value when they do exploratory testing and identify difficult-to-find issues. They should spend less time on other types of testing and automation, but that doesn’t mean compromising on quality. Instead, put the right design and tools in place to cover and automate obvious scenarios early in the cycle, freeing up more time for exploratory testing.

Strong Version and Release Process

Introduce a well-defined version and release process early in your cycle. Doing so benefits the team and ensures a smoother release process. If you are using GIT, which seems to be a defacto version control tool, establish a strong versioning process and establish your CI/CD setup early in your software development life cycle and adhere to the process.

In this webinar video recording, I have provided a brief overview on how to establish this process. If you are interested in learning specifically about the version control process, you can skip ahead to 20:04.:


Here is an in-depth blog discussing the crucial aspects to consider while automating BDD scenarios, which can be accessed at Below are the bullet points summarizing the key takeaways from the blog:

    • Use the right tech stack
    • Avoid hard-coded messages
    • Consider parallel runs
    • Use unique IDs
    • Follow the single responsibility principle
    • Don’t skip best coding practices
    • Fail fast
    • Consider using regex
    • Use tags

Automation Suite Execution Time

Regular checkpoints are critical for managing the execution time of the BDD automation suite. Ultimately, you need fast feedback, so keeping the suite’s execution time reasonable is essential. Ignoring this can impact the team’s performance, delivery timeline, and morale.


Subscribe to our free newsletter.

Related Posts

View all
  • I had the pleasure of hosting a webinar with two industry experts, Rebecca Stone from IBM. During the webinar, Rebecca shared her experience in successfully implementing BDD in a large government project, highlighting the benefits of BDD, why and how she used OOPSI and its role in overcoming challenges faced […]

    Continue reading
  • 10 Tips for Writing Effective BDD Scenarios When rolling out BDD having a clear and concise scenario writing is a vital aspect of successful BDD adoption. This blog post will provide you with 10 tips to enhance your BDD scenario writing, making it easy to understand, maintainable, and efficient. 1. […]

    Continue reading
  • It will be difficult to automate testing if you don’t consider it when creating your web application. It will be difficult, regardless of whether you are a code wizard or a no-code ninja. Here are some crucial ideas to have in mind as you develop your app to make testing a […]

    Continue reading
  • Many websites now require two-factor authentication (2FA) as an extra security measure beyond a standard username and password. When a user enables 2FA for their account, they will receive a code (OTP) via their phone or email after successfully logging in with their username and password. This code must be […]

    Continue reading