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:
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: https://nocodebdd.com/bdd-unit-testing/.
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: https://nocodebdd.com/oopsi-an-awesome-bdd-collboration-technique/.
For more detailed information, I highly recommend checking out this excellent article by Jenny Martin, the creator of OOPSI: https://www.linkedin.com/feed/update/urn:li:activity:7046551540303556608/.
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 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: https://nocodebdd.com/why-achieving-in-sprint-test-automation-is-the-key-to-agile
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 https://nocodebdd.com/lessons-learnt-in-automating-behaviour-driven-development-bdd-for-a-large-project/. 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.