A fast-paced work in environment that often changes is both challenging and demanding. In agile development working product should be delivered at the end of each sprint, but in reality often there are often tasks left to be completed.
This could be due to many circumstances: overloading the sprint with tasks, underestimating the time for meetings, tasks failing qa, adding tasks to sprint, or factors out of our control such as sickness or cloud service failure.
These events can seriously handicap the tester’s ability to work productively. At the end of a sprint testers are wrapping up functional testing while regression testing is on the horizon. When the sprint ends QA is left with tasks to complete before final deployment can take place. If moving the deadline is not an issue there is no problem. But when facing a major release or trade show demo, it’s critical to play the aces up one’s sleeve. This is what the BDD (behavior driven development) approach seeks to avoid.
BDD is hard to define, but we’ll try: BDD is a collaborative practice of making applications by describing their behavior from the perspective of the users. BDD is an approach that developed out of TDD (test driven development) BDD relies on domain specific language and natural language to define the behavior expected in each feature. The three major outcomes of a BDD software development process are: living documentation, executable specification and automated acceptance tests. BDD is often misunderstood for these things that it leads to. All of which are very useful but without the essence of what BDD is, they will only partially add value. BDD is more than sum of it’s parts or products - it’s a collaboration practice and the essence is conversation. Having product conversations early and often in feature development leads to:
- Shared understanding of business needs
- Focus on end user’s perspective
- Usage of ubiquitous, domain specific language among team members
- Linking production code to examples derived from business needs
“But ok, how does it affect me as a tester?” you might ask. Two answers come to mind: one simple and one complex. The simple answer is that it will make you work proactively instead of reactively. You can avoid the scenarios when the product owner doesn’t realize that “feature X” development broke “feature Y” or that when a new feature works as described in ACs, the PO doesn’t like it because she imagined the font would be different.
In BDD everything is established before development when “Three amigos” (3A) meet - the product owner, the developer and the tester. During a 3A meeting, a common product understanding is reached, features are shaped, user stories and acceptance criteria are crafted, functional tests can be created.
The core of BDD has roots deep in the Agile Manifesto which emphasises the same principles that lay in the foundation of scrum or kanban methodologies, and they can be coupled together. BDD works with both methodologies. Proactively clearing the smoke on features helps to:
- More accurately estimate each story
- Write user stories from end-user perspective in a non-technical fashion
- Get features and user scenarios that can be developed into automated functional acceptance tests (or behavioral tests). This means that tests become the executable specification.
- Together, user scenarios and features they relate to, form living documentation. It’s written in domain-specific language and understandable to everyone - eliminating the need for separate product and testing docs
Automated functional acceptance tests form of contract between business and delivery team (all parties involved in delivery are signing it when 3As meet). In short, when the product is released product owner commits himself to accept the feature for which automated tests passed. In reality there is still some manual testing effort which can’t be automated but having GUI-based set of tests run on schedule and provide automatic reports with screenshots is invaluable. This can free up QA to do other work such as exploratory testing or requirement validation.
As a company, we incorporate some elements of BDD such as backlog grooming sessions and 3A meetings, which helped us to specify features and user stories, systemize domain vocabulary and analyze features from multiple angles. This in turn led to lower number of failed scenarios due to fuzzy criteria and bugs. Less time was spent on talking about features and documenting them after they were developed.
Products were released always on time with only very basic checks on production environments. This was possible because both automated unit tests and functional acceptance tests were run by the CI environment on every merge to the master branch.
The time saved on regression testing was used mainly for analysis, support and automation. An important upside of this approach is that whenever someone has doubts if system works as intended, they can run automated test suite and validate it. When some library update has to be made or additional feature is added, the tests will be there to guard code integrity and application stability. This could be partially achieved through TDD but with BDD we’ll know which business requirement is not fulfilled when a test fails.
Although BDD is not a magic pill it greatly enhances “agile” processes and helps to keep the spirit of the agile manifesto alive.