BDD Testing

How to Implement BDD Testing in Jira: Step-by-Step Guide Using AIO Tests

Niharika Varshney
August 26, 2026
Implement BDD Testing banner image

Summarize Blog

Quick Summary

See how BDD testing works in Jira, from writing Gherkin scenarios and Scenario Outlines to managing execution, automation, traceability, and reporting in one connected QA workflow.

Behavior-Driven Development (BDD) testing bridges the gap between technical and non-technical teams. By using simple, natural language, such as Gherkin syntax, BDD allows everyone to understand and contribute to test scenarios.

For agile teams working inside Jira, adopting BDD makes even more sense. Jira is already the hub where stories, bugs, and tasks live. Bringing BDD test cases into Jira connects test plans directly with user stories and development workflows, making everything traceable and easy to manage.

A BDD Jira workflow can get messy without the right setup; testing teams may struggle with collaboration, scattered cases, and unclear ownership. AIO Tests simplifies BDD with built-in support in Jira, enabling teams to create, manage, and run test cases seamlessly without context switching.

In this guide, we'll walk you through the step-by-step process of implementing BDD testing in Jira using the test management platform.

What Is Behavior-Driven Development (BDD)?

Behavior-driven development testing is a collaborative approach that bridges the gap between business stakeholders, developers, and QA teams. It focuses on defining expected application behavior in plain, understandable language, making test scenarios accessible to everyone.

Key aspects of BDD include:

  • Behavior-driven development testing ensures test cases reflect real user behavior rather than just technical requirements.
  • BDD test case management helps teams create, organize, and maintain test cases linked to user stories, improving clarity and reducing miscommunication.
  • BDD integrates with Jira, connecting test cases to stories, bugs, and sprints for complete traceability.
  • It supports both manual testing and automated testing, allowing teams to run and track scenarios while choosing the right approach for each test.
  • It encourages collaboration among QA teams, developers, and stakeholders, improving alignment and shortening delivery cycles.

Why AIO Tests for BDD Testing in Jira?

For teams evaluating BDD test management tools, the platform provides test management within Jira for planning, organizing, executing, and tracking BDD tests. This AI-powered platform helps teams plan, organize, execute, and track all types of testing from manual to automated results and BDD scenarios covering the entire test lifecycle seamlessly within your team's daily workflow. The native Jira integration eliminates complex setups and sync issues, enabling QA teams to manage BDD test cases and effortlessly link them with Jira stories, bugs, and sprints.

How the platform simplifies BDD testing:

  • Gherkin Native Support: Write and manage BDD test scenarios using Gherkin syntax inside Jira. This keeps scenarios clear and readable for both technical and non-technical team members. This provides a structured Jira Gherkin workflow for creating and managing behavior-based scenarios alongside development work.
  • Import and Export Feature Files: Seamlessly import existing feature files to create test cases or export BDD scenarios from the platform into feature files. This bidirectional capability streamlines synchronization between automated and manual testing efforts.
  • Execution and Reporting Built-In: Execute BDD scenarios manually or via automation pipelines. Track execution status and view detailed reports inside Jira, ensuring full traceability and transparency.
  • i18n Support: The platform supports over 80 languages compatible with Gherkin, allowing teams to write BDD scenarios in their native language using Gherkin keywords.

Step-by-Step Guide to Implement BDD Testing in Jira Using AIO Tests

1. Create a BDD Test Case in AIO Tests

The first step in your BDD implementation in Jira is to create a BDD test case with the test case tool. The tool supports Gherkin syntax, which uses the Given-When-Then format to make test cases easy for everyone to read.

  • Access Test Case Creation: Navigate to the tool within your Jira instance. From the project or test cycle, click on Create Test Case.
Accessing test creation during BDD implementation in Jira using AIO Tests

  • Choose BDD/Gherkin Format: When prompted, select BDD/Gherkin as the BDD test case format. This sets up the structure for writing Given-When-Then steps.

  • Define Test Steps:

    • Given: Establish the initial conditions for the test (e.g., "Given the user is logged in").

    • When: Describe the action that triggers the behavior (e.g., "When the user clicks on the 'Submit' button").

    • Then: Outline the expected result (e.g., "Then the system should display a success message").

    • You can use And/But to include additional conditions or actions in the test case, making it more flexible.
Defining test steps during BDD implementation in Jira
  • Save and Link Test Case: After completing your test steps, save the test case. The platform allows you to link it with relevant Jira issues, such as user stories and bugs, for traceability.
Save and link the test case

2. Create Scenario Outlines with Examples

BDD testing allows you to parameterize your test cases by using Scenario Outlines. 

  • Edit Existing Test Case:  After creating the initial test case, open it in editing mode.
 Edit existing test cases
  • Add Scenario Outline: Select the Scenario Outline option, which lets you define parameters that will replace specific values in your test steps.

  • Add Examples: Under each Scenario Outline, create an Examples table listing the parameter values you want to test. This allows you to reuse the same test case structure while testing various conditions.
Adding Examples table under Scenario Outline to test multiple parameter values in BDD
  • Click the plus sign (+) to add parameters. Type the name into the 'New parameter name' field, then click 'Add'
Adding a new parameter by clicking the plus sign and entering the name in the 'New parameter name' field
  • Enter the values of the parameters. 
 Entering parameter values in input fields

  • Save Changes: After defining the parameterized test case, save the test case to apply the scenario outline. You can now run the same test with different inputs.

Executing a Dataset-Based Test Case in a Cycle

1. Viewing Dataset-Based Cases in a Cycle

In the Cycle screen, both dataset and non-dataset test cases are listed. To filter only dataset-based cases:

  • Use the “Datasets” filter from the toolbar.
Using the 'Datasets' filter from the toolbar

3. Running the Test Case

To execute a dataset-based test case:

  1. Expand the Test Case: Click the carat icon (>) next to the test case in the cycle view.

  2. Automatic Run Creation: The system generates 'Run 1' automatically.

  3. Dataset Executions: Each dataset defined in the test case results in a separate execution within the run.

On the Cycle screen, a single test case appears as multiple executions, with one execution for each dataset. Teams can track and manage each execution individually.

Running the test cases‍

running the test cases results preview

5. Dataset Row Breakdown

Each dataset execution in the test management platform can have its own status, effort, comments, defects, and attachments. While datasets can be deleted from a run, the last dataset cannot be removed. 

If the last dataset must be deleted, the entire case or run must also be removed.

Deleting the final dataset implies removal of the entire test case or run
  • Row Number: Indicates the position of the dataset within the test case. If a dataset is deleted (e.g., Dataset 2), the numbering adjusts accordingly, displaying Datasets 1 and 3.
  • More Details Icon: Displays information such as the creation and execution timestamps for the dataset.
  • Reset Dataset: Clears all statuses, comments, attachments, step results, and defects for the selected dataset.
  • Delete Dataset: Removes the specific dataset from the run, recalculating the overall effort and status. Note: 
  • Effort: Logs the actual effort expended on the dataset execution. The cumulative effort of all datasets contributes to the total run effort.
  • Timer: Start the timer at the dataset level to track the execution time for that dataset.
  • Status Selector and Display: Assign a status (e.g., Passed, Failed) to the dataset. This status influences the overall run status based on predefined percolation rules.
  • Defects: Log defects encountered during the dataset execution. These are aggregated at the run level and can be viewed in the defects summary.
  • Comments/Attachments: Add comments or attach files to the dataset execution.

6. Dataset Execution Steps

Expanding a dataset row reveals its steps, with dataset values highlighted within each step for clarity. Users can interact with each step by:

  • Adding Actual Results: Click the “Add actual result” link to input outcomes for each step.
  • Use the status icon to set the step's execution status. This status influences the dataset, run, and overall case status based on percolation rules.
  • Click the defects icon to report any issues encountered during the step.
  • Use the comments icon to add notes or tag team members for collaboration.
  • Click the attachments icon to upload supporting files or evidence related to the step.
Dataset execution steps ‍

Dataset execution step preview‍

7. Execution Status & Status Percolation

Users can set the execution status such as Not Run, In Progress, Blocked, Passed, or Failed by clicking the status icon at the Case, Run, Dataset, or Step level in the cycle details page. This flexibility allows for status updates at any level of granularity.

execution status and status percolation

8. Capturing Evidence and Effort

Users can log effort, add comments, report defects, and upload attachments at the dataset level, just as they can in regular runs.

Effort logged for each dataset execution is automatically rolled up to the run level. Users can manually override the total effort by editing the time in the run row.

Effort summary at run level with auto-rollup from datasets and manual override option‍

Instead of entering effort manually, users can start a timer at the dataset level to record the execution time.

Automatic execution time capture via timer at dataset level‍

Defects raised at the dataset level are visible at the run level.

Defects raised in datasets are displayed at the run level‍

Defects logged at the run level are also reflected at the dataset level.

 Defects logged at the run level are reflected at the dataset level‍

Defects recorded at the dataset level are managed in the same way as defects recorded at the run level.

Defects are managed at the dataset level similarly to the run level‍

Steps to Create a BDD Case by Pasting a Scenario

Step 1: Start by clicking the Create option in the top menu and choosing Case from the dropdown.

User clicking the 'Create' option in the top menu and selecting 'Case' from the dropdown‍

Step 2: Select the Create from Scenario button to continue.

Create from Scenario' button highlighted for selection‍

Step 3: A pop-up window will appear. Paste the scenario into the provided field.

Pop-up window with a text field for pasting the scenario‍

Step 4: Hit the Convert button to proceed.

Convert button visible for processing the pasted scenario‍

Step 5: The system will automatically populate the necessary fields on the Create Case screen. To review the test steps, click Add Steps.

Auto-filled fields on Create Case screen and highlighted 'Add Steps' button‍

Step 6: After reviewing the information, click “Save & Close” to finish.

Save & Close' button displayed to finalize the case creation

In addition to simplifying BDD case creation, the test case tool allows users to copy steps from other cases and duplicate existing cases. These capabilities make it easier to work with both Classic and BDD cases.

How Cucumber and Jira Work Together for BDD Testing

Cucumber and Jira play different but complementary roles in BDD testing. Jira manages requirements, user stories, defects, and development work, while Cucumber executes automated scenarios written in Gherkin. 

With a structured Jira BDD workflow, teams can manage BDD scenarios alongside requirements and bring automation results back into Jira.

Stage How Cucumber and Jira Work Together
Define requirements Product owners and development teams document user stories and acceptance criteria in Jira. These requirements provide the business context for BDD scenarios.
Create BDD scenarios QA teams convert expected behavior into Given-When-Then scenarios. With the platform, BDD test cases can be created and linked to the relevant Jira requirements.
Automate with Cucumber Automation engineers implement the Gherkin scenarios using Cucumber and connect each step to the underlying automation code.
Execute tests Cucumber runs the automated scenarios during development or through a CI/CD pipeline and produces the execution results.
Track results in Jira The platform can bring Cucumber automation results into the Jira-based testing workflow, allowing teams to review execution status alongside manual testing activities.
Maintain traceability Teams can connect Jira requirements, BDD test cases, execution results, and defects, making it easier to identify which behaviors were tested and where failures occurred.

BDD Sample Test Cases in Jira

BDD test cases use Given, When, and Then statements to describe expected application behavior in a clear, readable format. In Jira, these scenarios can be linked to user stories or requirements for better traceability.

  • Successful login: Given the user is on the login page, when valid credentials are entered, then the dashboard should open.
  • Invalid login: Given the user is on the login page, when incorrect credentials are entered, then an error message should appear.
  • Password reset: Given the user has forgotten their password, when they submit a registered email address, then a reset link should be sent.
  • Add product to cart: Given a product is available, when the user clicks Add to Cart, then the product should appear in the cart.
  • Form validation: Given a required field is empty, when the user submits the form, then a validation message should be displayed.

BDD Testing vs. Traditional Testing

No. Aspect BDD Testing Traditional Testing
1 Primary focus Verifies expected application behavior from the user's perspective. Verifies whether a feature or function works according to defined requirements.
2 Test format Uses business-readable scenarios, commonly written in Given-When-Then format. Uses test cases with steps, test data, expected results, and actual results.
3 Collaboration Encourages product, development, and QA teams to define expected behavior together. Test cases are often created and maintained mainly by QA teams.
4 Language Uses plain language that both technical and non-technical stakeholders can understand. May include more technical test steps and validation details.
5 Requirements alignment Scenarios are closely tied to user stories, acceptance criteria, and business behavior. Tests validate functional and technical requirements after they are defined.
6 Automation BDD scenarios can be automated using frameworks such as Cucumber. Automated tests may use frameworks such as Selenium, Playwright, or Cypress without a BDD layer.
7 Best suited for Cross-functional teams that need shared understanding of expected behavior. Teams that need detailed functional, regression, integration, or technical validation.

BDD does not replace traditional testing. Teams can use both approaches together based on the type of requirement, test coverage needed, and level of collaboration required.

Conclusion

In this blog, we’ve seen how the test management platform, with its native Jira integration, makes BDD implementation more structured. By combining Gherkin syntax, test case management, execution, and reporting within Jira, the platform helps teams collaborate on, execute, and track BDD tests.

If you’re ready to streamline BDD testing and improve collaboration across development and testing teams, the platform brings test management, execution, and traceability into the Jira workflow without requiring teams to switch between disconnected tools.

Book a demo to see how the test management platform can simplify BDD implementation and improve your testing workflows.

test case management

FAQs

1. How does AIO Tests support Gherkin and Given-When-Then syntax in Jira?

The platform supports BDD test cases directly in Jira using Gherkin syntax, including Given, When, Then, And, and But keywords. Teams can create readable BDD scenarios and connect their testing activities with Jira requirements. 

2. How do you create a BDD test case from an existing Gherkin scenario in AIO Tests?

Go to Create → Case → Create from Scenario, paste the Gherkin scenario, and click Convert. The tool populates the required case fields, after which you can review the steps and select Save & Close.

3. How do Scenario Outlines and Examples work in BDD test cases with AIO Tests?

Scenario Outlines let teams parameterize a BDD test case, while the Examples table provides different parameter values. Each dataset can then be executed separately without creating duplicate test cases for every input combination.

4. How can you execute and track BDD test cases in Jira using AIO Tests?

The platform supports manual and automated BDD execution within Jira. Teams can track execution status and results in Cycles; for dataset-based Scenario Outline cases, they can also track status, actual results, effort, defects, comments, and attachments at dataset and step levels.

Content