How we made BDD work

Everything about it was new to me. New language, new framework(s), new methodology (not only my scrum first time, but also BDD!), and to top it all off, I was going to be the product owner. I was humbled by this massive undertaking but it was also a really exciting and challenging experience I thought was worth sharing.

The setup

BDD was not my choice, in fact, at that point I haven't really had a notable testing experience to speak of. I already knew this project was going to be a Rails project but that did not intimidate me, as soon as I recognized the familiary to python - a language I have used and loved -, I was more curious than scared.

This was also the first time I saw a fancy, "modern" project - many older PHP applications are monolithic, designed to run on an Apache server. I've seen projects without package management, without namespaces, without OOP and of course, without any kind of automated testing. After such experiences, the opportunity to work with Docker, deployment automation (Gitlab CI/CD) and tests was like a whole new world.

We had a lead developer who was responsible for the technical decisions, a project manager who was overseeing scrum, four developers and myself. I was delegated to this team as a developer, but I very soon assumed a secondary role as a product owner. This was a reasonable decision as the developer team was not an in-house team, it was an external company my employer hired to work on this project. At the same time, I have been working for my employer for 4 years at this point and I had a considerable amount of domain knowledge that could be helpful for modernizing our application.

Being a product owner

As a first step, I worked with our companies' managers, warehouse workers and the client services team to understand their workflow and how they were using the application, and translate these workflows into flow diagrams that the developer team could work with.

The development team used these diagrams to build out the application and I was always right there if they needed clarification about something. If there was a question I did not know the answer to, I could always go to my own employer's managers or the legal team for the answer. This is how I established this role of mediation between my employer and the external development team.

Here comes BDD

BDD or behavior-driven development is a variant of test-driven development, a software development methodology in which you are supposed to write a failing test first, and then the code that will pass the test.

Ruby uses the rspec gem to impement this. The benefit of BDD is that it establishes a common domain-language which allow even non-developers to understand what the code is supposed to do, how an entity is supposed to behave.

describe Order do
  it "has an initial total value of zero" do
    order = Order.new
    expect(order.total).to eq(0)
  end
end

If you format the output, this specification will produce something like:

Order
  has an initial total value of zero

This way, it was straightforward to establish a workflow of translating the flow diagrams into specifications, and then the specifications into working code.

How well did it work?

Since the initial goal was to rework the original system and make the workflows more flexible according to the users' needs, BDD allowed us to translate their requirements into code and immediately verify if the system was capable of the desired behavior.

After each sprint, the completed work was presented to my employer in a live demo session where we could collect feedback directly from the users (the company's employees) to support the fast feedback loops needed for scrum.

Thanks to contiuous integration, the rpec test suit (as well as a selenium test suit for the frontend) was integrated into the pipeline, and because of continuous delivery, a test system was available for users to try from the getgo.

This well-established operation and the unique team composition with me as a product owner allowed us to meet the delivery deadlines, as well as create a well-tested application that also met user expectations.

Thank you for reading!