Behaviour Driven Testing – Key Takeaways

Introduction – Behaviour Driven Testing

As a company with a dedicated Testing unit, our specialization lies in Test Automation and we use Behaviour Driven Testing (BDT) heavily in Test Automation projects for both web and mobile-based applications. It’s been just over 2 years since our teams started with BDT and it has been a great learning experience for us. I am sure quite a lot of QA teams working with BDT can relate to the opportunities and challenges that I am presenting.

For the benefit of the beginners in BDT, I begin by highlighting some of the main reasons that drove us towards implementing BDT.

More than anything else, BDT helps in deriving tests directly from user stories ahead of time and includes every stakeholder involved in the product, right from the beginning – irrespective of whether they are technical or not.

To help even non-technical users understand the product features; BDT uses a domain-specific language which is business readable. This makes BDT reach a larger audience with minimum/no technical training.

The availability of powerful frameworks and languages. Gherkin is the most popular language which is used with frameworks like Cucumber, JBehave, and Behat. Gherkin uses an intuitive “Given When Then” syntax using which the feature is written.

Applicability in a broad range of situations. Usually, Gherkin specification is followed by an automation script. However, not every situation requires automation. In such cases, we may still use BDT to define testing behavior and complete the implementation using other techniques like exploratory testing.

One more notable point is that an up-to-date specification document serves as a fantastic documentation resource.

Key takeaways from practicing BDT – Behaviour Driven Testing

Through our experience in executing projects using BDT, we came across our share of opportunities and challenges. Following is the summarized list of takeaways from our experience:

Collaboration – It brings all stakeholders of the project with different views onto the same page and makes sure that all have the same expectations. This includes product teams, business analysts, QA team and developers. This in turn helps to come up with a good and clear set of acceptance criteria’s

Simple Specification – Unlike other models where the testers generally need to know the format of a test case, test management tool etc. here tests are designed in a ubiquitous language. Again, BDT focuses on the system’s behavioural aspects rather than focusing on testing the implementation

Easy Feedback – Due to simplicity and non-technical nature of BDT, Business Analysts can easily understand and actively participate in reviewing automated test cases.

Advanced Technical Skills – Skilled resources are required to build/maintain the framework as BDT tools and framework development approach are different from other popular automation tools in the market (QTP, Silk, TestComplete).

Rework – In some instances, the tests written by the manual tester/client/ business analysts are not good enough for automation. Efforts might be required in rewriting them.

Documentation – Documentation need not be created and maintained separately since the feature file itself serves as the requirement specifications/use cases.

Focus on Behaviour – BDT captures the business changes in a lucid way. The changes are no longer obscured in code and document.

Open Source Tools – Reduced spending on tools, since BDT frameworks and tools are open sources based.

Initial Setup – Initial project setup for BDT can be complex and time-consuming.

Support Community – The support community for BDT is still not large enough. It might take a longer time to resolve technical issues due to the limited exposure.

?Most Popular Topics

?Top 5 Aspects to consider when testing financial applications

?The Challenges Faced by Today’s Quality Assurance Practices

?Design Patterns In Test Automation World