Behaviour Driven Development — 2/3— with Agility
This article is part of a serie:
Let’s see what are the differences between the traditional way and the BDD way of delivery values to the business.
Software development process
In the Software development process, we have several players getting into the scene. In the case of waterfall flow, we can distinguish different roles: the customer, end users, business analysts, architects, developers and testers. And in an agile scheme we have these roles: stakeholder, production owner, scrum master, developers and testers. In both schemes, we usually have business analysts writing requirements (BRD), followed by some other business analysts on the development side writing solution requirements, then quality assurance manager writing a test plan, and finally testers are requested to execute tests.
Either a team is working an Agile or a Waterfall way, they still may be — or are — using the traditional software development process. And it’s pretty hard to getting away from it because people are just used to it.
Working with that approach meaning that the respective people would do things in a sequential order:
- for instance the business people would write down requirements in a document — typically called a BRD.
- Then a Quality Assurance (QA) manager would prepare a test plan to organise the work for testers,
- while the software architect is defining or adapting the existing architecture of the software and eventually produces a design document
- From the BRD and design document, developers put their hands in code to fulfil the requirements by translate them to machine code — without understand exactly what they are about. They also have to make sure the technical documents are up to date.
- And before the new features are being delivered, a bunch of tests — manual tests and hopefully automated tests — are run to ensure the quality is met. These tests are prepared and executed by testers. And testers typically translate requirements into test cases — again without having a clear understanding of the feature or product as a whole.
- Once tests are all executed, they produce the test reports. If everything goes fine, the QA manager will give a GO for release.
Oh by the way, the quality gate of the release being shipped is not yet in place, they may want a DevOps engineer to put in place quality gate to show some metrics. With those metrics, they can decide to go live or not.
Here, testers and QA are translating from requirements to test cases, while developers translate them into machine code — in a one-way directive and in a straightforward way, without having a clear understanding. And they are all siloed and they are not talking very much to each other. And from time to time, they way ask questions to the BA or PO to get more details in order to have the functionality completed. And it happens that the finished product is not really delivering the value stakeholders are expecting.
We see there are a lot of things to take into account when developing software, and still it does not guarantee that the software would meet the expected quality.
What if they explore the BDD approach. What if BDD is providing a simpler way to bring up the quality of the software — as expected — in a more focus manner and more efficiently? So then, they have to understand — or better adopt — the BDD approach.
Nowadays, BDD is on the wall of fame — in the agile space, in the testing space as well as in the development space. It’s making a big buzz, not exploring BDD or not trying it is not an option.
BDD in Agile way
In Agile methodology, the Software Development Life Cycle is still present but with smaller scale, bringing notion of iterations and sprints. Beside, the Agile methodology also bring in new phases to the software development process, splitting in these five phases :
- Inception: Think of the what we want to achieve in terms of product — or product increment
- Story mapping: This is a workshop where we define the steps to work on delivery the values
- Refinement: Here we get into more details for each work items and define how solve the problem — in other words how we are going to implement the solution
- Sprint Planning: Once we have refined work items — user stories or tasks, we are going to commit on delivery values
- Development: Now it’s time to put our hands dirty to produce the values
This is the common workflow of build software in an Agile way. If we dive into more details in the refinement phase — and we can see that as a process because it is cyclic from sprint to sprint — there are so many similarities to the two firsts steps of BDD along the
3 amigos concept.
A Refinement — was called
grooming - aims to refine items of the product backlog, thus get into details for each of them. There are many things to consider when doing refinements:
- Timebox as part of Agile
- Having a scope with focus on one or a few items
- Implicate several roles (product owner, testers and developers), they should discuss together
- Align people on a common understanding of each work items, thus an agreement of what has been defined
- Refine each item by adding details and/or sub-tasks, by defining what is to be accomplished, and what is the value out of it, as much explicit as possible.
- Reduce or maybe clear off uncertainties. Here we should not focus on the solution, but on the problem. But if there is any doubt on how to implement the item, write it down in the item.
- Estimate the complexity of each item
- Having acceptance criteria defined — as part of Definition of Ready
BDD stepped into the Refinement Process
Then if we look at the above list of best practices things in the refinement — above, we can see that a few are matched to what we have in the BDD
formulate steps, which are as followed:
- 3 amigos (product owner, testers and developers)
— > matching bullet 3 : Implicate several roles (product owner, testers and developers), they should discuss together.
- Discuss for covering uncertainties
— > matching bullet 7 : Estimate the complexity of each item.
- Reach a shared understanding
— > matching bullet 4 : Align people on a common understanding of each work items, thus an agreement of what has been defined.
- Define a common language
- Having scenarios using examples with gherkin syntax
- Having acceptance criteria defined
— > matching bullet 8: Having acceptance criteria defined — as part of Definition of Ready.