As a company having a dedicated Testing unit, our specialisation lies in Test Automation and we use Behaviour Driven Testing heavily in Test Automation projects for both web and mobile based applications. It’s been just over 2 years since our teams started doing Automated Testing Using Behaviour Driven Testing (BDT) and we felt compelled to share some of the experiences that we have had during these 2 years with the EuroSTAR Testing community. I am sure that there are lot of teams out there doing BDT and I hope they can relate to some of the positive results that we have seen using BDT and of course to the challenges as well.
For the benefit of the readers of this article, I am starting off by highlighting some of the main reasons that drive us towards implementing BDT though I am sure most of you are aware of it. 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.
Apparently, to help even non technical users understand the product features BDT uses a domain specific language which should be business readable. Gherkin is the most popular one which is used with frameworks like Cucumber, JBehave and Behat. Gherkin uses a “Given When Then” syntax using which the feature is written and when you use run Cucumber or any other Gherkin based framework, it generates a report that verifies whether the software behaves the way as defined in the Gherkin document or not.
Generally a Gherkin specification precedes the automation script to be executed based on that and hence those users who are not doing automation may still use BDT but go with other techniques such as Exploratory testing to define the behaviour and use the same for documentation purposes.
Using Behaviour Driven Testing – What we learnt
During our experience executing projects using BDT, we have seen some positive results and also some challenges which are shared below.
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, tests are designed in a ubiquitous language. Again, BDT focuses on the system’s behavioural aspects rather than focusing on testing the implementation
Feedback – Business Analysts can actively participate in reviewing automated test cases and give their feedback to enhance them which usually doesn’t happen other models given the technical nature of the automation scripts
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 – Behaviour Driven Testing captures the business changes better than being lost it in code and document.
Open Source Tools – Spending on tools is reduced since BDT frameworks and tools are open source based
Initial Setup – Initial project set-up for BDT is complex and time consuming
Community Support – The community for BDT is still not large enough and when surrounded by technical issues, it takes time to resolve as the community may not have also experienced it.
ABout The Author
S.Vasudevan, the author of this article has about 14 years of experience in the field of Testing and Test Automation. Currently heads a 250 member Testing team at Aspire Systems, a company based out of Chennai, India. The author’s interests include Test automation tools, reducing defect leakage through better Testing practices etc.
