BDD can work

No tendency is quite so strong in human nature as the desire to lay down rules of conduct for other people.

“No tendency is quite so strong in human nature as the desire to lay down rules of conduct for other people.” ~William Howard Taft

There are way more case studies about disasters than success. And I don’t believe, as I have worked on some projects that on the face of it, ran poorly but still managed to deliver. It is very easy to dissect a project negatively - there is always room for improvement. Projects succeed down to the team, and whatever pressures and politics they have to navigate through. It’s the difference between running a regular race and running a steeplechase. What

I am going to talk about is a success story - a BDD success story. It was made easier by the fact both team and client were fully behind aspiring to this approach, and I think that’s an essential, not optional. The key word is “aspiring”, as everyone will have their own view on what success means, and what BDD means to them (if anything). The easier way to show it is working is by doing it.

  • Imagine you had a ScrumMaster who acted as a pure shield for the development team, as well as maintaining a close relationship with the Product Owners and stakeholders.
  • Imagine there was Products Owner(s) that not only devised requirements but used Gherkin of followed specification by example approach.
  • Imagine there was Products Owner(s) who maintained a regular set of users for user testing, on delivered features.
  • Imagine Products Owner(s) worked alongside the UX team, to ensure journeys were clear and logical to the user.
  • Imagine tests could be done well in advance, and continually added to the build and deployment pipeline.
  • Imagine the whole team working from the same development environment, using vagrant or docker or similar.
  • Imagine all this was done prior to a Sprint starting - a review, so all the team could input into the scenarios.

If you imagine all this to be true, then after a few months, you will notice these things happen more easily.

With the test engineering, ensure sound programming principles of reuse are applied to scenarios and steps, with each Sprint, then creating tests becomes less embroiled in admin and rushed code.

Because the Product Owners are ahead of the game, creating requirements in the form of real-life scenarios, they become quickly adept at not only defining user stories but breaking them down so more quickly and easily understood.

Because the project is focused on giving developers all they need to turn stories into code, the developers can implement with less room for error.

Because UX team are proactively involved in definition of stories and scenarios, as well as end users.

Overall, there were be reduction in reported issues, and more focus on improvements and experimentation, a more satisfying challenge for development.

And I am not even going to call it BDD, it’s just a great way to run a software project, as long as you have the right people with the right attitude. One of the first things to shake off is just because acceptance criteria are defined in advance, it does not mean things can’t change, or other requirements can be added, commonly to cover bugs or user feedback or exploratory testing findings. It’s a nonsense to say otherwise and just harks back to older style Waterfall QA.

This isn’t a process you can just slap onto of a team, you need the right people. And I don’t go with the “anyone can do anything” philosophy touted by many (bad) Agile coaches/evangelists. A team comprises of people with different technical and business skills, alongside the most important factor. Personality. I settled into the area I have done because it suited my personality and personal tech interests. I am a people-person but also have autistic tendencies. I don’t want to be the person who spends all day in meetings; I prefer to communicate 1-2-1, which is more to my strengths.

Projects with BDD label attracts a certain type of person - an enthusiast, usually with passion for their area but also interest in others. If you want hierarchy in those teams, be prepared to fight for it. Every day. And never win. Every day is about useful work, no space or time for self-serving behaviour. A lot is said about the importance of team, without really understanding why. If you have the right team (or close as dammit) then it will naturally cross-functional, supportive and productive. Expect spikes as these types of people want to do things right, and challenge their own assumptions. You really want these kinds of people, right? They won’t work for just anyone, so be prepared to listen and prove to them the project is right for them.

I have only worked on two projects that fully followed BDD in a pure form - one I was one from inception to go-live. By far the most satisfying project. But by aspiring to BDD, it can improve any project. For test engineering, there are some great frameworks out there, and regardless of approach, BDD-oriented frameworks are ideal for maintaining acceptance tests.

The Business Analyst took it upon himself to coach the PO’s on writing scenarios in Gherkin format. Plenty of cursing sometimes (it’s not as easy as sold)< but they all made an impressive effort to not only define requirements in BDD format but also observed the reuse principles. It meant I could create tests quickly, as have time to improve test framework scope with other tests. Even NFR’s were devised in the same manner.

The ScrumMaster truly acted as shield for development - allowed room for people to be themselves, get upset, swear and shout sometimes, but always supportive. He made proactive efforts to get stories signed up mid-Sprint if possible. An hour before start of Sprint, he would ensure all created necessary tasks under the stories, including Spikes. This minor tedious admin meant the Sprint started with most admin completed.

From the best to the worst: the project that was sold as BDD, but under the hood was not even close. DevOps reduced to firefighting production issues at 3 am, test automation disallowed from continually broken pipeline, developers unused to test engineers (or even bug reporting). And the most comical element- the pipeline dashboard, a screenshot when all panels were “green”. And the golden rule: No-one is allowed to say anything is wrong. Sound bizarre? It does, and it is.

Much of the time, how far you can go with BDD is down to structure of the team and company culture. If you truly want to follow this route, and the current team is not up to it, expect to lose people. Not because they are “not good”, but that their skills and attitude are not up to this way of working. It’s not about being ruthless, you want a happy healthy enthused team. If one person is compromising that, they should go. There is a team for everyone, not everyone suits every team. You are wasting your time thinking otherwise. You can’t fight human nature.

“Inconsistency with ourselves is the great weakness of human nature” ~ F Joseph Addison

Cookie policy