How Does Behavior-Driven Development (BDD) Work In an Agile Setting? (Part 5)

This is the final post in my series on Behavior-Driven Development (BDD).

In the previous post on this topic, I explained how contrary to what you might assume, the bulk of your BDD tests for a Web application should not be from a user’s perspective: if you make them from a user’s perspective, the tests will have to invoke a browser and as your test suite accumulates over many sprints, eventually they will take too long to run, and you will be forced to run the full regression only at night, delaying feedback to the programmers. Even worse, programmers will find it impractical to run many of the tests locally on their laptops, and so they won’t, defeating any goals of “shift-left” integration testing. I then explained that a better approach is to architect your application to have a business logic layer, and write the tests against that layer. Such tests can still be defined by user stories, but they are coded at an API level instead of a user experience level. In the previous post I also explained some of the considerations for using the BDD approach for acceptance tests. In this post I will explain some of the issues pertaining to team roles and BDD workflow.

In the Scrum model, the Scrum Master oversees the Scrum process, and the team is expected to self-organize for all other issues. For a team using BDD, there is a large degree of coordination needed. The team can certainly self-organize to define how that should work, but there need to be specific roles to make it work well.

The Test Lead Is Not a Legacy Role

In waterfall processes, the test lead is the person who “owns” testing, overseeing the testers. In an Agile setting, a test lead is still important. There is a-lot of misunderstanding around this. On the one hand, one often hears that Agile teams do all their own testing, and that there are no testers and certainly there is no test lead. On the other hand, it is not uncommon in large organizations to see “Agile” teams that use essentially a waterfall testing process, whereby programmers write code and then hand it off to testers to test. Neither approach is optimal.

What works well in my experience is to have a test lead whose job it is to make sure that the testing approach is sufficient to cover all of the risks, and to act as a kind of quality control on the test specs and tests that are written. The testing strategy should be something like what is described in this article series. Testing strategy is a large topic and I won’t go into it here.

An Agile test lead—my own term—is a kind of coach and subject matter expert. Their focus is testing and test coverage. They should be looking at the test specs that the team writes and discovering shortfalls, and then working with the team to improve the specs—that is, to increase coverage and test accuracy.

One approach is to make the test lead a reviewer: to have them review each test spec. That approach raises alarm bells in my head, because it sounds like a waterfall approach. It might be the best approach, however. Think of the test lead review as a step in a Kanban process, immediately following the step of writing a test spec. Another way to implement it is to make test spec creation a collaborative process, whereby the test lead works with each test spec writer. A test spec should not be considered done unless the test lead marks it so, but instead of this occurring as a review, it occurs through the test lead going around, examining and discussing each spec that is under development. You should try what you think will work best for your team.

I have found that a test lead will find a very large number of gaps in test specs, particularly in test specs written by programmers. Test specs written by business analysts tend to have fewer gaps, in my experience, but there is no substitute for an experienced test lead: such a person has a testing mindset and thinks in terms of edge cases, which is really important.

Balancing the Flow

In the first post in this series, I mentioned that the Scrum process does not really accommodate BDD that well, because BDD tests inherently entail a kind of workflow, and that workflow can span a sprint boundary. For example, the team might decide that it is optimal if when the Product Owner (PO) completes acceptance criteria for a story, that work on that story’s test specs can then begin, with the intention that the story be started in the next sprint. Okay so far: this is pretty normal Scrum, except that we have a test spec task—a kind of coding—that begins in the sprint prior to when a story is begun. That’s not a big problem though.

During the next sprint, programmers pull stories that have complete test specs. Some of the sprint’s stories might not yet have those. The programmers write test code to implement the tests. As story tests are completed, those stories are ready for application coding, so other programmers start on those. Toward the middle of the sprint, all of the sprint’s stories have completed test code, and most programmers are now working on application code. However, if too much effort was put into test code, then there will not be enough capacity left for application code. And it is important to ensure that a programmer who wrote a story’s test code does not also write the story’s application code. During this time, analysts are working on test specs for the next sprint.

Balancing that whole process requires a high degree of scrutiny, awareness, and organization. I have seen Scrum Masters create a table on a whiteboard for each sprint, listing the stories with a column for the test specs, test code, and application code, and who is working on what at any given time. During standup this table is updated and the team collectively decides what will be worked on next. Such a table gives a forward view, which is important, because one needs to be able to forecast when a test program will be completed to predict when work on a story’s application code can start, and if more people should be working on test code instead of application code, and that determination changes every day.

I have not tried managing this as an actual Kanban process, because there is often overlap: it is okay to start working on application code before test code is done, but it is really important that the test code is ready when the person writing the story’s app code is ready to start running tests.

Summary

What I have described in these five posts is quite a bit different from what one usually reads about BDD. This is the reality though. As with so many Agile practices, once you get into a large organization that builds big and complex things, Agile practices morph into something that is quite different from how it can work on a small isolated team. It is still Agile though: it is Agile that can be used to build big stuff like an automobile telematics system or a ground station and satellite network.