Behavior Driven Development (BDD) & Software Testing in Agile Environments

Agile environments effectively bridge the communication gaps between product and engineering. BDD is the best thing happened to Agile QA ;-)

Myths on Testing

At the university, I learned the fundamental concepts of Software Testing, but could not realize the bigger picture of this whole process. So I used to consider testing as a time-consuming process with so many theoretical jargon. But when I grow in my career and start working for the software industry in full time, I realized the true need for mechanisms to ensure the quality of software pieces we write. Let me share my findings with you.

Software Testing (Definition)

Software testing is a collection of processes aimed at investigating, evaluating and ascertaining the completeness and quality of a software product. This process ensures the compliance of a software product in relation with regulatory, business, technical, functional and user requirements through validation and verification.

Validation — Are we building the right product
Verification — Are we building the product right
V & V confidence — establishing confidence that the product is fit for purpose

Before getting into our topic, I assume that you have an understanding on the fundamental software testing concepts in the following concept map.

Software Testing Classification— Today software teams use combinations of above testing methods to meet their testing goals.

Traditional Testing

In the traditional software development environments, developing and testing were two distinct phases and most of the times, done by two distinct groups;

  1. Developers who write programs and build features
  2. Testers who test the written pieces of software
Quality Assurance — Testers write and execute comprehensive test suites to find bugs in newly-developed features, while verifying that the newly-written code has not caused any bug in the already-developed features (regression testing)

Going Agile

The rapid software development and constantly shipping of new quality features is now often the most important requirement for software systems that we develop. Businesses operate fast and our software products need to evolve quickly to reflect those changing business needs. But the traditional testing methodologies cannot ensure the expected good quality at faster speeds. In order to keep up with that different rhythm of development, a new approach in ensuring software quality is needed. That is Agile!

The focus of agile methods is to reduce overheads in the software process and to be able to respond quickly to changing requirements without excessive rework.

Agile Manifesto

Agile methods always commit to uncover better ways of building software by valuing;

Individuals and Interactions — over Processes & Tools
Working Software — over Comprehensive Documentation
Customer Collaboration — over Contract Negotiation
Responding to Change — over Following a Plan

Testing in Agile

Agile methods avoid the inefficiencies and overheads in traditional testing approaches by introducing the concepts like test automation, collaborative testing, full life cycle testing, reduced overheads, and minimum documentation. First, let me introduce you some terminology.

  1. Test Driven Development (TDD) — Tests are written before code and passing the tests is the critical driver of development.
  2. Acceptance Test Driven Development (ATDD) — Team members with different perspectives (customer, business analyst, tester, developer) collaborate and write acceptance tests in advance of implementing the corresponding functionality.
  3. Behavior Driven Development (BDD) — Tests are written in a non-technical language that everyone can understand (e.g. a domain-specific language like Gherkin). BDD combines the principles of TDD and ATDD and forms an approach for building a shared understanding on what kind of software to build by discussing examples.

Test Automation

In agile, almost all the time, we try to implement test suites in automated manner. Since the modern computers are really good at running repetitive tasks quickly, automating test suites is more efficient than using the manual testing. Whenever a new functionality is added to the system, the tests can be run and problems that the new code has introduced can be caught immediately (this enables the successful implementation of Continuous Integration practices).

Behavior Driven Development (BDD)

In Agile environments, BDD plays a vital role because it strongly encourages the use of Agile methodologies during the development and testing. BDD brings customers, end-users, BAs, QAs, and SEs of the software product into one table for effective sharing of knowledge on the system and its testing requirements.

BDD consists of cycles of a set of steps to follow.

  1. Identify business feature.
  2. Identify scenarios under the selected feature.
  3. Define steps for each scenario.
  4. Run feature and fail.
  5. Write code to make steps pass.
  6. Refactor code, Create reusable automation library.
  7. Run feature and pass.
  8. Generate test reports.

Writing Features

Features, scenarios, and steps together form Behavior tests. These tests are normally written in a business readable, domain specific language (DSL) by Business Analysts (BA) — in most of the cases . Gherkin is a popular language which is used for writing narrative user stories.

Sample Gherkin syntax to write a feature file

At the very beginning of a feature file, we mention the title of action as feature. Then it is optional to add a description to the feature. It takes the following format,

As [role]
I want [feature]
So that [benefit/business reason]

The acceptance criteria for a feature is the scenarios in it. Feature is said to be successfully passed only if all the scenarios in that feature are successful. A scenario takes the following format,

Given Exact context
When Action/Event
Then Outcomes
And/But More of the same…

Gherkin has more cool options like examples, scenario outlines, backgrounds, and tags. So make sure you go through the Gherkin documentation to get a better understanding on the possibilities of Gherkin.

If you are a person who tries to write great features, first of all, you have to minimize the feature smells (time dependency, inter-dependency, multi-scenario scenarios, overuse of variables)

Creating Tests

After business persons write the feature file, QA people start implementing the test suites. For writing BDD tests, BDD Test Frameworks are used. For automating the testing process, Test Runner code is also implemented using technologies like jUnit (Java), TestNG (Java), Mocha (JavaScript) etc.

Popular BDD Frameworks:

  • Java — Cucumber, JBehave
  • Ruby — Cucumber
  • PHP — Behat
  • JavaScript — cucumber.js, jasmine

Complete Test Cycle

In summary, BDD involves in a cycle of above activities and requires the involvement and collaboration of a cross-functional team which consists of customer/client, BAs, QAs, Testers, UI & UX designers, and software developers. It is a method carefully developed while keeping the principles of Agile Manifesto in mind.

Advantages of BDD

The biggest advantage of behavioral tests might be that they describe a set of functions that a user expects from a system in a very concrete and direct manner. The sum of these behaviors essentially document a contract with the user/client. If any of the tests fail, this contract is not upheld.

While it can be quite difficult to write unit tests for existing code, behavioral tests can be written for a system at any time: before, during, or after development. The case where the tests are written first is termed behavior-driven development.

The suite of unit tests provides constant feedback that each component is still working. The unit tests act as documentation that cannot go out-of-date, unlike separate documentation, which can and frequently does. When the test passes and the production code is refactored to remove duplication, it is clear that the code is finished, and the developer can move on to a new test.

Test-driven development forces critical analysis and design because the developer cannot create the production code without truly understanding what the desired result should be and how to test it. The software tends to be better designed, that is, loosely coupled and easily maintainable, because the developer is free to make design decisions and refactor at any time with confidence that the software is still working. This confidence is gained by running the tests. The need for a design pattern may emerge, and the code can be changed at that time.

The test suites act as a regression safety net on bugs: If a bug is found, the developer should create a test to reveal the bug and then modify the production code so that the bug goes away and all other tests still pass. On each successive test run, all previous bug fixes are verified. It also reduces debugging time.

Next Steps

To understand the BDD completely, let’s create a sample project to test a web application in BDD style with Cucumber, jUnit/TestNG, Java, and Selenium in my next tutorial.

Recommended Reading

References

Image Sources: https://www.safaribooksonline.com/library/view/bdd-in-action/9781617291654/, https://jovanamiljanovic.com/wp-content/uploads/2017/03/testirovshhiki-razrabotchiki-vzaimodeystvie.png, http://2.bp.blogspot.com/-SIWC4Nb2VQo/VzFfyjkAckI/AAAAAAAAAR4/XQGIel6Q_LorBWXSo55S3CRQmviXqxaYgCK4B/s1600/bdd.png

Tools in images: http://serenity-bdd.info, http://serenity-js.org


Be sure to follow me on Twitter @ashen_wgt and send me your feedback, any questions you have, and also let me know your experiences and I’ll check it out/retweet! You can also check my other articles on Agile Vision.