Top 50 BDD and Cucumber Interview Questions and Answers

Detailed explanation

TDD starts with small failing tests that guide code design, usually at unit level. ATDD focuses on acceptance criteria agreed before implementation, often at feature or story level. BDD builds on that idea by emphasizing collaboration, examples, and ubiquitous language so business, QA, and engineering share one understanding of expected behavior.

Practical example

For login, TDD might test PasswordValidator, ATDD might define acceptance checks for valid and invalid credentials, and BDD might express the behavior as Given a registered user, When they sign in, Then they see their dashboard.

Detailed explanation

Cucumber lets teams describe expected behavior in Given, When, Then scenarios and bind those steps to step definitions written in languages such as Java, JavaScript, TypeScript, Ruby, or Kotlin. It is useful when scenarios are valuable as shared documentation and executable acceptance tests, not just as technical scripts.

Practical example

A product owner can read a feature file for checkout behavior, while the automation framework uses step definitions to drive the browser or API and verify the same behavior.

Detailed explanation

Gherkin uses keywords such as Feature, Rule, Scenario, Given, When, Then, And, But, Background, Scenario Outline, and Examples. Good Gherkin describes observable behavior from a user or system perspective, while avoiding implementation details such as button locators, database queries, or framework mechanics.

Practical example

Given a customer has items in the cart, When they complete payment, Then an order confirmation is displayed.

Feature: Cart checkout

  Scenario: Customer completes checkout
    Given a customer has items in the cart
    When the customer pays with a valid card
    Then an order confirmation is shown

Detailed explanation

Given steps prepare preconditions without testing them directly. When steps represent the behavior being exercised, typically one main action. Then steps contain the expected result and should be assertive. And and But improve readability while keeping the same semantic role as the preceding keyword.

Practical example

Given a user has a locked account, When they try to sign in, Then the system shows an account locked message.

Detailed explanation

The Feature describes the capability under test. Scenarios capture concrete examples of behavior. Background defines shared setup for scenarios in the file. Scenario Outline plus Examples supports parameterized examples. Tags allow selection, reporting, and environment-specific behavior. Modern Gherkin may also use Rule to group scenarios under a business rule.

Practical example

A payments feature may contain tags for smoke tests, a Background for a registered customer, and scenarios for successful payment, declined payment, and expired card.

Detailed explanation

Use a regular Scenario when one example clearly communicates the behavior. Use Scenario Outline when the same behavior needs to be verified with several meaningful inputs and expected outputs. The placeholders in angle brackets are substituted from the Examples table for each generated scenario.

Practical example

A password strength rule can use Scenario Outline to verify short, weak, valid, and too-long passwords with different expected messages.

Scenario Outline: Password validation
  Given the user enters password "<password>"
  When the password is validated
  Then the message should be "<message>"

  Examples:
    | password | message              |
    | abc      | Password is too weak |
    | Abc12345 | Password is valid    |

Detailed explanation

Background is useful when several scenarios genuinely share the same contextual preconditions. It should remain short and readable because readers must mentally apply it to every scenario. If the setup is technical, noisy, or not relevant to every scenario, a hook or helper method may be more appropriate.

Practical example

In an account management feature, Background might say Given a registered customer exists and Given the customer is signed in.

Detailed explanation

Tags such as @smoke, @regression, @api, or @wip help teams run targeted subsets and communicate metadata. Tags can also trigger tagged hooks, but they should be governed carefully so they do not become an inconsistent taxonomy. A good tagging strategy uses a small set of purposeful tags with clear meanings.

Practical example

A CI pipeline may run @smoke on every pull request and @regression nightly.

Detailed explanation

Each step definition has a pattern, such as a Cucumber Expression or regular expression, and a body written in the chosen programming language. The step should translate business language into calls to application APIs, page objects, fixtures, or assertions. Good step definitions are reusable, focused, and not tightly coupled to UI implementation details.

Practical example

The step Then the order total should be $42.00 may call a checkout page object or API client and assert the displayed total.

Detailed explanation

Common hooks include Before and After for browser startup, test data cleanup, screenshots, logging, or API client reset. Tagged hooks run only for scenarios with matching tags. Hooks should support test execution infrastructure and avoid hiding business behavior that belongs in the scenario.

Practical example

An After hook can attach a screenshot when a UI scenario fails, while a @db tagged hook can reset test data before database-dependent scenarios.

Detailed explanation

BDD scenarios can serve as documentation when they are written in business language, reviewed by stakeholders, and kept green in CI. Unlike static requirement documents, executable specifications fail when the product behavior changes unexpectedly. This value is lost if scenarios are unreadable, overly technical, or not maintained.

Practical example

A new analyst can read the account closure feature file to understand the valid and invalid closure rules, then trust CI to show whether those rules still pass.

Detailed explanation

The goal is to discover misunderstandings early by discussing rules, examples, edge cases, and assumptions. The three perspectives are commonly represented by product or business, developer, and tester, though the exact people may vary. The output may include refined acceptance criteria, example maps, and candidate Gherkin scenarios.

Practical example

Before building refunds, the product owner explains policy rules, the developer identifies integration constraints, and the tester asks about partial refunds, expired orders, and fraud holds.

Detailed explanation

BDD scenarios are most valuable when they use the same words the business uses for rules, states, roles, and outcomes. This avoids translation errors between requirements, tests, and implementation. If the product calls someone a customer, the feature files should not randomly switch between user, client, account holder, and shopper unless those are distinct concepts.

Practical example

In a banking domain, available balance, ledger balance, and overdraft limit should be used precisely because they may mean different things.

Detailed explanation

Teams use Example Mapping to discover concrete examples for each business rule before writing code or automation. Rules describe expected behavior, examples illustrate the rules, and questions capture missing information. It is especially helpful for finding edge cases and deciding which examples deserve automated BDD scenarios.

Practical example

For discount codes, rules might cover expiry, minimum order value, one use per customer, and excluded products, each with concrete valid and invalid examples.

Detailed explanation

Cucumber adds value for collaborative acceptance scenarios, cross-role understanding, and living documentation. It is often a poor fit for low-level algorithm checks, exhaustive data permutations, visual assertions, simple technical health checks, or tests nobody outside QA will read. A healthy strategy uses Cucumber selectively alongside unit, component, contract, API, and exploratory testing.

Practical example

Testing every validation branch in a date parser is usually better as unit tests, while the business rule for booking cancellation windows may deserve BDD scenarios.

Detailed explanation

Data Tables are useful when a step needs a small set of related values, such as form fields, products, permissions, or expected records. They should improve readability rather than act as a large external dataset. In step definitions, Cucumber libraries usually expose helpers to convert tables to lists, maps, or custom objects.

Practical example

A Given step can create a customer with name, email, and status values supplied in a small table.

Given the following products exist:
  | name      | price | stock |
  | Keyboard  | 49.99 | 12    |
  | Mouse     | 19.99 | 30    |
When the customer searches for "Keyboard"
Then the product should be available

Detailed explanation

DocStrings are useful for JSON, XML, email bodies, markdown, messages, or other multi-line content that would be unreadable inside one step line. They keep the scenario expressive while preserving the exact payload. Step definitions receive the DocString as a string, sometimes with a media type depending on the Cucumber implementation.

Practical example

An API scenario can send a JSON request body as a DocString and then assert the response.

When I submit the registration request:
  """json
  {
    "email": "sam@example.com",
    "plan": "premium"
  }
  """
Then the account should be created

Detailed explanation

Cucumber Expressions use placeholders such as {string}, {int}, {float}, and custom parameter types to capture values from steps. They are easier for most teams to read and maintain than raw regex. Regex is still useful for complex matching, but it can make step definitions harder to understand if overused.

Practical example

The expression I add {int} items to the cart captures a number without writing a regex group.

import { Given } from "@cucumber/cucumber";

Given("I add {int} items to the cart", async function (quantity: number) {
  await this.cartPage.addItems(quantity);
});

Detailed explanation

Ambiguous step definitions usually come from generic wording, broad regex patterns, duplicated steps across modules, or inconsistent naming conventions. Cucumber cannot safely choose which implementation to run, so it reports an ambiguity error. Teams prevent this with clear domain language, shared step libraries, code review, and avoiding overly general catch-all steps.

Practical example

I log in as "admin" might match both I log in as {string} and I {word} in as {string}.

Detailed explanation

Undefined usually means the feature file has new wording or the glue path is misconfigured. Pending means the step definition exists but marks the implementation as incomplete. Skipped steps are a consequence of Cucumber stopping the scenario after a failure, undefined step, or pending step to avoid misleading results.

Practical example

If Given a premium user exists is undefined, the following When and Then steps in that scenario are skipped.

Detailed explanation

A runner connects feature files to the automation code and reporting stack. In Java this may be a JUnit or TestNG runner with Cucumber options. In JavaScript or TypeScript it is often a cucumber configuration file. Good configuration keeps environment settings explicit and avoids hardcoding local machine assumptions.

Practical example

A pull request job might run features under src/test/resources/features with glue under com.company.steps and the tag expression @smoke and not @wip.

export default {
  default: {
    paths: ["features/**/*.feature"],
    require: ["src/steps/**/*.ts", "src/support/**/*.ts"],
    format: ["progress", "json:reports/cucumber.json"],
    tags: "not @wip",
    parallel: 2,
  },
};

Detailed explanation

Tag expressions let teams run meaningful subsets such as @smoke and not @wip or @api or @contract. They are useful in CI pipelines, local debugging, and release workflows. The key is to keep tag semantics stable so filtering remains predictable.

Practical example

A nightly job may run @regression and not @flaky, while a pull request job may run @smoke and not @manual.

Detailed explanation

Tags should answer operational questions such as what to run for smoke, regression, API, UI, mobile, payment, or known quarantined tests. Avoid tags that duplicate feature names or encode implementation details. Review tags regularly and document allowed values so reports and CI filters stay meaningful.

Practical example

A suite might allow @smoke, @regression, @api, @ui, @checkout, @payments, @quarantine, and @manual, each with clear rules.

Detailed explanation

Feature files should remain business-readable, step definitions should translate those steps into actions, and Page Objects should encapsulate selectors, UI operations, and page-specific waits. This separation keeps Gherkin stable when the UI implementation changes and avoids duplicating locator logic across steps.

Practical example

The step When the customer submits the checkout form can call CheckoutPage.submitOrder instead of locating and clicking every field inside the step definition.

Detailed explanation

Feature files describe behavior. Step definitions translate business steps into automation calls. Page objects or API clients handle interaction details. Fixtures and test data builders prepare state. Hooks manage execution infrastructure. Configuration controls environments and filters. Reporting turns results into actionable feedback. Clear boundaries reduce duplication and make changes safer.

Practical example

A checkout scenario calls checkout steps, which use a CheckoutPage and OrdersApi, while test data builders create products and the report attaches screenshots on failure.

features/ -> business-readable scenarios
steps/ -> step definitions
pages/ -> UI interaction objects
api/ -> service clients
support/ -> hooks, world, fixtures
reports/ -> generated execution output

Detailed explanation

Steps in one scenario often need to share data such as created IDs, response objects, pages, or users. That state must be isolated per scenario to support parallel execution and avoid leakage. Cucumber implementations provide constructs such as World in JavaScript, PicoContainer or Spring in Java, or custom scenario context objects.

Practical example

A When step stores the API response in scenario context, and the Then step reads that response to assert status and body.

Detailed explanation

DI helps keep step definitions small and testable by injecting the collaborators they need. In Java, teams often use PicoContainer, Spring, or Guice with Cucumber. In TypeScript, a custom World object commonly acts as a scenario-scoped container. The important principle is that mutable dependencies should be isolated per scenario.

Practical example

A checkout step can receive a CheckoutPage, CartApi, and ScenarioContext instead of constructing them repeatedly or reading static fields.

public class CheckoutSteps {
  private final ScenarioContext context;
  private final CheckoutPage checkoutPage;

  public CheckoutSteps(ScenarioContext context, CheckoutPage checkoutPage) {
    this.context = context;
    this.checkoutPage = checkoutPage;
  }
}

Detailed explanation

Good test data management combines readable business examples with reliable setup mechanisms such as APIs, builders, factories, fixtures, or controlled database resets. Scenarios should state meaningful data, not implementation details. Data should be unique or cleaned up to avoid cross-test interference, especially in parallel CI runs.

Practical example

A step says Given a premium customer exists, while the step implementation creates that customer through an API builder and stores the customer ID in scenario context.

Detailed explanation

Background is part of the specification and should help readers understand each scenario. Hooks are execution infrastructure and can manage browsers, drivers, screenshots, cleanup, log capture, or environment reset. If hiding the setup would confuse a business reader, it probably belongs in Gherkin. If showing it would add noise, it probably belongs in a hook or helper.

Practical example

Given a registered customer is business context for Background; opening a browser and clearing cookies belongs in a hook.

Detailed explanation

Cucumber can produce formats such as progress, pretty, JSON, HTML, JUnit XML, or messages depending on the implementation. Strong reports help teams identify failing behavior, flaky areas, slow scenarios, and release risk. Reports are more valuable when scenario names are business-readable and artifacts are attached only where useful.

Practical example

For a failed checkout scenario, the report should include the failed step, stack trace, screenshot, browser console logs, and tags such as @checkout and @smoke.

Detailed explanation

A practical CI setup runs fast smoke scenarios on pull requests, broader regression suites on schedules or release branches, and publishes reports and artifacts. It should provision dependencies, configure environment variables, isolate test data, and fail the build on real regressions. Long or unstable scenarios should be separated, fixed, or quarantined with visibility.

Practical example

A pull request pipeline runs @smoke and not @quarantine, uploads Cucumber JSON and screenshots, and blocks merge if any scenario fails.

Detailed explanation

BDD fails when scenarios stop being collaborative specifications. Warning signs include UI scripts written in Gherkin, feature files nobody reviews, large Examples tables, brittle shared data, ambiguous step definitions, and test suites that are too slow to trust. The fix is usually to return to business examples, appropriate test layers, and clearer framework boundaries.

Practical example

A scenario saying When I click #checkout and enter text into input[name=card] is a UI automation script, not a useful business example.

Detailed explanation

Good scenarios use real examples rather than vague requirements, avoid implementation details, and explain why the behavior matters. They have enough context to be understandable, but not so much detail that they become scripts. They should be deterministic and independent so they can run reliably in any order.

Practical example

Then the customer should see free shipping applied is clearer than Then the shipping service returns code FS_001.

Detailed explanation

The Rule keyword helps organize scenarios when one feature contains multiple rules. It makes the relationship between examples and business policy explicit. A Rule can also have its own Background in modern Gherkin, which keeps setup closer to the scenarios that need it.

Practical example

A shipping feature can have rules for free shipping eligibility, restricted locations, and hazardous item handling.

Feature: Shipping offers

  Rule: Premium customers receive free standard shipping

    Scenario: Premium customer checks out
      Given a premium customer has a physical item in the cart
      When the customer views shipping options
      Then standard shipping should be free

Detailed explanation

BDD is not limited to browser tests. If the business behavior is about service rules, contracts, calculations, or workflow state, API-level automation may be faster and less flaky. UI automation is still appropriate when the user experience, rendering, accessibility, or cross-browser behavior matters. Many frameworks combine API setup with UI verification.

Practical example

A discount eligibility rule can be tested through an orders API, while the placement and wording of the discount banner may need a UI scenario.

Detailed explanation

A suite that passes sequentially may fail in parallel if scenarios share users, browsers, files, database rows, ports, or static variables. Framework design must isolate scenario context, create unique test data, avoid mutable singletons, and merge reports deterministically. External systems may also need rate limits, worker-aware accounts, or test environment capacity planning.

Practical example

Two parallel scenarios updating the same customer profile can fail unpredictably unless each scenario creates or reserves its own customer.

Detailed explanation

Flaky Cucumber suites often fail because of brittle waits, shared data, async processing, external dependencies, environmental instability, or overloaded CI agents. Diagnosis should use screenshots, logs, traces, rerun history, and failure clustering by tag or component. Reruns may reduce noise temporarily, but the long-term fix is deterministic waits, better data isolation, resilient setup, and clear ownership.

Practical example

If checkout failures happen only in parallel and screenshots show another user's cart, the likely issue is shared account state rather than a browser timing problem.

Detailed explanation

Instead of parsing strings repeatedly inside step definitions, custom parameter types define how domain values should be recognized and transformed. They improve reuse and validation when the same concept appears in many steps, such as account type, currency, role, or order status. They should be specific enough to avoid ambiguous matching.

Practical example

A {customerType} parameter can transform premium, standard, and guest into a CustomerType enum.

import { defineParameterType } from "@cucumber/cucumber";

defineParameterType({
  name: "customerType",
  regexp: /premium|standard|guest/,
  transformer: (value: string) => value.toUpperCase(),
});

Detailed explanation

A reusable step library should reflect the team's ubiquitous language and common business workflows. Steps should be neither too generic nor too specific. Organize by domain capability, review new step wording, prefer composition in helper services over calling steps from steps, and track duplication or ambiguity as the suite grows.

Practical example

Use Given a premium customer exists instead of many variants such as Given I create a premium user in database and Given premium account is inserted.

Detailed explanation

As frameworks grow, Page Objects alone are not enough because many business actions cross multiple screens or services. A task or domain service layer can express operations such as registerCustomer, createPaidOrder, or approveRefund using APIs and UI objects internally. This keeps step definitions thin and reduces duplication while preserving business intent.

Practical example

Given a paid order exists can call an OrderTestService that creates a customer, cart, payment, and order through stable setup APIs.

Detailed explanation

Every scenario should be able to run independently and in any order. Prevent leakage by creating data per scenario, clearing cookies or sessions, using worker-safe resources, resetting mocks, and avoiding shared mutable fields. If cleanup can fail, prefer disposable data with unique identifiers and environment reset jobs.

Practical example

Generate a unique email per scenario and store it in scenario context instead of reusing qa@example.com across the suite.

Detailed explanation

Large suites need more than pass or fail output. Useful observability captures duration trends, flaky scenarios, retry counts, failing tags, environment details, screenshots, API logs, browser traces, and links to builds or defects. Reports should support triage by product area and owner, and raw outputs should remain available for debugging.

Practical example

A dashboard can show that @checkout failures increased after a payment gateway deployment and link each failed scenario to screenshots and request logs.

Detailed explanation

The feature file is a collaboration artifact, so its wording should change mainly when business behavior changes. Step definitions and lower layers absorb UI, API, locator, and data setup changes. This contract protects living documentation from churn and makes refactoring possible without rewriting business scenarios.

Practical example

If the checkout button changes from Continue to Place order, the Page Object may change, but the step When the customer submits the order should remain valid.

Detailed explanation

In microservices, Cucumber scenarios should not become slow full-stack tests for every service interaction. Use BDD for important business examples that cross boundaries or clarify rules, and support them with faster consumer-driven contracts, component tests, and API checks. Test data, environment orchestration, and observability become especially important.

Practical example

A loan approval journey may have a few BDD scenarios, while each service has contract tests for request and response compatibility.

Detailed explanation

At scale, BDD quality depends on both technical and collaboration discipline. Teams need agreed Gherkin style, step definition ownership, tag rules, framework contribution guidelines, review checklists, CI standards, and feedback from metrics such as flakiness, duration, duplicate steps, and stakeholder usage. Governance should enable teams, not create a bottleneck.

Practical example

A center of excellence can maintain framework libraries and style guides while product teams own their feature files and domain examples.

Detailed explanation

Start by asking what rule each scenario is trying to prove. Replace technical steps such as clicking fields and selecting locators with domain language such as completing checkout or submitting valid payment details. Step definitions should delegate UI details to Page Objects. Keep enough detail to understand the example, but remove mechanical script instructions that change whenever the UI changes.

Practical example

Change When I click the green checkout button and type 4111111111111111 into card_number to When the customer pays with a valid card.

Scenario: Customer pays for an order
  Given a customer has a shippable item in the cart
  When the customer pays with a valid card
  Then the order should be confirmed
  And the customer should receive a confirmation email

Detailed explanation

Compare sequential and parallel runs, group failures by tag or feature, and inspect screenshots, logs, and created data. Look for shared accounts, static fields, reused files, fixed ports, non-unique identifiers, browser session leakage, and external service limits. Reduce worker count temporarily only to confirm the pattern, then fix isolation and framework design.

Practical example

If two workers use the same admin account and one scenario changes its password, unrelated login scenarios may fail only in parallel.

Detailed explanation

The architecture should keep business language separate from automation mechanics. Feature files live by domain capability, step definitions are thin translators, domain services model reusable workflows, page objects or API clients encapsulate interactions, and support code manages scenario context, fixtures, hooks, configuration, and reporting. Build in parallel safety, CI integration, and contribution standards from the start.

Practical example

For an ecommerce app, the framework may include checkout.feature, checkout.steps.ts, CheckoutPage, OrdersApi, OrderFactory, ScenarioWorld, hooks, cucumber config, and report publishing.

{
  "layers": [
    "features",
    "step-definitions",
    "domain-services",
    "page-objects-or-api-clients",
    "support-context",
    "reporting"
  ]
}

Detailed explanation

If stakeholders ignore feature files, the suite may be too technical, too late in the process, or not connected to real decision-making. Use Three Amigos or Example Mapping to discuss examples before automation, rewrite scenarios in domain language, and show living documentation in a useful format. If nobody needs a human-readable specification for some tests, move those checks to a more appropriate layer.

Practical example

Replace technical login setup scenarios with business examples for account lockout rules and review them during story refinement.

Detailed explanation

Start with data: scenario duration, failure history, business criticality, duplicates, and flakiness. Keep a small reliable smoke suite for release gates, move low-level permutations to unit, API, component, or contract tests, and reserve end-to-end BDD for high-value workflows. Improve setup speed, use API shortcuts where appropriate, parallelize after isolation is safe, and remove scenarios that no longer protect real risk.

Practical example

Instead of testing 40 discount permutations through the browser, keep two customer-facing checkout BDD scenarios and move the calculation matrix to API or unit tests.