BDD Cucumber Interview Questions for 3 Years Experience (2026)

Short answer: a good scenario describes behaviour in business language (declarative). A bad one lists UI clicks (imperative), so it breaks whenever the screen changes and nobody outside QA reads it.

# Imperative - avoid
Given I open "/login"
When I type "qa@example.com" into "#email"
And I click "#submit"

# Declarative - prefer
Given a registered customer
When they sign in with valid details
Then they see their order history

One scenario should check one behaviour; if you need many Then lines about unrelated things, split it.

Short answer: when the same behaviour must be checked with different data. Each Examples row runs as its own scenario.

Scenario Outline: Coupon rules
  Given a cart worth <total> rupees
  When the customer applies coupon "<code>"
  Then the discount is <discount> rupees

  Examples:
    | total | code    | discount |
    | 1000  | SAVE10  | 100      |
    | 300   | SAVE10  | 0        |

Avoid huge Examples tables; data-heavy checks are often better as unit or API tests.

Short answer: use Background for setup that a business reader needs to see ("Given a logged-in customer"). Use hooks (@Before) for technical setup readers do not care about (starting a browser, clearing a database).

Keep Background short; if it grows, the feature file probably covers too many behaviours.

Short answer: each step text is matched to a method by a Cucumber expression (or a regular expression). Parameter types like {int} and {string} are converted for you.

@Given("a cart worth {int} rupees")
public void aCartWorth(int total) { cart = carts.createWithTotal(total); }

@When("the customer applies coupon {string}")
public void applyCoupon(String code) { result = cart.apply(code); }

Common failures: undefined step (no match - Cucumber prints a snippet to paste) and ambiguous step (two methods match - make one expression more specific).

Short answer: use dependency injection (for example cucumber-picocontainer). Cucumber creates one instance of a shared context class per scenario and passes it to every step class that asks for it. Do not use static fields - they leak between scenarios and break parallel runs.

public class ScenarioContext { public Cart cart; public Response lastResponse; }

public class CartSteps {
    private final ScenarioContext ctx;
    public CartSteps(ScenarioContext ctx) { this.ctx = ctx; }  // injected
}

Short answer: an @After hook receives the Scenario; check isFailed() and attach the image so it appears in the report.

@After
public void afterScenario(Scenario scenario) {
    if (scenario.isFailed()) {
        byte[] png = ((TakesScreenshot) driver).getScreenshotAs(OutputType.BYTES);
        scenario.attach(png, "image/png", scenario.getName());
    }
    driver.quit();
}

Tagged hooks such as @Before("@db") run only for scenarios with that tag.

Short answer: tag scenarios or features and pass a tag expression.

mvn test -Dcucumber.filter.tags="@smoke and not @wip"

Tag expressions support and, or, not and brackets. Keep a small agreed tag list (@smoke, @regression, @wip) so tags stay meaningful.

Short answer: with the cucumber-junit-platform-engine, enable parallel execution in junit-platform.properties:

cucumber.execution.parallel.enabled=true
cucumber.execution.parallel.config.strategy=fixed
cucumber.execution.parallel.config.fixed.parallelism=4

Before turning it on, make sure drivers and scenario context are per-scenario (injected, not static) and that scenarios do not share test data.