BDD Adoption - Taking time to get it right

Recently I've had the opportunity to speak with a broad range of Agile coaches and consultants who have consistently told me that they have not seen any organization successfully adopt BDD as part of their standard process of elaborating their User Stories. Luckily I have had the opportunity to work with several organizations that were able to successful adopt BDD and believe strongly in how this process can transform how you build and bake quality into your products.

I think most people hear the word BDD and they immediately think that it is an automation centric effort, though that is a great value add for BDD, leveraging BDD without automation can also lead to improved testing and quality.

Adopting BDD is so much more than automation (which I wrote about here) it's really about clearly defining the expected behavior of your system.

Why is this so important? Because as humans we all interact differently with the systems that we encounter.  As people who develop these systems we deliver based upon our experiences and understanding of the system we are building.

Language (Business Requirements) has been the manner and method that we have used to convey what we want a system to do to.  However with an international work force we don't all have a shared language.  In addition to this constraint we also interpret what we read differently based upon our primary language, life experiences and culture.  Given this, it's not surprising that when we build a system, it has many different interpretations attached to it, which negatively impacts both the functionality AND quality of our system.

BDD is a way to talk about how your system should behave not what it should do.  Yes we want our systems to have specific functions and features, but talking about how each of these will behave brings about a much richer conversation of what can happen in many functional situations the system and the people will encounter, not just the happy path.

There are two primary components of BDD:

1. The Given/When/Then test setup
2. The Example Table

Getting the first part of your BDD is the most important component because it defines the size and scope of what the User Story.  We do that by decomposing an individual user story into Test Scenarios.  One quick way to determine if your user story is perhaps to large or complicated is to evaluate the number of Test Scenarios you can define.  Keep your Test Scenarios to under 4 per each individual User Story so that you can more easily understand the expected behavior for that part of your feature or functionality.

Keeping the number of test scenarios small is also important once you translate your BDD into test automation which will keep your tests small so when something breaks it is much easier to find out where you need to address a fix.  Remember development teams should be consistently refactoring their code to improve code quality.  With high levels of automation we can quickly catch when refactoring unexpectedly changes the underlying behavior of our system.  This is where Quality is kept front and center in our organization.

The second part of building effective BDD is the Example table.  My training focuses on getting the first part clear and clean because the example table is an easier effort of filling in the expected results in each of your parameter columns.  As with the first section you can use the number of parameter columns as a means of determining if your test scenario is too large.  Try to keep the number of parameters to between 4-8, anymore will result in more brittle tests and more time debugging your automation code.

Adopting BDD as your primary means of decomposing stories may on the surface seem like a lot of work, but remember that you are only doing this level of detail for each 2 week sprint so the number of stories that you build out context driven BDD is relatively small.  Doing it every sprint means you get better at it every time and you will refine your ability to generate BDD much more quickly.

We should also remember that this is a TEAM oriented approach, don't relegate this to your QA team, you will miss getting all of the context needed to delivery high quality code and functionality.

Agile Testing

I was saddened to see that a meetup group that I managed for over two years was coming to an end because there wasn't anyone who wanted to take on the leadership role.  When I started at a Northern Virginia startup as QA Manager I was tasked with taking on the leadership role of the DC Agile Software Testers (DCAST) meetup. When I took over we had 25 people and when I left the group two years later  we had grown to a robust 450 and had developed a reputation as a place where QA professionals could meet to learn how they could be successful in an Agile environment.

I've always said that QA is the last to come around when organizations move towards Agile.  Early on in my career in Agile the QA leaders would tell me 'yeah you guys develop however you want and when you are done, then we'll test'.    The notion that QA couldn't test anything until everything was done (though in reality it never was) was strong.  The feeling of power in finding defects that were typically not defects but mis-interpretations of requirements was palpable.  The force was strong with us then. (cue the light saber sound).

With DCAST I saw quickly that the people who were coming didn't understand how they could engage in the process and more importantly they didn't understand how they could deliver 'quality' without having the entire feature delivered for testing.  Iterative testing just didn't compute.

There are many things that QA teams need to understand in order to be successful in Agile.  Some of the key elements include:

1. Automation - For QA this needs to be a key focus of development.  Automation builds what I call 'progressive regression'.  Instead of thinking of regression as the final end to end activity, look at it as a growing entity.  With waterfall development and more manual focused testing, you get an opportunity to perform a full regression test potentially just once at the very end of the development cycle.   This leaves little time to deal with defects that arise from your testing.  With automation and continuous integration you are effectively performing a regression test of your developed features every night.
2. Behaviour Driven Development (BDD) - The two-pronged effort to quickly develop and manage your test automation suite utilizes example based test development like BDD as your test acceptance framework.  What BDD does is ensure that the entire team is reviewing the acceptance tests that will ultimately be developed as part of the automation suite.  This process ensures highly contextual user stories that clearly define the behavior of the feature and keeps everyone focused on exactly what needs to be developed (nothing more nothing less)
3. Parallel Teamwork - With the use of BDD, QA can develop their automation code while feature development is in flight.  If the teams are working from the same story specifications then when the code is checked in the automation should be able to run with few errors.  This is a key process to develop in order for teams to deliver quickly.  By not having parallel efforts, teams will typically fall into the cadence of having automation developed in the next sprint.  Once you go down this road you will typically see automation efforts begin to fall further behind as QA will start manually testing in order to 'stay on top of testing'.
4. Sprint Management - QA teams need to work with their team to ensure that work is being delivered throughout the entire sprint.  A common problem teams face in Agile is that we fall into the 'mini-waterfall' process where developers deliver the features in the last day or two of the sprint.  This leaves very little time for QA to perform ad-hoc and manual break testing along with fixing any automation breaks that have occurred once the code is checked in.
5. Zero Defect Policy - This is key.  Teams need to develop a working agreement that enforces a zero defect policy for new feature work in a Sprint.  This means that the team does not receive credit for any stories that can't be closed out with zero defects.  This focus ensures that the entire team is focused on delivering quality.
6. Quality is EVERYONE'S responsibility - There is no such thing as 'toss it over to QA' in an Agile world.  Hey Developers, you have to help test if you deliver something late.   Don't let your software engineers tell you that they don't test.  All great developers have to be good testers ( you know TDD kind of focuses on writing tests).  The entire team is responsible for quality not just your test engineers.   Note - QA Managers this concept in no way removes the need for your existent, rather like Engineering Managers your role changes.  You should actually have time to be strategic and plan out future testing platforms and approaches for your team.

I'm glad to have led DCAST as it provided me an opportunity to help QA professionals grow their understanding of the activities and process all good Agile teams exhibit.