Resource library

Automation Interview

Cucumber and BDD Interview Questions and Answers

Cucumber and BDD interview questions with strong sample answers, real Gherkin snippets, step-definition patterns, and framework wiring for QA and SDET roles.

2,012 words | Article schema | FAQ schema | Breadcrumb schema

Overview

Cucumber interviews rarely reward people who memorized what Given, When, and Then mean. Interviewers have watched too many teams bolt Gherkin onto an old Selenium suite, call it BDD, and produce 400 unreadable scenarios. So the questions are designed to find out whether you understand the discipline behind the tool: collaboration, living documentation, and behavior expressed in the language of the business.

This guide is written for SDETs and QA automation engineers who use Cucumber-JVM, Cucumber.js, or SpecFlow and want answers that sound like real project experience. Every question below comes with a sample answer you can adapt, plus Gherkin and step-definition detail so you can defend your choices when the interviewer pushes back.

Read it as a way to sharpen your own opinions. The strongest candidates do not recite definitions. They tell you where BDD earned its keep, where it turned into expensive theater, and exactly how they wired Cucumber into a maintainable framework.

Why Interviewers Separate BDD From Cucumber

The first trap is treating BDD and Cucumber as synonyms. BDD (Behavior Driven Development) is a collaboration practice: business, development, and testing agree on concrete examples of behavior before code is written. Cucumber is one tool that turns those examples into executable specifications. You can practice BDD with no tool at all, and you can misuse Cucumber while doing zero real BDD.

A sample answer that lands: 'BDD is about building a shared understanding through examples. Cucumber is the runner that keeps those examples honest by executing them against the product. If the business never reads the scenarios, I have a test framework with extra ceremony, not BDD.' That framing signals you have lived through the difference, which is exactly the signal panels are listening for.

Gherkin Fundamentals They Always Test

Expect a warm-up on Gherkin structure. A Feature groups related scenarios and states the business value. A Scenario is one concrete example. Given sets up context, When is the single action under test, and Then asserts the observable outcome. And plus But simply continue the previous keyword for readability. Background holds steps shared by every scenario in the file so you do not repeat setup.

`Feature: Wallet top-up` states the capability and who benefits.
`Background:` runs before each scenario, ideal for a logged-in user or seeded account.
`Given the wallet balance is 50.00` establishes state, not action.
`When the user tops up 25.00 with a saved card` is the one triggering action.
`Then the wallet balance should be 75.00` asserts a single, checkable outcome.
Keep one When per scenario. Multiple Whens usually mean two scenarios hiding in one.

Declarative Versus Imperative Scenarios

This is the highest-signal quality question in any Cucumber interview. An imperative scenario spells out clicks and fields: enter username, enter password, click submit, wait for spinner. A declarative scenario states intent: given a registered shopper, when they check out, then the order is confirmed. Imperative steps couple your living documentation to the UI, so every layout change rewrites the specification and business readers tune out.

Strong answer: 'I keep scenarios declarative and push the mechanical detail into step definitions or page objects. The feature file should read like a product rule so a business analyst can review it. If a scenario mentions a CSS selector or a button color, that detail belongs in the glue code, not the specification.' Offer to show a before and after if they want the concrete contrast.

Imperative smell: `When I click the '#login-btn' element` inside a feature file.
Declarative fix: `When the customer signs in` with the mechanics hidden in the step.
Rule of thumb: a non-technical reader should understand every line without you translating.

Step Definitions and Glue Code

Step definitions map each Gherkin line to code. Modern Cucumber prefers Cucumber Expressions, such as matching `the balance is {double}`, over raw regular expressions, because they are readable and support typed parameters and custom parameter types. Interviewers want to know you understand that one step definition can serve many scenarios, and that ambiguous or duplicate step definitions are a real failure mode Cucumber will reject at runtime.

The follow-up is almost always about sharing state between steps. The Given step sets up data that the Then step must assert against, and those are separate methods. The clean answer is dependency injection: a scenario-scoped context object (PicoContainer in Cucumber-JVM, or the World in Cucumber.js) that is created fresh per scenario and injected into each step class. Static fields shared across steps are the classic mistake that breaks parallel runs.

Prefer Cucumber Expressions with typed parameters over brittle regex where possible.
Share state through a per-scenario context bean, never static variables.
Avoid assertions inside Given steps. Setup fails loudly, expectations belong in Then.
One step definition, many scenarios. Duplicate steps trigger an ambiguous-step error.

Hooks, Tags, and Execution Control

Hooks run setup and teardown outside the feature file so scenarios stay clean. @Before and @After wrap every scenario, @BeforeStep and @AfterStep wrap each step, and tagged hooks such as @Before('@payments') run only for scenarios carrying that tag. A common use is launching the driver in @Before, capturing a screenshot on failure in @After using the Scenario object, and quitting the driver afterward.

Tags double as your execution filter. You annotate scenarios with @smoke, @regression, or @payments, then select them with a tag expression on the command line or in the runner, for example `@smoke and not @wip`. A good answer connects tags to the pipeline: smoke on every pull request, full regression nightly, and @wip excluded everywhere so half-written scenarios never break the build.

Data Tables, Scenario Outlines, and Parameterization

When the same rule has several inputs, a Scenario Outline plus an Examples table beats copy-paste. The outline uses placeholders in angle brackets, and Cucumber runs the scenario once per data row, reporting each as its own result. Data Tables are different: they pass a block of structured data into a single step, which Cucumber can transform into a list of maps or a list of typed objects using a DataTableType.

A sharp answer distinguishes the two clearly: 'Scenario Outline is for running one behavior across many example rows, so each row is a separate test result. A Data Table is one input structure handed to one step, like a basket of items. I use DataTableType or a transformer to convert rows straight into domain objects so the step code stays clean.' That precision separates people who read the docs from people who ship with it.

`Scenario Outline` with `Examples:` yields one result per row, great for boundary rules.
Angle-bracket placeholders like `<amount>` bind to Examples columns.
Data Tables feed structured input to a single step, transformed via DataTableType.

Wiring Cucumber Into A Real Framework

Expect architecture questions. In Cucumber-JVM you have a runner (JUnit Platform engine or TestNG) that points at the feature files and the glue package, plus plugins for reports such as the built-in HTML report or Allure. The layering that impresses: feature files at the top, thin step definitions that translate language into actions, a service or page-object layer that does the real work, and utilities plus config underneath. Steps should orchestrate, never contain raw Selenium or REST calls.

Interviewers also probe integration. Cucumber sits happily on top of Selenium for UI behavior and REST Assured for API behavior, and the same step layer can drive either. The key message is that Cucumber is a specification and orchestration layer, so your page objects, API clients, and test data builders live below it and are reusable with or without Gherkin.

Runner points at features plus a glue package; keep glue in one predictable path.
Steps delegate to page objects or API clients. No selectors or HTTP calls in steps.
Add reporting plugins (HTML, JSON, Allure) and publish them as CI artifacts.

Scenario-Based And Troubleshooting Questions

A favorite scenario: 'Your suite grew to 300 scenarios and the business stopped reading them. What went wrong?' The answer is that scenarios drifted imperative and duplicated flows at the UI level, so they became slow tests dressed as documentation. The fix is pruning to business-rule examples, pushing detailed coverage down to API and unit layers, and reserving Gherkin for behavior a stakeholder genuinely cares to review.

Another common one: intermittent failures when you switch on parallel execution. The usual culprit is shared mutable state, static WebDriver instances or step data leaking across threads. You fix it with scenario-scoped dependency injection, a ThreadLocal driver, and independent test data per scenario. If they ask about ordering dependencies, the correct stance is that every scenario must set up its own state and never rely on a previous scenario having run.

Behavioral And Collaboration Questions

Because BDD is a team practice, panels ask how scenarios get written. The credible answer references the three amigos: a business representative, a developer, and a tester refining a story together, often through example mapping on cards, so acceptance criteria become concrete examples before any code exists. You are not the sole author of feature files. You are the person who makes sure the examples are testable and complete.

You may also get: 'Business insists every rule stays a UI scenario, and the suite is now too slow. What do you do?' A mature answer educates rather than complies blindly. You explain the test pyramid economics, offer to keep a thin layer of end-to-end journeys for confidence, and move the bulk of rule coverage to the API or service level where it runs in seconds. You are protecting both speed and the readability the business values.

Frequently Asked Questions

What is the difference between BDD and Cucumber?

BDD is a collaboration practice where business, development, and QA agree on concrete examples of behavior before coding. Cucumber is a tool that executes those examples as tests. You can do BDD without Cucumber, and you can misuse Cucumber without doing any real BDD.

What is the difference between a Scenario Outline and a Data Table in Cucumber?

A Scenario Outline runs the same scenario once per row of an Examples table, and each row is reported as a separate test. A Data Table passes one block of structured data into a single step, which you can transform into objects. Outlines vary the whole test; data tables feed one step.

How do you share data between step definitions in Cucumber?

Use dependency injection with a scenario-scoped context object, such as PicoContainer in Cucumber-JVM or the World in Cucumber.js. It is created fresh for each scenario and injected into every step class. Avoid static variables, which leak state across scenarios and break parallel execution.

What are hooks in Cucumber and when do you use them?

Hooks are blocks that run outside the feature file. @Before and @After wrap each scenario for setup and teardown, and tagged hooks run only for matching scenarios. Common uses include starting the driver, seeding data, and capturing a screenshot on failure using the Scenario object.

Why should Gherkin scenarios be declarative instead of imperative?

Declarative scenarios state intent, so they read like product rules and survive UI changes. Imperative scenarios spell out clicks and selectors, which couples your documentation to the interface and makes business readers stop reviewing it. Keep mechanics in step definitions and the feature file readable.

How do you handle a Cucumber suite that has become too large and slow?

Prune scenarios to genuine business-rule examples, remove duplicated UI flows, and push detailed coverage down to API and unit tests. Keep a thin set of end-to-end journeys for confidence. Use tags to run smoke on pull requests and full regression nightly rather than everything on every build.