Agile testing methods – Behavior Driven Testing

Agile testing is a relatively newer approach to

software testing

It follows the principles of agile software development as called out in the Agile Manifesto. About 10-12 years back, most of the projects were run in Waterfall fashion. However, With the basic advantage of quicker time to market, Agile methodology is gaining popularity nowadays.

nowadays

In Agile, software development and testing are continuous, and it is a collaborative effort between testers, developers, product owners, and even customers testing is not a separate phase like the waterfall model.

The difference with Agile methodology is that the testing starts at the very start of the project, even before development has started, and gives continuous feedback to the development activity.

Also, as a thought process also, testing in agile methodology is different since the onus of quality lies with everyone in the Agile team and not just QA i.e. in a way everyone on the team is responsible for testing.

Agile Testing Methods :
1. Test Driven Development (TDD) :

• The term TDD was coined by Kent Beck in 2002
• In this methodology, Tests are written before functions.
• It relies on the repetition of a very short development cycle
• First, the developer writes an initially failing automated test case that defines a desired improvement or new function
• Second, the Developer produces the minimum amount of code to pass that test, and
• Finally the new code to acceptable standards

The idea behind Test-driven development is to make each change small enough to iterate rapidly. As you automate and implement each feature or a change you’ve basically added something valuable to your overall system, and you’re ready for a shippable product and product owner feedback.

(a). Behavior-driven, testing (BDD) :

• It was first described by Dan North in 2009.
• BDD is an extension of test-driven development (TDD).
• Product Owner, Programmer, and Tester (3 amigos) are involved from the very start.
• Aids in application implementation from a stakeholder point of view through the use of the given-when-then style of representing tests.
• BDD Shifts the vocabulary from being test-based to behavior-based.
• It May be interchangeably/loosely called
  • Storytelling
  • Functional Testing
  • Acceptance Test Driven Development (ATDD)

Since BDD involves thinking in a common language, It helps teams to have the right conversations at the right time and thus maximizing the amount of valuable code produced. It also has the potential to identify gaps in understanding and areas where we need more information before we know what is to be done. 

2. Steps involved in the BDD Test :

• First, take a small upcoming change to the system i.e. a User Story or a scenario (Also known as Example in Context of Cucumber).
• Analyze new functionality to explore and agree on the details of what’s expected to be done by discussing between three amigos – BA, developer, and tester.
• Document the scenarios in a way that can be automated.
• Lastly, implement the behavior described by each documented example, starting with an automated test to guide the development of the code.

A practical BDD project flow is described in the figure below. 

3. BDD vs ATDD vs TDD : Key differences
Behavior Driven Development (BDD) :

• More customer-oriented and helps developers write tests keeping in mind the behavior desired by the stakeholders, and not tests to verify the code implementation.
• Customer-focused and uses English-like language, allowing easier collaboration with non-technical stakeholders.
• Gives a clear understanding as to what the system should do from the perspective of the developer and the customer.
• In BDD tests fail because the feature hasn’t been developed,
  • The feature is based on what customer needs

Acceptance Test Driven Development (ATDD) :
 

• Starts by guiding the development team on what features are actually required to be built and then testing those features to verify their functionality. Hence, ATDD focuses at a high level and TDD at a low level.
• Do the right thing (Business Point of  View).
• Gives the developer an understanding of what the system should do.
• Recent ATDD tools are inclining more towards using BDD-like language of Given, When, Then.

Test Driven Development (TDD)

• Tells the developer whether her/his code works fine.
• Do things right (Dev Point of  View).
• In TDD tests fail because the algorithm/function hasn’t been developed.
  • The algorithm is based on what the programmer knows
     

General Process Flow in BDD/TDD

4. Cucumber and Gherkins :
Cucumber :

• An important point to note is that Cucumber is not a Testing tool.
• Cucumber is a tool based on the Behavior Driven Development (BDD) framework which is used to write User acceptance tests.
• Cucumber reads executable specifications written in English text and validates that the software does what the specifications suggest.
• Scenarios or Specifications for Cucumber are written in below format :

Scenario : <Detailed scenario description>

GivenThe most: This clause describes the pre conditions

When : This clause defines the trigger point or an operation.

Then : This clause defines the outcome of the event or the operation. 

Gherkins :

• Gherkin is a Business Readable, Domain Specific Language.
• It is simple to understand as it removes logic and syntax details from behavior tests.
• It uses a set of Keywords to make tests more understandable. The most commonly used keywords are Feature, Given, When, The, Rule, and many more.
• Gherkins has been translated into and can be used in multiple languages. This helps easy communication between Stakeholders and business users.

Advantages and Disadvantages :

• Tests written in Gherkins/Cucumber serve the dual purpose of tests and project documentation.
• Adopting the BDD approach ensures a development process is built with the user experience in mind.
• This methodology requires a lot of engagement among 3 amigos. This can serve as an advantage or disadvantage depending on the project situation.

Closing thoughts :
The BDD approach can be a good choice when you need everyone on the team to be engaged without digging into technical aspects. Also, this approach is not ideal for all project types. Shorter projects may get delayed using this method. It can also make projects complicated and sometimes slow them down. It also requires a major mindset shift from the traditional way of working.