When your team decides to adopt Behavior Driven Development (BDD) as a software development practice, the changes that are about to happen encompass a lot more than just throwing a tool at a problem.
Introducing BDD has a significant impact on the way you do your work, as well as on how you interact with your fellow team members. Remember, BDD is all about communication, not just about tools!
In this article, you’ll see how the introduction of BDD might impact your work as a tester. What changes? What remains? What can you contribute? As you’ll see, implementing BDD could bring some significant changes to your testing tasks and responsibilities, but it also means a lot of opportunities for more interesting and effective ways to do your best work.
In traditional software development practices, software testing was seen mostly as an afterthought: an activity to be performed after the design and development phase had been completed. If there was any time left before the project deadline, that is.. The introduction of agile software development practices has caused some change in this situation, and when it was implemented well, testers were involved a lot earlier in the process. However, in a lot of teams I have worked with, testing was still something done afterwards, but now at the end of each iteration (sprint), instead of at the end of the project (just Google ‘scrummerfall’ to see what I’m talking about here…).
When you’re adopting BDD, testers instead will be involved from the start of the development of every new feature. When BDD is adopted, all development starts with facilitated sessions to create and refine specifications in three amigos sessions, using techniques like Specification by Example and Example Mapping. Since the tester is one of those three amigos, you will be much more involved in the entire development process, from the very start.
Being involved from the early stages of the software development life cycle means that, as a tester, there’s much more opportunity to do what you do best. Instead of having to wait until development is complete (or, heaven forbid, a feature or user story has entered the ‘dev done’ stage…), you can start finding edge cases, discovering how the feature works together with other features and other types of professional question asking (we all know that that is the real definition of ‘QA’, right?) at a much earlier stage. As of the three amigos, you will be asked to help shape, critique and refine the specifications before the development even begins. This means saying goodbye to having to ask ‘Why was this feature built in this way? That doesn’t work in this situation’, and hello to asking ‘What will happen if we use the feature in this way once it’s implemented?’.
As your involvement in the software development lifecycle grows from ‘test last’ to ‘test everywhere, all the time’ when BDD is introduced in your team, your involvement with people from the business will grow, too. Discussing specifications upfront with product owners or business analysts, continuous validation of (to be) developed features with end users and communicating the results of your automated acceptance tests and your living documentation to business stakeholders, it is all part of what you do as a tester in a team that has adopted BDD.
Not only will you be working closer with business people, you’ll likely also work closer with the developers in your team, too. Not only will you be discussing the specifications with them during three amigos sessions, you will also likely be much closer involved in the actual development. It doesn’t mean that you will have to implement requested features yourself (although nothing is keeping you from doing that if you want to and have the development skills), but since you’re communicating with the developers from a shared understanding of what the software is supposed to behave like, discussions about implementation choices and how to test them will be much more frequent compared to more traditional software development paradigms.
The automation of acceptance tests as they are written in the specifications in the Gherkin Given/When/Then format, is an important step in the BDD process. This means that there’s likely to be plenty of work for you to pick up in the area of test automation. An effective and reliable test automation suite, driven by executable specifications using a tool such as SpecFlow, is an important asset in the journey towards fast feedback on the quality and value of the software under development. Here are just some test automation-related tasks that teams following BDD have to deal with regularly, often on a daily basis):
As you can see, the introduction of Behavior Driven Development as a way of working in your team can have a major impact on what you do as a tester. But unless you’re happy with waiting until all development is done, then having too little time to properly test, and complaining about it in the coffee corner, I’m sure that you’ll find the introduction of BDD an opportunity to get involved earlier, contribute more, and learn some new things and skills, too.