Introducing BDD to your team – how does it affect your role as a tester?

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.

Get involved upfront

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.

Add your specific skills to the mix

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?’.

Work closer with business people

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.

Work closer with developers

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.

Get involved in test automation

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):

• Creating and implementing new step definitions to tie the steps in your Gherkin scenarios to executable actions performed on your application under test
• Maintaining, merging and pruning existing step definitions
• Updating existing and adding new libraries to the acceptance test automation suite
• Structuring existing scenarios and features to create living documentation that is easy to read and understand
• Finding and working towards the optimum balance between readability of steps on the one hand and maintainability and ease of implementation on the other hand

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.