As a Lead Software Engineer, maintaining cohesion between stakeholders and engineers is of paramount importance. Achieving this alignment requires the adoption of best practices in project management.

One such practice that serves me time and time again is Behavior Driven Development (BDD). BDD empowers the team to precisely define the behaviors of a feature within an application through the use of 'Feature' files, 'Scenarios,' and the "Given, When, Then" methodology.

But what makes BDD such a priceless asset in my toolkit?

Its significance extends beyond the realm of project management tools like Jira; it can also be integrated into automated tests within the application's codebase.

In this article, we will delve into a simplified approach for implementing BDD in both Jira and end-to-end tests using Playwright and Next.js. We'll also minimise technical debt by avoiding additional dependencies and plugins. Let's discover how this streamlined method can elevate your software development processes.

The Documentation First Approach

I usually begin in Confluence by mapping out each feature of an application. Take a 'Sign In' page as a simple example. Let’s flesh out its purpose:

What have we done here?

• Created a Confluence Space named ‘Behaviour Driven Development’
• Created a parent page named ‘Frontend Pages and Components’
• Created a child page named ‘Sign In Page’
• Added a brief overview of its purpose and the expected outcomes after user credentials have been submitted

Note: We could also add design screenshots from tools like Figma to specify non-functional requirements but we'll exclude this for brevity.

User Stories

Following the initial introduction, we've crafted five User Stories that provide a high-level overview of potential actions and outcomes on the page, even delving into what should occur if an authenticated user inadvertently lands on the Sign-In page.

At this juncture, you might be contemplating, "What more is there to do?" Indeed, we could proceed with the development of the Sign-In page by creating a Jira 'Story' ticket for each of the user stories outlined above, enabling engineers to kickstart the work.

But, let's take it a step further. What if we applied the principles of Behavior-Driven Development (BDD) to see how it could potentially reshape our approach?

Converting User Stories to 'Feature' files

Beneath our User Stories we've created a Feature file that uses a human-readable language known as Gherkin. Gherkin is specifically designed to describe software behaviour in plain English, making it accessible to both technical and non-technical team members.

Let’s take the first User Story as an example to understand how we’ve converted it to a Scenario in our Feature file:

User Story:

As an unauthenticated user, I want to login to the application to view the dashboard

Scenario in Feature File:

Feature: Sign In Page

  Scenario: Successful sign-in with valid credentials
    Given the user is on the sign-in page
    When the user enters a valid username and password
    And clicks the "Sign In" button
    Then they should be navigated to the dashboard
...

We've taken our user's intentions and goals from the story and distilled them into four manageable steps that serve as a clear path for testing the 'Sign In' page. But the advantages don't stop there; these steps can be integrated into our automated testing process. By leveraging end-to-end test runners like Playwright, we can write tests that execute each action, validating each step along the way.

To summarise so far, while User Stories play a pivotal role in the discovery phase, BDD (Behavior-Driven Development) compels us to refine our stories into actionable and testable acceptance criteria. The "Given-When-Then" methodology and its inclusion in automated testing ensures our software not only aligns with user expectations but also operates as expected in real-world scenarios.

From Feature File to Jira Tickets

Before we delve into the automated testing code examples, let's explore the process of applying our Feature file to Jira tickets. There are various approaches to this, each suited to the specific needs of the project. In my experience, User Stories often serve as a guiding framework during the discovery phase. They don't necessarily need to be transcribed verbatim into Jira tickets. However, the complexity of each User Story and the number of Scenarios within the resulting Feature file may influence our decision.

In this example, we have five Scenarios in the Feature file that can comfortably reside within a single 'Story' issue in Jira. Therefore, let's proceed as follows:

1. Create an Epic named Authentication with a child Story issue named Sign In Page:

2. Generate five child Task issues, each aligned with the five Scenarios from our Feature file. Use the Scenario name as the Summary for each task, for instance, 'Successful sign-in with valid credentials':

3. Lastly, within the Description field of each Task, copy and paste the 'Given-When-Then' steps from the corresponding Scenario in our Feature file:

This approach ensures that we can efficiently manage and track the development and testing of our features while maintaining a clear link to the originally defined behavior in our BDD Feature file.

Non Functional Requirements

Naturally, not all aspects of our 'Sign In' page are exclusively functional. What about the design elements? Logos? Etc. These can also be included as tasks within the story. We may aim to align the design with a Figma UI. It's worth noting that BDD isn't an all-or-nothing approach; it can coexist with other feature requirements. Though, if needed, robust end-to-end testing frameworks such as Playwright have the capability to validate design requirements too.

Advantages of Implementing BDD in Jira

I'm personally enthusiastic about this approach, and here are several reasons why:

Enhanced Confidence and Visibility: Utilizing the Gherkin language in Jira issues simplifies comprehension and facilitates testing.

Testable Requirements: Acceptance criteria within each story are readily understandable by both humans and automation tools, as you'll soon discover.

Streamlined Tasks: Work units are broken down into smaller, more manageable components.

Accelerated Feedback Loop: Smaller work units allow us to identify and address issues swiftly.

Increased Productivity: The completion of smaller tasks fosters a heightened sense of accomplishment and productivity among our teams.

Precisely Defined Features: Our team can furnish the client with a comprehensive list of behaviors for all application features even before the sign-off stage.

Collaboration: Effective scoping ensures that the behavior of each feature is meticulously defined, promoting collaboration among our teams.

Comprehensive Documentation: Features are comprehensively documented within a single location, and Jira serves as a facilitative tool for product delivery.

Minimized Revisions: Feature files and stories can be validated by the client, reducing the likelihood of miscommunication and the subsequent need for time-consuming revisions.

By embracing this approach in Jira, we not only streamline our development and testing processes but also enhance transparency, collaboration, and client satisfaction throughout the project lifecycle.

Automated Testing with Gherkin and Playwright in Next.js

TBC