How the Testers are Involved in TDD, BDD & ATDD Techniques

An Introduction to TDD, BDD, and ATDD Techniques:

TDD, BDD, and ATDD are terminologies that have been transformative in the Agile software testing realm, gaining widespread popularity. A shift in the mindset of testers is necessary, entailing the development of new competencies and, most importantly, a change in perspective and approach.

Rather than working in a vacuum, testers are expected to collaborate and co-work with developers. This collaboration includes the following activities:

• Exchanging test cases
• Taking part in drafting acceptance criteria for stories
• Continually providing feedback to stakeholders
• Working together to swiftly rectify defects
• Offering feedback and suggestions for improving deliverable quality
• Automation

Prior to discussing the involvement of a tester in these practices, let’s first clarify the concepts underlying these terms:

Test Driven Development

Think about the conventional software development method, where coding is done first followed by testing. Test-driven development, or TDD, is a method that inverts this conventional process. With this method, testing is performed first, and then the corresponding code is written.

Perplexed?!!

How is it feasible to test software that has not yet been developed?

Indeed!! That’s what test-driven development, or TDD, is all about.

TDD operates in small degrees, where:

• Test is created first
• The test is then conducted, resulting in failure (for obvious reasons)
• The code is crafted (or refactored) to pass the test case
• The test is then run again
• Should the test pass, proceed to the next test; OTHERWISE, modify or rewrite the code to make the test pass

Let’s illustrate this through a flowchart:

Now it’s crucial to understand that TDD doesn’t pertain to the testing done by testers. Instead, it specifically relates to the testing conducted by developers.

You got it right!! It’s in reference to unit testing.

The preliminary test composed is not generated by testers, but it’s rather the unit test penned by developers. Thus, I would rephrase the steps as follows:

• The unit test is crafted first
• The unit test is run, which will fail (for apparent reasons)
• The code is designed (or refactored) to pass the unit test
• The unit test is then run again
• If the test passes, proceed to the next unit test; OTHERWISE, modify or rewrite the code so the test passes

Now, the question arises: if TDD is the developer’s prerogative, what part does the tester play in this method?

Although TDD is primarily the developer’s function, it doesn’t imply that testers are not involved. Testers can enhance collaboration by sharing test scenarios that incorporate:

• Boundary value cases
• Equivalence class test cases
• Significant business cases
• Error-prone functionality tests
• Security-specific test cases

What I’m attempting to convey is that testers should participate in formulating unit test scenarios and collaborate with developers in their application. Testers should also deliver their feedback on test results.

To execute TDD, testers need to enhance their abilities. They need to become more technically savvy and concentrate on honing their analytical and logical skills.

Testers should also strive to grasp the technical language used by developers and, if feasible, acquire a broad understanding of the codebase. Similarly, developers should strive to think like testers, devising more sophisticated scenarios that will make unit testing more robust and trustworthy.

Both developers and testers need to understand each other’s perspectives. This differs from the traditional method where developers paid less attention to unit tests as they relied on testers to find bugs, and testers avoided learning technical concepts as they felt their job was complete after identifying defects.

Behavior Driven Development

Behavior Driven Development, or BDD for short, is an extension of Test Driven Development.

As the name implies, BDD concentrates on developing features based on their behavior. The behavior is elucidated using examples in plain language, which is understandable by everyone involved in the development process, whether they are technical or non-technical team members.

Here are some prominent features of BDD:

• The language used to express behavior is uncomplicated and consistent, ensuring understanding by all team members, irrespective of technical ability
• It offers a platform for the “three amigos” (developer, tester, and PO/BA) to come together and comprehend the requirements, establishing a shared documentation template
• This approach is centered on the final system behavior, rather than its design or implementation
• It pays equal attention to both aspects of quality:
  • Fulfilling requirements
  • Appropriateness for use

Why BDD?

We know that rectifying defects or bugs in later development stages can be expensive. Fixing production defects not only impacts the code but may also alter the design and requirements. When conducting a root cause analysis (RCA), it is often concluded that defects originate from misunderstandings of requirements.

This happens because individuals possess varying capacities in understanding requirements. Thus, technical and non-technical team members may interpret the same requirement differently, leading to faulty deliveries. Therefore, it is essential that all development team members have the SAME understanding of the requirement and interpret it in the SAME manner.

We need to ensure that the entire development endeavor is focused on meeting the requirements and avoiding “requirement-miss” defects. To achieve this, the whole development team must align themselves to comprehend requirements that are fit for use.

BDD enables the development team to accomplish this in the following ways:

• Formulating a standardized approach to expressing requirements in simple English
• Providing examples that illustrate the requirements
• Offering a platform/interface that allows technical (developers/testers) and non-technical (PO/BA/customer) team members to collaborate and gain a shared understanding of requirements

How to Execute BDD?

There are several tools available for implementing BDD. These include the following:

• Cucumber
• Fitnesse
• Concordion
• JBehave
• Spec Flow

Example:

Let’s demonstrate BDD with an example, using Gherkin (Cucumber) for this instance:

Let’s assume we want to grant access to the XYZ site only to authenticated users.

The Gherkin file (feature file) would appear like this:

Feature: Test registration portal

Scenario Outline: Valid user logged in

Given: Customer opens the registration portal

When: user inputs the username as “<user>” and password as “<password>”

Then: the customer should be able to view the form.

Examples:

|user |password|

|user1 |pwd1|

|user2 |pwd2|

You can see how a particular requirement is documented using simple English. The three amigos can collaborate to compose feature files, and specific test data can be documented in the example section. BDD offers a platform for developers, testers, and business representatives to align their understanding of the features to be implemented.

The BDD approach reduces effort and costs by detecting defects early in the development cycle, thanks to the ongoing collaboration of customers and developers.

Development teams can use these feature files and convert them into executable programs for testing specific features.

How to do that? You would need to learn Cucumber/Fitnesse for that!

Acceptance Test Driven Development

Acceptance Test Driven Development, commonly known as ATDD, is a method where the entire team collaborates to define acceptance criteria for an epic/story before the actual implementation begins. These acceptance tests are underscored by proper examples and other necessary information.

In numerous cases, BDD and ATDD are used interchangeably. The ATDD approach can also be implemented using the Given-When-Then format, similar to the BDD approach.

Let’s summarize the differences between these three methods:

• TDD is more technical, written in the same language used for feature implementation. JUnit test cases are composed for Java implementations. BDD and ATDD, however, are written in simple English.
• TDD focuses on implementing a feature, while BDD highlights the behavior of the feature, and ATDD focuses on capturing the requirements.
• TDD requires technical expertise, whereas BDD and ATDD do not. The beauty of BDD/ATDD is that both technical and non-technical team members can contribute to feature development.
• TDD stresses good design and focuses on meeting requirements. In contrast, BDD/ATDD emphasize the second quality aspect, which is “fit for use”.

All these techniques follow a “test-first” approach, unlike conventional development methodologies that follow a “test-last” approach.

As tests are composed first, testers have an essential role to play. Testers must have extensives domain and business knowledge, and must also possess good technical abilities to effectively contribute during the “three amigos” discussions.

In the Agile environment, with concepts like Continuous Integration (CI) and Continuous Delivery (CD), testers must collaborate closely with developers and contribute equally to development and operations.

Let’s conclude this discussion with a look at the renowned Test Pyramid in Agile:

The bottom layer of the pyramid is the unit test layer, acting as the base. Most tests should be conducted in this layer. This layer is solely focused on TDD.

In the Agile environment, the emphasis is on reinforcing and solidifying this layer of the pyramid, where most of the testing takes place.

Xunit tools are employed in this layer of the pyramid.

The middle layer of the pyramid is the service layer, which represents service-level tests. This layer serves as a bridge between the application user interface and the lower-level unit/component. It mainly comprises APIs that receive UI requests and send responses. BDD and TTDD methods are widely implemented in this layer.

The tools employed in this layer of the pyramid include Fitnesse, Cucumber, and Robot Framework.

The uppermost layer of the pyramid is the UI layer, where testing efforts should be minimal. Most testing should have been concluded by the time we reach this layer.

The tools employed in the topmost layer include Selenium, QTP, and RFT.

Given that we operate in small increments (Sprints) in Scrum, manually implementing these methods is not feasible. Automation plays a vital role in their execution. In fact, these methods are executed through automation. With each sprint, new features are added, making it crucial that previously implemented features are still functioning as expected. Automation proves to be instrumental in this scenario.

Wrap Up

By the completion of this article, you should have gained insights into how testers engage in TDD, BDD, and ATDD techniques.

In the concluding part of this series, I will concentrate on automation in an Agile environment.

About the writer: This article was penned by STH Author Shilpa, who has over 10 years of experience in the software testing field across sectors like internet advertising, investment banking, and telecom.

Stay tuned for future updates!