Rationale and Methods for Behaviour Driven Data

Abstract

With the increased attention for Agile development approach, BDD (Behavioral driven data) model also acquired a heed. Basically, it is considered as an evolution of TDD (Test driven development). BDD is a software development method used to create a bridge between the stakeholders and the technical teams in a professional environment. In TDD test cases are written in a more sophisticated way focusing on a way to achieve the code coverage whereas in BDT(Behavioral Driven Testing), test cases are written even before the development phase. In this way, the written cases are user specific and pertaining to system behavior. The main advantage of this approach is the simplicity of a testcase. Every test case(detail of the application) is written in Gherkin language (Naïve English) which can be easily understood by the Naïve user/stakeholders too. Also, when the testing is done prior to development phase the resultant failure cases will be maximum. This provokes the technical team to include all the possible scenarios that should be considered for building an application. This paper provides a rationale for BDD as well as the different tools that can be used to perform Behavior data testing.

Behavioral Driven Testing - Advanced TDD

Imagine a client tells us to build a model which has four legs, a giant body with a tail and dark. The technical teams developed an Elephant. What if the client was expecting a Bear? Where could be the misunderstanding? In this case, the mistake is from the technical team who failed to clearly understand the requirements from the stakeholders. Completely relying on TDD may lead to a failure of a model/application developed. Here acceptance testing is performed where code is validated in such a way that it covers the stakeholder’s requirements. In TDD, testers mainly focus on validating if the code suffices the requirements functionality rather than user specifications/behavior of the system. Also, the test cases are written in a technical way(unbounded) which makes it difficult to understand. Sometimes, the automates test cases are written with respect to the framework used in-order to automate the tests. However, BDT is an extension to TDD which mainly focuses on the behavior of the web application and also user specifications rather than the implementation. The test cases are also in ubiquitous language which helps the stakeholders to specify tests easily. The main characteristics of BDT include global language, Continuous decomposition, Template based features, Acceptance test based automation, readable code, stage specific behavior. BDD is mainly used for web applications alone. There are various toolkits available through which the automated BDD testcases can be written such as Cucumber, Easy B, J Dave etc.

Literature Review

Most of the published articles undermine the usage of BDT in professional environment, claiming that BDT is just an advancement of TDD with no proper benefits mentioned. In Tavares et al. (2007), the book claims that BDT is a simple approach which tries to perform validation and verification of test cases simultaneously in the design phase only. Also, it strongly asserts that BDT specialized tool kits are required in order to perform automation of acceptance test cases. However, in the ongoing summary various tool kits that can be integrated to tests BDT specific test cases are explained. There are several tool kits which can be used like cucumber, J Dave etc. On the other hand, Keogh et al. (2010) explains the business benefits one can have with the usage of BDT. Keogh attempts to explain a wider picture of BDT arguing that it’s implementation has a quite good impact on the various phases of a project lifecycle. Also, it creates an impression that BDT enhances the interaction between the business and software development. Carvalho et al. (2008) view BDT as a specification technique that “automatically certifies that all functional requirements are treated properly by source code, through the connection of textual description of these requirements to automated test cases. According to them, BDT is a higher level language where each requirement is written in a specific language with tags assigned to them so that they are treated as per the tag assigned in the subsequent phases of testing. Even though, this seems correct, it couldn’t explain the broader picture of the BDT mentioning about the implications, language etc.

Discussion

Behavior Driven Testing is mainly concerned about the application behavior rather than the functional requirement. BDT is the perfect approach if you want to understand business point of view on the requirements of the product. Many Organizations are finding BDD as an effective way to implement the product by means of integrating BDT framework with their model.

Characteristics of BDT

Ubiquitous Language

The Language meets the requirements of the domain model of a specification. With this property-Clients, Business, Stakeholders, Technical team may discuss about the requirements without any ambiguity. The names of the classes and methods used by the developers in code should be same as the user story/feature name. This allows a smooth functioning of the application over different phases of SDLC. During the analysis phase, a grammar is defined which is followed right from the analysis phase to execution phase. This grammar sometimes be called as the vocabulary of the application within the norms of BDT.

Looping decomposition

From the above example about the Bear and Elephant we can understand that there is a misunderstanding regarding requirements gathering between customer and the company. BDT helps to establish the business value initially. One must understand the behavior of the application and user specification before agreeing to a project. Apart from the implementation (similar to TDD), BDD process starts with identifying the value of the business. The system’s behavior will later be derived from the expectations of the business. The iterative decomposition is basically deriving the feature sets from these business outcomes. Derivation of features is based on the mutual understanding between testers and developers. Later, these features are further divided into user stories. Since, there is continuous derivation from business outcomes to user stories and later test cases, this process is called looping decomposition. Since the methodology used is Agile there would be phases of development and testing simultaneously. This makes it to assign priorities to the business outcomes as to what has to be developed and validated first. Unlike other testing strategies in BDT the user stories tend to be completely user oriented. The User story must contain what is the expectation from the user, the advantage the user has with the current feature. The scenarios derived by the testers from the user story are called Acceptance criteria.

User Story and Scenarios Template

As mentioned earlier, the language used to define the requirements is Gherkin Language. The template used to write a test scenario is as follows.

Given [example]

When [event]

Then [result].

A scenario tells how a feature should behave in that particular event along with the expected outcome from it.

Mapping Automated cases

The real skill of a tester is checked while writing a scenario and mapping them to the features. A scenario is divided into several steps where each step contains a context, events and actions.

In detail, for a user story (U)  when Event(E) happens the answer of the system should be (A). Test step is a function of (U,E,A). Each test step is mapped to one test method. In order to pass a scenario every test step needs to be passes (Red green flags are assigned in Test Management tools). Mapping rules are set of instructions written to be followed while mapping scenarios to test code.  Each scenario is mapped to a test method located using an annotation describing the step.

Readable code and Specifications

BDD states that the code is readable and specification should be written as part of the code. In this way, testers will have a better understand where exactly validations can be performed and it will be beneficial while performing boundary value analysis and white box testing. The naming convention of the methods should be in such a way that a naïve reader should understand what the method does by looking at its name.(can be written in sentences). However, most of the times the class and method names will be same as the user stories.

Behavior testing –phase

Automated Acceptance testing comes under the implementation phase of BDD. The toolkits that can be used for BDT are restricted to the stakeholder’s wish. Majority of BDD toolkits are required during the testing phase, since most of the test cases are automatable.

BDD Testing frameworks

HipTest

The native testing framework used for BDT. It can integrate with numerous frameworks like cucumber, Selenium, Jenkins, Jira etc. It is an open source platform with live documentation display and a feature to reuse test steps between multiple test cases.

Cucumber

Test cases are written in such a way that it can be understood by stakeholders, Business owners, testers and developers. All together decide upon the best behavior of the model which are later converted into acceptance test cases by the testers. The requirement and test case conditions are maintained in the same place. The primary language used is RUBY, however we can also use JAVA as well. This is limited to web based automation only.

Easy B

This tool is mainly used or Unit testing. Developers opt out unit testing while using Easy B.

Testing involves using user stories as validation criteria. There is no IDE integration for Easy B. A specification is declared as pending (reducing the efforts of the tester) unless it is completely passed comprising all the test steps associated with it.

J Dave

J Dave is more inclined to developer working framework. It shows the behavior of a class according to the specification unlike other BDT frameworks.

Concordion

One of the significant tools to write acceptance test scripts for java based projects. It can be integrated with Junit framework so it can be used with NetBeans, Eclipse etc. The specifications are written in HTML. The acceptance tests are written JAVA. It cannot be widely used in testing unless the tester is aware of the business specifications to be written in HTML.

JBehave

This is purely Java based framework with specifications written in plain text format making it BDT compatible. It can be integrated with selenium easily and since it has integration power it can also be used on various IDE’s like Eclipse, NetBeans etc.

SpecFlow

The most popular tool used for Behavioral data testing. It uses Gherkin language to write specifications. It can be integrated with visual studio(since it goes hand in hand with .Net).It has many advantages over Cucumber like generating reports, parallel execution of test executions, intelligent execution.(Failed test cases are executed first post deployment).

Advantages of Behavior Driven Testing

• It creates sense of collaboration between the stakeholders, QA, developers through business reviews frequently.
• Since, the test cases are written in natural language, it is easily readable by the business analysts which do not require developer’s frequent intervention to explain the product. Also, business analysts can write the test cases if required.
• It is cost effective. As seen earlier, BDT has the step reusability feature through which redundancy can be minimized thereby reducing the efforts in testing.
• Since majority of BDT tools are open source, we can have high ROI and also the code maintenance is better.

Limitations

• Prior experience of TDD (Test driven development) is required.
• BDT can be performed only in Agile methodology.
• Testers should possess strong technical skills and understanding of the application.

Conclusion

Behavior data testing should be done on top of the BDD frameworks listed above layer wise. The test cases are written in Given-when then format which enhances the readability, scalability of the project. However, tester needs to possess keen knowledge on the domain and the programming language which he/she wishes to script. The scripts written are referred to as acceptance test cases. The flow of the Behavior data testing is as follows:

User story creation by BA->Tester writes the scenarios->review->Mapping of the automatable test cases->Execution of automation scripts->bugs review and fixes->Regression testing->production deployment.

References

https://www.researchgate.net/publication/224265781_A_Study_of_the_Characteristics_of_Behaviour_Driven_Development

https://blog.testlodge.com/what-is-bdd/

https://www.softwaretestinghelp.com/behavior-driven-development-bdd-tools/