BDD & Cucumber Interview Questions & Answers
These are the BDD and Cucumber questions automation testers and SDETs are asked most — from Gherkin basics to hooks, runners, state sharing and parallel runs. Each answer is interview-length, with code where it helps. For the full learning path, see The Complete Cucumber BDD Tutorial.
BDD Fundamentals (Q1–5)
Q1. What is BDD?
Behavior-Driven Development: business, developers and QA agree on concrete examples of how the system should behave, written in plain language (Gherkin). Those examples become automated acceptance tests and living documentation.
Learn more: BDD Fundamentals & Gherkin
Q2. Why use BDD in automation?
It gives technical and non-technical people a shared, readable specification; tests trace directly to business behavior; and the scenarios document what the system does. The benefit only comes when the business actually helps write or review the scenarios.
Q3. BDD vs TDD?
TDD is a developer practice at unit level — write a failing unit test, then the code. BDD is a team practice at feature level — agree on behavior examples in Gherkin, then automate them. They complement each other.
Learn more: BDD vs TDD
Q4. What is Gherkin, and what are its keywords?
The plain-text language of feature files.
Keywords: Feature, Rule, Background, Scenario (or Example), Scenario Outline, Examples, Given, When, Then, And, But — plus tags (@), comments (#), DataTables (|) and doc strings (""").
Learn more: Cucumber & Gherkin Cheat Sheet
Q5. Declarative vs imperative scenarios?
Imperative scenarios describe clicks ("user enters username in field…"); declarative ones describe behavior ("the user logs in with valid credentials").
Prefer declarative — it's readable for the business and doesn't break when the UI changes.
Feature Files (Q6–10)
Q6. What is a feature file?
A .feature file describing one business feature in Gherkin: a Feature title and description, and one or more scenarios. One feature file should cover one behavior.
Learn more: Feature Files Explained
Q7. Scenario vs Scenario Outline? ⭐
A Scenario runs once. A Scenario Outline is a template that runs once per row of its Examples table, with <placeholders> replaced by each row's values:
Scenario Outline: Login with different users
When the user logs in as "<username>" with "<password>"
Then the "<result>" should be shown
Examples:
| username | password | result |
| standard_user | secret_sauce | products page |
| locked_out_user | secret_sauce | locked-out message |
Q8. What is Background?
Steps that run before every scenario in the feature file — for shared preconditions like "Given the user is logged in".
Keep it short; if only some scenarios need the steps, don't use Background.
Q9. Background vs a @Before hook?
Background is visible business context in the feature file.
A hook is hidden technical setup in code (start a browser, seed data).
If the business should see it, use Background; if it's plumbing, use a hook.
Q10. What are DataTables and doc strings?
A DataTable passes a table of data to one step; a doc string passes a multi-line block, such as a JSON body:
Scenario: Register a new user
Given the following user details:
| name | Asha |
| email | asha@example.com |
When the API receives:
"""
{ "name": "Asha", "email": "asha@example.com" }
"""
Then the user should be created
@Given("the following user details:")
public void userDetails(DataTable table) {
Map<String, String> user = table.asMap(String.class, String.class);
}
Step Definitions (Q11–15)
Q11. What is a step definition?
A Java method annotated with @Given, @When or @Then whose expression matches a Gherkin step.
The annotation keyword doesn't matter for matching — the text does.
Learn more: Step Definitions & Cucumber Expressions
Q12. Cucumber expressions vs regular expressions?
@When("the user adds {int} items of {string} to the cart") // Cucumber expression
public void addItems(int qty, String product) { }
@When("^the user adds (\\d+) items of \"([^\"]*)\" to the cart$") // regular expression
public void addItemsRegex(int qty, String product) { }
Cucumber expressions ({int}, {string}, {word}, {float}) are the modern default — simpler to read.
Regular expressions are still supported when you need more control.
Q13. What happens when a step definition is missing or duplicated?
A missing one makes the step undefined, and Cucumber prints a snippet to implement.
Two matching definitions cause an AmbiguousStepDefinitionsException.
Fix: Ambiguous & Undefined Steps.
Q14. Given vs When vs Then?
- Given sets up context.
- When performs the action.
- Then checks the outcome.
- And / But continue the previous type.
Ideally one When per scenario — several Whens usually mean the scenario tests too much.
Q15. Can step definitions be reused across feature files?
Yes. Cucumber matches step text against all glue code, so one definition serves every feature using that wording — which is why consistent step wording matters.
Hooks, Tags & Execution (Q16–21)
Q16. What are hooks?
@Before
public void setUp() { /* start browser */ }
@Before(value = "@db", order = 1) // only for @db scenarios; lower order runs first
public void seed() { /* insert test data */ }
@After
public void tearDown(Scenario scenario) {
if (scenario.isFailed()) {
byte[] png = ((TakesScreenshot) driver).getScreenshotAs(OutputType.BYTES);
scenario.attach(png, "image/png", "failure");
}
driver.quit();
}
There are also @BeforeStep / @AfterStep, and @BeforeAll / @AfterAll for once-per-run setup.
Q17. What are tags used for?
Grouping and selecting scenarios — @smoke, @regression, @wip — and scoping hooks.
They go on features (inherited by all scenarios), rules, scenarios, outlines and individual Examples tables.
Learn more: Cucumber Tags & Test Execution
Q18. How do you run specific tags?
In the runner:
tags = "@smoke and not @wip"
Or from the command line:
mvn test -Dcucumber.filter.tags="@regression and not @wip"
Expressions support and, or, not and parentheses.
Q19. What goes in the runner class?
@CucumberOptions(
features = "src/test/resources/features",
glue = {"stepDefinitions", "hooks"},
tags = "@smoke",
plugin = {"pretty", "html:target/cucumber.html", "json:target/cucumber.json"},
monochrome = true,
dryRun = false
)
public class TestRunner extends AbstractTestNGCucumberTests { }
- features = where the feature files are
- glue = packages with step definitions and hooks
- plugin = reports
- dryRun = check that every step has a definition without executing anything
Q20. How do you run Cucumber scenarios in parallel?
With TestNG, override the scenarios provider:
@Override
@DataProvider(parallel = true)
public Object[][] scenarios() {
return super.scenarios();
}
Each scenario then needs its own browser — a ThreadLocal driver or per-scenario dependency injection.
With JUnit 5, enable:
cucumber.execution.parallel.enabled=true
Q21. How do you generate reports?
Through plugin options (HTML, JSON, JUnit XML), plus tools like Allure or the Cucumber reports plugin in Jenkins — with screenshots attached in an @After hook.
Framework Design (Q22–25)
Q22. How does Cucumber work with the Page Object Model? ⭐
Feature files describe behavior; step definitions stay thin and call page-object methods; page objects hold locators and Selenium code.
Business logic never lives in the step definitions.
Learn more: Hybrid Framework With POM
Q23. How do you share state between step definition classes?
With dependency injection (for example PicoContainer): create a context class holding the driver and scenario data, and inject it through each step class's constructor.
Cucumber creates a fresh instance per scenario.
Avoid static fields — they break parallel runs.
Q24. What is the Rule keyword?
Introduced in Gherkin 6, Rule groups scenarios that illustrate one business rule inside a feature:
Feature: Coupons
Rule: A coupon can be used only once per customer
Scenario: First use is accepted
Given the customer has not used coupon "SAVE10"
When they apply "SAVE10"
Then a 10% discount is applied
Scenario: Second use is rejected
Given the customer has already used coupon "SAVE10"
When they apply "SAVE10"
Then the error "Coupon already used" is shown
Q25. What are the biggest challenges with BDD — and how did you handle them?
Imperative, UI-heavy Gherkin; duplicated step wording; fat step definitions; test data; and business people not engaging.
Solutions: declarative scenarios, step-wording guidelines and reusable parameterized steps, thin steps over page objects, externalised data, and writing scenarios together in refinement.
Learn more: BDD Challenges in Real Projects
See how feature files, step definitions and hooks connect in the Cucumber BDD Visualizer.
From the Interview Room
BDD and TDD are part of the frameworks I've worked with. What makes BDD valuable is the conversation: scenarios written in plain language that testers, developers and product people all understand, which is also the idea behind Testsigma's plain-English test creation. Keep each scenario focused on one behavior and let the step definitions call your existing page and business-library code. Be ready to show a feature file, its step definitions and how they connect to your page classes.
📚 Official documentation: Cucumber documentation
FAQs
Which Cucumber questions are asked most?
Scenario vs Scenario Outline, Background, tags, hooks, runner options, step definitions and how Cucumber fits with POM.
Do I need to write Gherkin in the interview?
Often — usually a Scenario Outline for a login or search feature. Practice writing one from memory.
Is Cucumber only for Java?
No. Cucumber has official implementations for Java, JavaScript and Ruby, among others; SpecFlow/Reqnroll (.NET) and Behave (Python) follow the same Gherkin approach.
What does dryRun do?
It checks that every step has a matching definition without executing any code — a fast way to find undefined steps.
Is BDD the same as using Cucumber?
No — BDD is the collaboration; Cucumber is a tool for automating the resulting examples.
Next Steps
- The Complete Cucumber BDD Tutorial
- The Complete Automation Framework Guide
- The Complete SDET Interview Guide
