82 Cucumber interview questions with answers

What they are assessing

Whether you separate the practice from the tool.

Model answer

BDD is a collaboration practice where business, development and testing agree concrete examples of behaviour before code is written, expressed in a shared language everyone understands. Cucumber is a tool that executes those examples by mapping the plain language steps to code. The distinction matters: you can do BDD with no tool at all, and you can use Cucumber with no BDD, which is what most teams actually do. The value is in the conversation that produces the examples, and the automation is a by-product.

Likely follow-up

If the value is in the conversation, why automate the examples at all?

What they are assessing

Knowledge of the collaboration ritual.

Model answer

A conversation between three perspectives before a story is built: business, usually the product owner, who says what is wanted and why; development, who says what is feasible and raises technical implications; and testing, who asks what happens when it goes wrong. The output is a set of concrete examples that become the scenarios. The point is that the three roles find different gaps, and holding the conversation before coding is far cheaper than discovering the disagreement in review.

What they are assessing

Understanding of the underlying idea.

Model answer

Describing intended behaviour through concrete examples rather than abstract rules, because examples are harder to misread. Instead of stating that discounts apply to bulk orders, you state that an order of ten units at two pounds costs eighteen pounds. Ambiguity surfaces immediately when someone disagrees about a number. Those examples then become both the specification and the automated tests, which is where the living documentation idea comes from: documentation that cannot drift from the system because it fails when it does.

What they are assessing

Honest judgement, which interviewers value here.

Model answer

When no business person will ever read the feature files, which is the common case. If the only readers are the engineers who wrote them, the Gherkin layer adds indirection, a glue maintenance burden and slower execution for no benefit, and the same coverage is cheaper in plain JUnit or TestNG. It is also poor for technical checks such as API contract or performance, where the plain language layer obscures rather than clarifies. Cucumber earns its cost when the scenarios are genuinely a shared artefact.

Trap to avoid

Defending Cucumber unconditionally. Interviewers who have maintained a large suite are usually testing whether you know its cost.

What they are assessing

Diagnostic insight.

Model answer

Look at who writes the feature files and when. If scenarios are written by testers after the code is complete, it is automation with extra steps. If they are written collaboratively before development and used to drive it, it is BDD. Other signals are whether anyone outside engineering has ever opened a feature file, whether the steps use business language or reference buttons and fields, and whether acceptance criteria and scenarios are the same artefact or two documents that drifted apart.

What they are assessing

Basic syntax recall.

Model answer

Gherkin is the plain text language Cucumber parses. The keywords are Feature for the file level description, Scenario or Example for a single case, Given, When and Then for the steps, with And and But for continuation, Background for steps shared by every scenario in the file, Scenario Outline with Examples for data driven scenarios, and Rule in Gherkin 6 for grouping related scenarios under a business rule. There are also doc strings, data tables, tags and comments.

What they are assessing

Whether you use them correctly rather than as decoration.

Model answer

Given establishes the starting context: the state the world is in before the behaviour under test. When is the action or event being exercised, and there should usually be exactly one. Then states the expected outcome, observable from outside the system. Keeping them in their roles matters because a scenario with three Whens is usually testing three things, and a Then that performs an action rather than asserting is a sign the scenario has lost its shape.

Likely follow-up

What does it suggest if a scenario has several When steps?

What they are assessing

Understanding of shared setup and its cost.

Model answer

Background holds steps that run before every scenario in the file, so common setup is written once. It is useful for genuinely universal context such as being logged in as a standard user. The caution is that it runs before every scenario, so a long Background slows the whole file, and it moves context away from the scenario, which hurts readability: a reader has to scroll up to understand what state the scenario starts in. Three or four lines is a reasonable ceiling.

What they are assessing

Data driven Gherkin.

Model answer

A Scenario Outline is a template with placeholders in angle brackets, paired with an Examples table supplying values. Cucumber expands it into one scenario per data row, each reported separately. It is the right structure when the same behaviour needs checking across several inputs, such as validation rules for different field values. The risk is overuse: an Examples table with twenty rows covering unrelated cases produces a scenario nobody can read, and those usually want splitting into separate outlines with meaningful names.

What they are assessing

Knowledge of multi-line arguments.

Model answer

A doc string is a multi-line block of text passed to a step, delimited by three double quotes, preserving line breaks. It is used when the argument is genuinely long or structured: a JSON request body, an email body, or an expected message spanning lines. The alternative is a data table, which suits tabular data better. Doc strings support a content type annotation after the opening delimiter, which some tools use for syntax highlighting.

What they are assessing

Awareness of newer syntax.

Model answer

Rule groups scenarios that illustrate one business rule, sitting between Feature and Scenario, with Example as a synonym for Scenario beneath it. It makes the structure of a feature explicit: this rule, illustrated by these examples. It is worth adopting where features cover several related rules, because it improves readability for business readers, which is the whole point of the layer. It requires tool support, and older reporting plugins sometimes render it awkwardly, which is the practical reason teams have been slow to move.

What they are assessing

The single most important Gherkin skill.

Model answer

Describe intent rather than interaction. Imperative: enter admin in the username field, enter secret in the password field, click the login button. Declarative: given I am logged in as an administrator. The declarative version survives a UI redesign, reads as business language, and hides mechanics in the step definition where they belong. The imperative version is a script written in Gherkin, which is slower to run, harder to read and needs editing every time a field moves.

Trap to avoid

Writing UI mechanics into feature files. It is the most common Cucumber failure and interviewers will ask you to rewrite an imperative scenario on the spot.

What they are assessing

Balance between concreteness and brittleness.

Model answer

Concrete values are the point of specification by example, so yes where the value is the behaviour: an order of ten units costing eighteen pounds is exactly what should be stated. What should not appear is incidental data: a specific account number, an internal identifier, or a date that will expire. Those belong behind a step such as given an existing customer, with the step definition creating or selecting one. The test is whether a business reader would care about the value.

What they are assessing

Basic organisation.

Model answer

One Feature per file, named after the capability, with a short narrative describing who wants it and why, conventionally in the as a, I want, so that form. Then scenarios, each with a descriptive name stating the case rather than the steps. Tags above the feature or individual scenarios. Optionally a Background. Files live in a features directory, usually organised into folders by area, and the runner glue path points at the package containing the step definitions.

What they are assessing

Judgement about file organisation.

Model answer

Enough to cover one capability and no more, which usually lands somewhere between five and fifteen. The signal to split is that the Background no longer applies to everything in the file, or the feature narrative has become vague enough to cover several things. Very large feature files are hard to navigate and tend to accumulate scenarios that belong elsewhere. Splitting by business capability rather than by screen keeps them meaningful as documentation.

What they are assessing

Attention to the artefact business people read.

Model answer

It should state the case and ideally the expected outcome, so the name alone is informative in a report. Successful login is weak; login is rejected after three failed attempts is useful, because when it appears in a failure report the reader knows what broke without opening the file. Names that merely restate the steps add nothing, and names such as test 1 make a report useless. It is a small discipline with a large payoff during triage.

What they are assessing

A question about practice, not tooling.

Model answer

Collaboratively, with the product owner or business analyst leading on the examples and the tester shaping them into scenarios. In practice a tester usually does the drafting, which is fine, provided the business reviews and can genuinely follow them. What does not work is engineering owning them entirely, because the language then drifts technical and the business stops reading, at which point the plain language layer is pure overhead. Ownership is the thing that decides whether Cucumber pays for itself.

What they are assessing

The core mapping concept.

Model answer

A method annotated with a pattern that matches a Gherkin step, containing the code that performs it. When Cucumber runs a scenario, it matches each step against the available definitions and executes the one that matches, passing any captured parameters as arguments. In Cucumber-JVM the annotations are @Given, @When and @Then, though they are interchangeable in matching terms: a step written as Given can match a definition annotated @Then, because the keyword is for readability rather than matching.

Likely follow-up

So does it matter which annotation you use on a step definition?

What they are assessing

Modern syntax knowledge.

Model answer

Cucumber Expressions are a simpler pattern syntax using typed placeholders such as {int}, {string}, {word} and {float}, so a step reads I have {int} items rather than a regex with capture groups. They are more readable, produce typed parameters automatically, and support custom parameter types. Regular expressions are still supported and remain necessary for complex matching such as optional phrases or alternation. For most steps the expression is clearer, and mixing both in one project is normal.

What they are assessing

Knowledge of a genuinely useful feature.

Model answer

A registered type that converts a matched string into a domain object automatically, defined with @ParameterType in Cucumber-JVM. So a step saying given a premium customer can capture premium and hand the definition a CustomerType enum rather than a string to parse. The benefits are type safety, conversion logic written once rather than in every definition, and steps that read naturally. It is one of the cleanest ways to reduce duplication in a growing glue layer.

What they are assessing

A common failure everyone hits.

Model answer

It occurs when a step matches more than one definition, and Cucumber refuses to guess, failing with an AmbiguousStepDefinitionsException listing the candidates. The usual cause is two patterns that overlap, often because one is too loose, such as a regex with a broad wildcard. The fix is tightening the patterns or consolidating the definitions. The related error is DuplicateStepDefinitionException, which is the same pattern registered twice, typically because the glue path picks up a class in two places.

What they are assessing

Workflow knowledge.

Model answer

A step in a feature file with no matching definition. Cucumber reports the scenario as undefined rather than failed, and prints a snippet you can paste as a starting definition, which is how you normally begin implementing a new feature. Running with dryRun enabled checks all steps have definitions without executing anything, which is a fast way to validate a feature file before committing and a useful build step in its own right.

Likely follow-up

How would you make the build fail on undefined steps?

What they are assessing

The maintainability question.

Model answer

Keep them thin: a step definition should express intent and delegate, not contain page interactions or business logic. Interactions belong in page objects or service clients, and logic belongs in helpers. Organise definitions by domain rather than one giant class, and watch for near duplicate steps that differ by a word, which is what happens when people write a new step instead of searching for an existing one. A step definition longer than about ten lines is usually doing something that belongs elsewhere.

What they are assessing

A real scaling problem.

Model answer

Enforce reuse before writing: search existing steps first, which most IDE plugins support. Parameterise instead of duplicating, so I see the error {string} replaces five near identical steps. Agree phrasing conventions early, because the explosion is usually caused by the same idea written three ways by three people. And review feature files as you would code, since that is where the duplication originates. A suite with four hundred steps for eighty scenarios has a phrasing problem, not a coverage problem.

Trap to avoid

Treating the glue layer as not real code. It is the part that decays fastest and it needs the same review as the application.

What they are assessing

Lifecycle knowledge.

Model answer

Blocks of code that run around scenarios and steps: @Before and @After run before and after each scenario, @BeforeStep and @AfterStep around each step, and @BeforeAll and @AfterAll once for the whole run in recent versions. They hold setup and teardown that should not appear in the feature file, such as launching a browser, resetting data, or capturing a screenshot on failure. Keeping that out of Gherkin is important, because browser lifecycle is not business behaviour.

What they are assessing

Detail knowledge.

Model answer

With the order attribute on the annotation. For @Before, lower order values run first; for @After, the order is reversed so higher values run first, which mirrors setup and teardown symmetry. Without explicit ordering the sequence is undefined, and relying on incidental ordering produces failures when someone adds a hook. If you have several hooks that must run in a specific order, that is usually a sign they should be one hook calling things in sequence.

Likely follow-up

Two @Before hooks have no order specified. Which runs first?

What they are assessing

Tag aware setup.

Model answer

A hook with a tag expression, so it runs only for scenarios carrying those tags: @Before("@database") runs only for scenarios tagged database. It is how you apply expensive setup selectively rather than to every scenario, for example seeding data only where it is needed, or configuring a different browser for scenarios tagged mobile. It keeps the common path fast while still allowing specialised setup.

What they are assessing

Practical diagnostics.

Model answer

In an @After hook, check whether the Scenario object reports failure, take the screenshot from the driver, and attach it with scenario.attach, supplying the bytes, the media type and a name. The reporting plugin then embeds it in the report. Doing it in a hook means every scenario gets it without any step or feature file change. The detail that catches people out is taking the screenshot after the driver has already been quit, which produces an exception inside the hook.

What they are assessing

Design judgement.

Model answer

Hooks should hold technical lifecycle: browser or client setup and teardown, data reset, logging, evidence capture. They should not hold business setup that the scenario depends on, because that hides context from the reader: if a scenario needs an existing order, that should be a Given step, visible in the feature file, not something a hook silently arranges. The test is whether a business reader would be confused about where the state came from.

What they are assessing

Basic selection knowledge.

Model answer

Labels on features or scenarios, written with an at sign, used to select what runs. They let one suite serve several purposes: a smoke tag for the fast gating run, tags by feature area, a wip tag for work in progress excluded from CI, and a tag for scenarios requiring specific setup. They also drive conditional hooks. Selection happens in the runner configuration or on the command line, so the same codebase produces different runs without edits.

What they are assessing

Practical selection syntax.

Model answer

Modern Cucumber uses boolean expressions: "@smoke and not @wip" runs smoke scenarios that are not work in progress, "@payments or @checkout" runs either, and parentheses group them. This replaced the older comma and tilde syntax, where comma meant or and a tilde meant not, which is still seen in older projects. The common mistake carried over from that era is expecting a comma separated list to mean and, when it meant or.

Trap to avoid

Using the old tilde syntax on a modern version. It fails with an unhelpful parse error rather than silently, which at least makes it findable.

What they are assessing

A detail that affects selection.

Model answer

Yes. A tag on a Feature applies to every scenario in it, and a tag on a Scenario Outline applies to every generated example. Tags can also be placed on an Examples table, so one data set within an outline is selected differently from another, which is occasionally useful for excluding a known failing combination. Inheritance means a feature level tag can accidentally pull in more than intended, which is worth checking when a run includes scenarios you did not expect.

What they are assessing

Governance of a mechanism that sprawls.

Model answer

Agree a small, documented set with defined meanings, and treat adding a new tag as a decision rather than a habit. Typically that is one for the gating smoke run, a few for functional areas, one for work in progress, and one for quarantine. Tags that mean the same thing as the folder structure add nothing. And review them periodically, because a suite with sixty tags where nobody can say what half of them select is a suite where tag based selection has stopped being trustworthy.

What they are assessing

A frequently used feature.

Model answer

A table of values written under a step in pipe delimited form, passed to the definition as a DataTable object. From there you convert it: asList or asLists for simple values, asMap or asMaps when the first row is a header, giving a list of maps keyed by column name, which is the most common form. You can also convert directly into domain objects by registering a DataTableType, which keeps the definition clean and gives type safety.

Likely follow-up

How would you convert a data table straight into a list of domain objects?

What they are assessing

A distinction candidates confuse.

Model answer

An Examples table drives repetition: each row produces a separate scenario, reported separately, and the placeholders substitute into the steps. A data table is an argument to one step within a single scenario, used when the step needs structured input such as a list of items to add to a basket. So Examples means run this several times, data table means this step takes a table. Using an Examples table where a data table was needed produces several scenarios each handling one row, which is rarely the intent.

What they are assessing

Readability judgement.

Model answer

Small enough to read at a glance, which in practice means a handful of rows and columns. A table with fifteen columns has stopped being a specification and become a fixture file, and it will not be read by anyone in the business. When that happens the right move is usually to move the bulk data behind a Given step referencing a named data set, keeping only the values that matter to the behaviour in the feature file. The same applies to Examples tables with dozens of rows.

What they are assessing

Basic execution setup.

Model answer

In Cucumber-JVM it is a class annotated with @CucumberOptions, run by JUnit or TestNG. It configures features, the path to the feature files; glue, the package containing step definitions and hooks; plugin, the reporters; tags for selection; dryRun to check step coverage without executing; monochrome for readable console output; and publish or snippets options. Newer versions increasingly move this to a properties file or JUnit 5 platform configuration rather than an annotated class.

What they are assessing

A common configuration mistake.

Model answer

It tells Cucumber where to find step definitions and hooks. Getting it wrong produces undefined steps even though the definitions exist, which is confusing because the code is clearly there. The other failure is setting it too broadly, so it picks up classes from more than one place and registers a definition twice, producing a duplicate step definition error. The rule is to point it at the specific package containing the glue, not at the project root.

What they are assessing

Knowledge of a genuinely useful option.

Model answer

With dryRun enabled, Cucumber matches every step against the definitions and reports undefined or ambiguous ones without executing anything. It runs in seconds. The uses are validating a new feature file before implementing it, checking after a refactor that no step lost its definition, and running it as a fast build step so a broken glue mapping fails immediately rather than after a twenty minute suite. It is one of the cheapest quality checks available in a Cucumber project.

What they are assessing

Triage workflow.

Model answer

Add the rerun plugin, which writes the failed scenario locations to a file, typically target/rerun.txt. A second runner then takes that file as its features parameter and executes only those. It is useful during triage and for a retry stage in CI, though the same caution applies as with any retry: a scenario that passes on rerun is not passing, and the retry rate should be visible rather than quietly absorbed.

What they are assessing

Portability.

Model answer

As system properties or environment variables read by the glue code, with sensible defaults so a local run works without arguments, and supplied by the pipeline for each environment. Configuration should never be in the feature files, because the environment is not business behaviour. Credentials come from the CI secret store. The test of whether this is right is that the same jar runs against every environment with only a property changing, and nothing in the features has to be touched.

What they are assessing

The architectural problem every Cucumber project hits.

Model answer

Through dependency injection, which Cucumber-JVM supports via PicoContainer, Spring, Guice or others. You create a context or world object holding the shared state, and every step definition class takes it as a constructor argument; Cucumber creates a fresh instance per scenario and injects the same one everywhere, which gives sharing with isolation. PicoContainer is the lightest option and needs only the dependency on the classpath. Cucumber-JS solves the same problem with the World object.

Likely follow-up

Why does the injected context need to be per scenario rather than per run?

What they are assessing

Understanding of isolation.

Model answer

Because they persist across scenarios and across threads. State left by one scenario leaks into the next, producing order dependent failures that pass when the scenario runs alone. Under parallel execution it is worse: two scenarios write the same static field concurrently and both behave unpredictably. It works in a small serial suite, which is why it gets adopted, and it fails as soon as the suite grows or parallelism is enabled.

Trap to avoid

Using a static WebDriver or a static context object. It is the most common reason a Cucumber suite cannot be parallelised later.

What they are assessing

Design discipline.

Model answer

It should hold what genuinely crosses steps within one scenario: the driver or API client, identifiers created during the scenario, and the last response for assertions. It should not become a dumping ground for everything, because a context with thirty fields couples every step definition to every other and makes the scenario impossible to reason about. If a value is used by only one step, it is a local variable. Keeping the context small is what keeps steps independently readable.

What they are assessing

Scaling knowledge.

Model answer

With TestNG, extending AbstractTestNGCucumberTests and setting the data provider to parallel, with thread count in the suite XML. With JUnit 5 and the Cucumber engine, through junit-platform.properties setting execution parallel enabled and the strategy. Maven Surefire can also fork. Whichever route, the prerequisite is the same: scenarios must be independent, the driver and context must be per thread, and test data must not collide. Parallelism is a property of the suite design, not a configuration switch.

What they are assessing

Experience of doing it.

Model answer

Static state first: a shared driver or context, which produces failures that look random. Then test data collisions where several scenarios use the same account. Then hooks that assume exclusivity, such as one that truncates a database table between scenarios, which will wipe data another thread is using. Then reporting plugins that write to a shared file without synchronisation, producing corrupted output. I would expect to fix the context injection and the data isolation before anything else.

What they are assessing

Precision about the unit of parallelism.

Model answer

Yes, with the appropriate configuration; the unit of parallelism in modern Cucumber is the scenario, or each example of an outline, not the feature file. Older setups parallelised by feature file, which limited throughput when one file held many scenarios. The practical implication is that a Background running expensive setup is then executed per scenario across threads, which can hammer the environment, so moving heavy setup to a tagged hook or an API call becomes more important once parallelism is on.

What they are assessing

Output knowledge.

Model answer

Built in plugins produce pretty console output, HTML, JSON and JUnit XML. The JSON output is the important one because other tools consume it: the masterthought cucumber-reporting plugin builds a detailed HTML report from it, and Allure and Extent both integrate. JUnit XML is what the build system parses to show test results. In practice most teams use the JSON plugin plus one richer reporter, and publish the JUnit XML for the pipeline.

What they are assessing

Whether you have seen the idea succeed or fail.

Model answer

The idea that the feature files, plus their execution results, serve as documentation that cannot silently drift, because a scenario describing behaviour the system no longer has will fail. It works when the scenarios are declarative and business readable and someone actually consults them. It fails when features are imperative UI scripts, which nobody outside the team can read, or when the suite is partially disabled, at which point the documentation describes behaviour that is no longer verified. The idea is sound; it depends entirely on how the Gherkin was written.

What they are assessing

Triage quality.

Model answer

Attach evidence in an @After hook: screenshot, page source or the last API response, and the relevant logs, so the report carries them. Use a reporter that renders attachments, since the default HTML report is thin. Make scenario names descriptive so the failure list is readable without opening anything. And include the data row for scenario outlines, otherwise ten identical looking failures give no clue which example broke. The measure is whether someone can diagnose from the build page without rerunning locally.

What they are assessing

Recognition of a specific smell.

Model answer

A step containing and, doing two things: given I log in and navigate to the orders page. It is a problem because it cannot be reused independently, it hides a second action from the reader, and it usually grows further. The fix is splitting into two steps, or replacing both with a single higher level step expressing the intent, such as given I am viewing my orders, with the mechanics in the definition. The occasional and is fine when the two parts are genuinely one concept.

What they are assessing

Proportion.

Model answer

Because the Gherkin layer costs something: a glue method per step, slower execution, and an extra artefact to maintain. It earns that cost for scenarios a business reader will read. It does not earn it for a boundary value check on a numeric field, an API contract assertion or a performance threshold, all of which read better and run faster as plain unit or integration tests. A suite where every check is a scenario usually has a few hundred that nobody outside the team has ever opened.

Likely follow-up

Where would you draw the line on your current project?

What they are assessing

Diagnostic pattern matching.

Model answer

Feature files containing button and field names. Scenarios twenty steps long. A step definition count several times the scenario count. Nobody outside engineering opening a feature file in six months. Scenarios that must run in a given order. Heavy use of Background to carry setup. A growing set of disabled or wip tagged scenarios. And step definitions containing branching logic, which means the business rule has migrated into the glue where the business cannot see it.

What they are assessing

A precise design question.

Model answer

Generally no. Conditional logic in the glue means the same step behaves differently depending on state, which makes the scenario misleading: the feature file says one thing happens and the code decides. It also hides business rules from the business readable layer, defeating the point. The legitimate exceptions are technical concerns such as handling an optional cookie banner or retrying a flaky element. Business branching should be expressed as separate scenarios instead.

What they are assessing

The most common newcomer problem.

Model answer

The glue path first, since pointing it at the wrong package is the usual cause. Then whether the definition class is in the compiled test output, because a source folder not configured as a test root produces exactly this. Then the pattern itself: a trailing space, differing punctuation or a mismatch between a Cucumber Expression and the step wording. Running with dryRun shows all the mismatches at once rather than stopping at the first, which is the fastest way to see the pattern.

What they are assessing

Isolation reasoning.

Model answer

Shared state almost always: a static field or a context that is not per scenario, a browser session carrying cookies from the previous scenario, or data created by an earlier scenario that the later one now conflicts with. Then ordering assumptions, where a scenario relied on something an earlier one happened to create. I would confirm the context is injected per scenario, ensure hooks reset state, and make each scenario create its own preconditions rather than adding ordering to work around it.

What they are assessing

Reporting detail.

Model answer

Cucumber names generated scenarios after the outline, so with a plain report several failures look identical. The fixes are including a distinguishing column value in the scenario name using a placeholder, which modern Gherkin supports, so the name renders per example; using a reporter that shows the example row; and putting the identifying data into assertion messages. Without one of those, triage on a data driven feature means rerunning locally to find the row, which is exactly what CI was meant to avoid.

What they are assessing

Performance thinking.

Model answer

Move the setup out of the UI and into an API or database call inside the step definition, which usually turns a thirty second Given into a one second one without changing the feature file at all, because the Gherkin describes intent rather than mechanics. That is one of the concrete benefits of declarative steps. Beyond that, consider whether the setup belongs in a tagged hook so only scenarios needing it pay the cost, and whether a shared fixture created once per run can be sliced per scenario.

What they are assessing

Awareness of the modern synonym.

Model answer

They are synonyms in Gherkin 6 and later; Example was introduced as the preferred word because it reflects the specification by example idea more accurately than Scenario does. Both parse identically. The only complication is that Example is also the block name under a Scenario Outline in some tooling, and older reporting plugins sometimes render the newer keyword awkwardly, which is why many projects have stayed with Scenario.

What they are assessing

Expression syntax detail.

Model answer

Cucumber Expressions support optional text in parentheses, so I have {int} item(s) matches both singular and plural without a second definition. Alternation with a slash handles variants, such as I click/press the button. These small affordances matter more than they sound, because the alternative is either awkward English in the feature file or two nearly identical definitions, and the latter is how step explosion starts.

What they are assessing

Practical hook usage.

Model answer

It gives access to information about the running scenario: its name, its tags, its status once finished, and the attach method for adding evidence. It is what lets an @After hook decide whether to take a screenshot based on failure, name the file after the scenario, or branch on a tag. Reading the tags from it is also how a hook applies different teardown for different scenario types without needing several conditional hooks.

What they are assessing

Understanding of the mechanism rather than the recipe.

Model answer

With PicoContainer, Cucumber scans step definition constructors and instantiates the required types automatically, resolving a shared instance per scenario so two classes asking for the same type receive the same object. There is no configuration; the container works from the constructor signatures. With Spring you annotate a configuration class and the beans are managed by Spring instead, which is preferable when the application already uses Spring and you want to reuse its context.

What they are assessing

Layering.

Model answer

Step definitions call page objects rather than touching the driver directly, and the driver lives in the injected context so it is per scenario and thread safe. The layering is feature file describes intent, step definition translates intent into a sequence of page object calls, page object encapsulates locators and interactions. Keeping the driver out of step definitions is what allows the same steps to be reused and makes the glue readable.

What they are assessing

Scenario scoping.

Model answer

A scenario should verify one behaviour, which may legitimately require several Then steps asserting different aspects of the same outcome. What it should not do is exercise several behaviours in sequence, which is what produces twenty step scenarios that fail at step fifteen with no clear meaning. The test is whether the scenario name can describe what it checks in one clause: if the name needs an and, the scenario probably should be two.

What they are assessing

Traceability.

Model answer

By tagging scenarios with the story or requirement identifier, so a report can be grouped by it and gaps become visible. Some teams integrate with Jira or Xray so the link is bidirectional. The honest caveat is that the link decays: scenarios get copied with the tag, requirements get closed, and nobody reconciles. It works when tagging is part of the definition of done and someone reviews it, and becomes decorative otherwise.

What they are assessing

Whether the two are one artefact or two.

Model answer

Ideally they are the same thing: the acceptance criteria on the story are written as scenarios during refinement, and those scenarios become the automated tests. That is the arrangement that avoids drift. What commonly happens instead is criteria written in prose on the ticket and scenarios written separately afterwards, which produces two descriptions that diverge and a permanent question about which one is authoritative. Merging them is usually the single highest value change a team can make to its BDD practice.

What they are assessing

Practical waiting.

Model answer

By waiting for the expected condition inside the step definition rather than adding a wait step to the feature file, since waiting is mechanics and not business behaviour. That means explicit waits on the condition, polling with a timeout for an eventually consistent backend, or subscribing to a completion signal where one exists. A Gherkin step saying and I wait five seconds is both a design smell and a reliability problem, and it is one of the clearest signs of an imperative feature file.

Trap to avoid

Adding a wait step to Gherkin. It puts timing into the business readable layer and hard codes a duration that will be wrong on a slower machine.

What they are assessing

Assertion mechanics for tabular results.

Model answer

Cucumber-JVM has DataTable diff, which compares an expected table with actual data and reports the differences in a readable table form rather than as a failed equality check. That produces far better failure output for something like verifying the contents of a results grid. The alternatives are converting both to lists of maps and asserting, which works but produces poor messages, or asserting row by row, which loses the overall picture when several rows differ.

What they are assessing

Practical pipeline hygiene.

Model answer

Tag them and exclude with a tag expression such as not @wip in the CI run, while still allowing them locally. The important accompanying discipline is a limit and a review, because wip tags are permanent in most projects: scenarios get tagged during a rush and never untagged, so the suite silently loses coverage while appearing healthy. Reporting the count of excluded scenarios alongside the pass rate keeps it visible.

What they are assessing

The prerequisite for parallelism to help.

Model answer

Each scenario creates the data it needs at the start, usually through an API for speed, with unique values generated per scenario so there is no collision on unique constraints. Where data must come from a pool, reserve and release it rather than sharing, using a claim mechanism so two threads cannot take the same record. What does not work is a shared seed data set that scenarios modify, because the failures it produces look like application defects and take days to attribute.

What they are assessing

Practical tooling.

Model answer

Run the scenario from the IDE with a breakpoint in the definition, which most Cucumber plugins support directly from the feature file gutter. For matching problems rather than logic problems, dryRun shows what matched. Logging the resolved parameter values at the start of a definition quickly reveals when a Cucumber Expression captured something unexpected, such as a string including trailing punctuation from the step. The Cucumber console output in pretty mode also shows exactly which definition matched each step.

What they are assessing

Whether you would push back.

Model answer

I would ask why first, because the usual answer is that management wants readable reports, and that is not a reason to adopt BDD. Converting existing imperative tests produces imperative feature files, which is the worst outcome: all the cost of the Gherkin layer and none of the collaboration benefit. If the goal is readable reports, a better reporter is far cheaper. If the goal is genuine collaboration, start with new work and a three amigos practice rather than converting, and let the existing suite stay as it is.

What they are assessing

Project structure.

Model answer

Conventionally under src/test/resources in a Maven project, in a features directory organised into subfolders by business area, with step definitions under src/test/java in a glue package. Keeping features in resources rather than alongside code matters because they are resources loaded at runtime rather than compiled. Mirroring the folder structure between features and step definitions helps people find the glue for a given step, though the glue path is flat so it is a convention rather than a requirement.

What they are assessing

Balancing coverage and readability.

Model answer

Use a Scenario Outline with an Examples table for the variations of one rule, which keeps the behaviour stated once and the cases visible as data. Cover the interesting boundaries rather than every combination: the values either side of each threshold, plus a representative middle case. Exhaustive combinations belong in unit tests where they are cheap, not in a business readable specification. The feature file should show the reader what the rule is, not prove it exhaustively.

What they are assessing

Breadth across implementations.

Model answer

The Gherkin is identical, which is the point of the specification. The differences are in the glue: JavaScript step definitions, the World object instead of dependency injection for shared state, hooks defined as functions rather than annotations, and configuration in a cucumber.js or cucumber.json file rather than a runner class. Parallelism is process based rather than thread based. Conceptually everything transfers, so experience with one is genuinely applicable to the other.

What they are assessing

Scope precision.

Model answer

@Before runs before every scenario, so it executes once per scenario. @BeforeAll runs once for the entire run, before any scenario, and its counterpart @AfterAll runs once at the end. The distinction matters for expensive setup: starting a shared service or a container belongs in @BeforeAll, while browser lifecycle belongs in @Before so each scenario is isolated. Note that @BeforeAll behaviour under parallel execution depends on the runner, which is worth checking rather than assuming.

What they are assessing

Practical remediation.

Model answer

Measure per scenario first, because the distribution is usually skewed. Then reduce in order: move setup from UI to API inside step definitions, which is often the largest single win and requires no feature file change; remove scenarios duplicating coverage, which accumulate when people copy rather than parameterise; push checks that do not need a browser down to unit or integration level; then parallelise once isolation allows it. Splitting into a fast gating subset and a fuller nightly run restores usefulness immediately while the rest is fixed.

What they are assessing

Step role discipline.

Model answer

No. Then should assert on the outcome only. A Then that clicks something or navigates is doing the work of a When, which makes the scenario misleading and the step unusable elsewhere. It usually happens when a scenario has grown to cover several behaviours and the author kept appending. The fix is either splitting the scenario or moving the action into a When. The keyword is not enforced by Cucumber, which is exactly why the discipline has to come from review.

What they are assessing

Refactoring practice.

Model answer

Change both together, using the IDE plugin which can rename a step and update its usages, and run dryRun immediately afterwards to catch any feature file that still uses the old wording. The risk is that a missed occurrence becomes an undefined step, which fails loudly, or worse matches a different definition, which fails subtly. For a widely used step I would prefer adding the new phrasing as an alternation first, migrating the feature files, then removing the old form.

What they are assessing

Adoption strategy.

Model answer

Start with the conversation, not the tool. Run three amigos sessions on a few upcoming stories and write the examples together, even on a whiteboard, and let the team see that it surfaces disagreements early. Only once that habit exists does automating the examples make sense. Introducing Cucumber first produces the common failure: testers writing Gherkin after the fact, nobody in the business reading it, and the team concluding BDD does not work when what they tried was not BDD.

Likely follow-up

What would you do if the product owner will not attend the sessions?

What they are assessing

Willingness to reach an unpopular conclusion either way.

Model answer

Ask what the Gherkin layer is currently buying. If no business reader has opened a feature file in six months and the scenarios are imperative, it is buying nothing and the cost is real, so removing it and keeping the underlying tests is a legitimate decision that should be made openly rather than by neglect. If the collaboration is genuinely happening, the complaint is usually about suite speed or flakiness, and removing Cucumber will not fix either. The diagnosis determines the answer; the tool is rarely the actual problem.

What they are assessing

Communication judgement.

Model answer

Scenarios passing against total, grouped by business area rather than by file, which is the one thing the Gherkin layer makes genuinely easy and valuable. Alongside that, which scenarios are excluded or quarantined, because a pass rate that ignores forty disabled scenarios is misleading. And the trend across runs rather than a single snapshot. What I would avoid presenting is a raw scenario count as a coverage measure, since it measures how many examples were written rather than how much risk is addressed.