BDD questions are common in product company interviews and some service companies. Even if your current project does not use Cucumber, knowing it shows breadth. The key is explaining the COLLABORATION aspect — BDD is not a testing tool, it is a communication method.
Q: What is BDD? How is it different from TDD?
A: BDD (Behavior-Driven Development) focuses on the behavior of the application from the user perspective, written in plain English using Given-When-Then syntax. TDD (Test-Driven Development) focuses on code — write a unit test first, then write code to pass it. The key difference: TDD is developer-centric (unit tests in code), BDD is team-centric (scenarios in natural language that business analysts, developers, and testers all understand). BDD bridges the gap between business requirements and test automation. In my project, we use Cucumber for BDD: the BA writes the feature file in Gherkin, developers and testers review it, and I automate the step definitions. The feature file serves as both the requirement document and the test — single source of truth.
Q: What is Gherkin? What are the main keywords?
A: Gherkin is the plain-text language used to write Cucumber feature files. Keywords: Feature — describes the feature being tested. Scenario — a specific test case. Given — precondition/setup (user is on the login page). When — action (user enters credentials and clicks login). Then — expected outcome (user should see the dashboard). And/But — additional steps within Given/When/Then. Scenario Outline — parameterized scenario that runs with multiple data sets from an Examples table. Background — common Given steps shared across all scenarios in a feature file. Example: Feature: User Login. Scenario: Successful login. Given user is on login page. When user enters "admin" and "pass123". Then user should see dashboard. The feature file is readable by anyone — no technical knowledge needed.
Q: What is a Scenario Outline? How is it different from a regular Scenario?
A: A Scenario runs once with fixed values. A Scenario Outline runs multiple times with different data from an Examples table — it is BDD data-driven testing. Syntax: Scenario Outline: Login with different credentials. Given user is on login page. When user enters "<username>" and "<password>". Then login result should be "<result>". Examples: | username | password | result | | admin | pass123 | success | | invalid | wrong | error | | "" | pass123 | validation |. The angle brackets <username> are placeholders replaced by each row in the Examples table. This scenario runs 3 times — once per row. I use Scenario Outline for: login with multiple credentials, form validation with various inputs, search with different keywords. It eliminates writing 10 separate Scenarios for the same flow with different data.
Q: What are step definitions? How do they connect to feature files?
A: Step definitions are Java methods that implement the Gherkin steps. Cucumber matches each step in the feature file to a method annotated with @Given, @When, or @Then using regex or Cucumber expressions. Example: @Given("user is on login page") public void userOnLoginPage() { driver.get(baseUrl + "/login"); }. @When("user enters {string} and {string}") public void userEnters(String username, String password) { loginPage.enterUsername(username); loginPage.enterPassword(password); loginPage.clickLogin(); }. @Then("user should see dashboard") public void userSeesDashboard() { assertTrue(dashboardPage.isPageLoaded()); }. The step definition connects Gherkin (what to test) with Selenium (how to test). I keep step definitions thin — they call page object methods, not raw Selenium code. The glue path in the runner class tells Cucumber where to find step definitions.
Q: What are Cucumber hooks? How are they different from TestNG annotations?
A: Cucumber hooks are methods annotated with @Before and @After that run before/after each Scenario. @Before: set up WebDriver, navigate to base URL. @After: take screenshot on failure, close browser. They are similar to TestNG @BeforeMethod/@AfterMethod but specific to Cucumber. Key differences: Cucumber hooks are tagged — @Before("@smoke") runs only before scenarios tagged @smoke. Cucumber hooks receive a Scenario object for metadata: @After public void tearDown(Scenario scenario) { if (scenario.isFailed()) { byte[] screenshot = ((TakesScreenshot) driver).getScreenshotAs(OutputType.BYTES); scenario.attach(screenshot, "image/png", "failure"); } driver.quit(); }. There are also @BeforeStep and @AfterStep hooks (less common). Execution order: @Before hooks > Background steps > Scenario steps > @After hooks.
Q: What are tags in Cucumber? How do you use them?
A: Tags categorize scenarios for selective execution. Add @smoke, @regression, @login above a Scenario or Feature. Run specific tags from the runner: @CucumberOptions(tags = "@smoke"). Boolean logic: "@smoke and @login" (both), "@smoke or @regression" (either), "not @broken" (exclude). In my project: @smoke on critical path scenarios, @regression on all scenarios, @wip for work-in-progress (excluded from CI runs). Tags can also be used with hooks: @Before("@database") sets up a database connection only for database-related scenarios. From the command line: mvn test -Dcucumber.filter.tags="@smoke". This gives the same flexibility as TestNG groups but with plain-text scenario organization.
Q: How do you integrate Cucumber with Selenium and TestNG?
A: Dependencies in pom.xml: cucumber-java, cucumber-testng (or cucumber-junit), selenium-java. Create a runner class: @CucumberOptions(features = "src/test/resources/features", glue = "com.project.stepdefs", plugin = {"pretty", "html:target/cucumber-report.html"}, tags = "@smoke"). public class TestRunner extends AbstractTestNGCucumberTests { @Override @DataProvider(parallel = true) public Object[][] scenarios() { return super.scenarios(); } }. The runner extends AbstractTestNGCucumberTests for TestNG integration. Feature files go in src/test/resources/features. Step definitions in the glue package. Page objects are injected via dependency injection (PicoContainer or Spring). For parallel execution, override the scenarios() DataProvider with parallel = true and configure thread count in testng.xml.
Q: What is Background in Cucumber? When do you use it?
A: Background contains Given steps that are common to ALL scenarios in a feature file. It runs before each scenario, just like @Before hook but written in Gherkin. Example: Background: Given user is on login page And user logs in as "admin". This avoids repeating the same login steps in every scenario. Use Background when: all scenarios in the feature share the same precondition. Do not use it when: only some scenarios need the precondition (use separate Given steps instead) or when the Background becomes too long (it runs before EVERY scenario, including ones that might not need all those steps). Keep Background short — ideally 1-3 steps. If it grows beyond that, consider splitting the feature file.
Q: How do you generate reports in Cucumber?
A: Three reporting options: (1) Built-in — plugin = {"pretty", "html:target/cucumber.html", "json:target/cucumber.json"} in @CucumberOptions. The HTML report is basic but functional. (2) Cucumber Reports Service — plugin = {"me.jvt.cucumber.report.PrettyReports:target/cucumber"} generates a rich HTML report with charts and step details. (3) Allure with Cucumber — use the allure-cucumber7-jvm plugin for the same Allure reports I use with TestNG. In my framework, I generate both: JSON output for CI pipeline parsing and HTML report for human review. The JSON report can be published to Cucumber Reports cloud service for team sharing. For CI, Jenkins reads the JSON report to show pass/fail trends.
Q: What are the advantages and disadvantages of BDD with Cucumber?
A: Advantages: (1) Feature files are readable by non-technical stakeholders — BA, PM, client. (2) Living documentation — feature files are both specs and tests. (3) Enforces Given-When-Then thinking, which improves test design. (4) Reusable step definitions across scenarios. (5) Tags enable flexible test organization. Disadvantages: (1) Extra layer of abstraction — feature file, step definition, page object, test data. More files to maintain. (2) Step definition maintenance — renaming a Gherkin step requires updating all feature files that use it. (3) Regex complexity — matching step definitions can get tricky with special characters. (4) Overkill for small teams where everyone is technical — POM + TestNG is simpler. My recommendation: use Cucumber when the team includes non-technical stakeholders who need to read and contribute to test scenarios. Use TestNG directly when the team is all engineers.
Key Point: BDD is about collaboration, not just Cucumber syntax. Explain how feature files bridge the gap between business and engineering.