82 BDD interview questions with answers

What they are assessing

Whether the candidate defines it as a practice or as a tool.

Model answer

Behaviour driven development is a collaborative practice where business people, developers and testers explore and agree the behaviour of a feature through concrete examples before it is built, express those examples in a language everyone understands, and then automate them so they stay true. It originated with Dan North as an evolution of test driven development, specifically to address the fact that teams struggled with what to test and with the word test getting in the way of the conversation.

Likely follow-up

If BDD is a collaboration practice, where does the testing come in?

What they are assessing

The single most important distinction in this bank.

Model answer

Not primarily. It produces tests as a by-product, but its purpose is to prevent misunderstanding between the people who want the software and the people who build it. The tests are the mechanism that keeps the agreement honest over time rather than the point of the exercise. Teams that adopt it as a testing technique get the automation cost without the benefit, because the value sits in the conversation that happens before any code exists.

Trap to avoid

Describing BDD as a way of writing tests in plain English. That is the output, not the practice, and it is the answer that signals the candidate has only used the tooling.

What they are assessing

The standard framing, which structures everything else.

Model answer

Discovery, formulation and automation. Discovery is the structured conversation exploring the feature through concrete examples and surfacing what nobody had considered. Formulation is capturing those examples in a shared, readable form that both business and engineering agree describes the behaviour. Automation is making those formulated examples executable so they continue to verify the system. The order matters, and the common failure is starting at automation, which produces the artefacts without the understanding.

What they are assessing

A distinction candidates frequently blur.

Model answer

TDD is a developer practice at the code level: write a failing unit test, make it pass, refactor, driving design. ATDD is acceptance test driven development, agreeing acceptance tests before implementation so the criteria are concrete. BDD overlaps heavily with ATDD and is broader in emphasis, focusing on the conversation and the shared language rather than on the test artefact. In practice BDD and ATDD describe much the same thing from different angles, and both sit outside the TDD loop, which continues at the unit level underneath.

Likely follow-up

Can a team do BDD and TDD at the same time?

What they are assessing

Motivation, which explains the design of the practice.

Model answer

Two related ones. Dan North observed that developers learning TDD struggled with what to test and how to name tests, and found that framing tests as behaviour descriptions resolved that. The larger problem was the gap between what the business meant and what got built, which no amount of documentation closed because requirements written in prose are ambiguous in ways nobody notices until the wrong thing is delivered. Concrete examples remove that ambiguity, because it is very hard to disagree about a specific case while appearing to agree about a general statement.

What they are assessing

A related body of practice.

Model answer

Gojko Adzic’s formulation of essentially the same ideas: deriving the specification from concrete examples agreed collaboratively, refining them into a precise form, automating them, and treating the result as living documentation. The terminology differs from BDD but the practices largely coincide, and his framing of the documentation value is clearer than most. It is worth knowing because interviewers sometimes use the terms interchangeably, and because the book is the usual reference for the argument that the examples are the specification rather than an illustration of one.

What they are assessing

The practice that carries most of the value.

Model answer

A structured conversation, usually short and time boxed, where the team explores a story through concrete examples rather than abstract description. The output is a shared understanding, a set of examples covering the rules, and an explicit list of questions nobody can answer yet. The last of those is often the most valuable, because an unanswered question discovered in a fifteen minute conversation is cheap, and the same question discovered during development costs a rebuild or a wrong decision made silently.

Likely follow-up

What do you do with the questions nobody in the room can answer?

What they are assessing

The three amigos principle.

Model answer

At minimum a business representative, a developer and a tester, which is the three amigos pattern. Each brings a different question: the business asks what the user needs, the developer asks how it would be built and what is feasible, and the tester asks how it could fail and how we would know it works. The tester perspective is the one most often absent and usually the one that changes the story, because the error cases and edge conditions are rarely in the original description. Larger groups slow it down without adding much.

What they are assessing

Facilitation, which is where these sessions succeed or fail.

Model answer

Time box it, typically twenty to thirty minutes per story, because an open ended session drifts into design discussion. Keep it on concrete examples rather than general statements, and redirect when people start describing implementation. Capture rules, examples and questions visibly as you go, which is what example mapping formalises. End with a decision about whether the story is ready, needs more information, or should be split, because a session that ends without that conclusion has not done its job.

What they are assessing

A very common practical obstacle.

Model answer

Recognise that it undermines the practice rather than pretending otherwise, because the whole point is the conversation with the person who knows what is wanted. Practically, I would try shorter and more frequent sessions, since availability is usually about meeting length. I would use a proxy who genuinely has authority rather than someone relaying. And I would write down the assumptions made in their absence and circulate them for explicit confirmation, which converts a silent assumption into a reviewable one. What I would avoid is a team writing scenarios alone and calling it BDD.

Trap to avoid

Proceeding without the business and treating the scenarios as agreed. They document what the team assumed, which is exactly the gap BDD exists to close.

What they are assessing

Whether the candidate ties the practice to a syntax.

Model answer

Formulation is capturing the agreed examples in a precise, shared form that both business and engineering accept as describing the behaviour. Gherkin is one way and the most common, but not a requirement: a table of examples, a well structured acceptance criteria list, or a domain specific format can all serve. The test is whether a business person would recognise it as describing their intent and whether it is precise enough to automate. Teams sometimes reach for Gherkin reflexively when a table of inputs and expected outputs would communicate better.

Likely follow-up

When would a table of examples be better than Gherkin scenarios?

What they are assessing

A concept borrowed from domain driven design.

Model answer

A shared vocabulary used consistently by everyone, in conversation, in the scenarios and in the code, so there is no translation layer between how the business describes something and how the system models it. It matters because translation is where meaning is lost: if the business says policy holder and the code says customer and the scenarios say user, three slightly different concepts quietly diverge. BDD scenarios are a strong forcing function for this, because inconsistent terms become obvious when you try to write them down for everyone to read.

What they are assessing

A question with a widely believed wrong answer.

Model answer

They should be written collaboratively and derived from the discovery conversation, rather than authored by one role. The common misconception is that the business writes them, which almost never works in practice because scenario writing is a precision skill. The realistic pattern is that a tester or developer drafts them from the conversation and the business reviews and corrects. The distinction worth stating is business readable rather than business written: the requirement is that the business can read and validate them, not that they typed them.

Trap to avoid

Saying the product owner should write the feature files. It sounds right, is rarely true, and teams that insist on it usually abandon BDD within a few months.

What they are assessing

Scoping judgement.

Model answer

No, and this is one of the main sources of bloat. Scenarios should cover the behaviour that matters to the business and the rules people would disagree about. Exhaustive validation of every field, every boundary and every error message belongs in unit or API level tests, where it is cheaper to write, faster to run and easier to maintain. A feature file containing forty scenarios for one story is almost always a sign that technical detail has leaked into a layer meant for business communication.

What they are assessing

Basic syntax awareness.

Model answer

A structured plain text format for writing scenarios, using keywords: Feature, Scenario, and the steps Given, When, Then, And and But, with Background for shared setup, Scenario Outline with Examples for parameterised cases, and Rule for grouping scenarios under a business rule. It is deliberately minimal so the content carries the meaning rather than the syntax, and it supports many spoken languages, which matters for teams whose business stakeholders do not work in English.

What they are assessing

Core structure.

Model answer

Given establishes the context or precondition, the state the world is in before the behaviour occurs. When is the action or event being described, the thing that triggers the behaviour. Then is the expected outcome, what should be observably true afterwards. And and But continue the previous keyword for readability. The structure maps onto arrange, act and assert, and the discipline it imposes is that a scenario has one clear trigger.

What they are assessing

A design rule with a clear rationale.

Model answer

Generally not. One When means one behaviour under examination, so a failure identifies what broke. Several Whens usually means the scenario is describing a workflow rather than a behaviour, and when it fails you have to read the whole thing to find out where. The exception people raise is a genuine sequence where the second action only makes sense after the first, and even then it is usually clearer to fold the first into a Given, since the context it establishes is a precondition rather than the subject of the test.

Likely follow-up

How would you rewrite a scenario with three Whens?

What they are assessing

A feature that is routinely overused.

Model answer

Steps that run before every scenario in a feature file, used for shared context. It is appropriate for a small amount of genuinely common setup, such as establishing which user is logged in when every scenario in the file assumes the same one. It becomes a problem when it grows, because a reader then has to hold five Background steps in mind while reading every scenario, and because scenarios start depending on setup that is not visible where they are. A long Background usually means the feature file covers too much.

What they are assessing

Parameterisation, which is frequently misused.

Model answer

A scenario template with placeholders, run once per row of an Examples table. It is right when the same behaviour is being illustrated across a few meaningfully different cases, such as three customer types that are treated differently. It is wrong when it becomes a data driven test harness: twenty rows of input validation in a feature file is a unit test wearing Gherkin, and nobody from the business will ever read it. The rule of thumb is that each row should be a case someone would mention in a conversation about the feature.

Trap to avoid

Using Scenario Outline for exhaustive data coverage. It bloats the feature file, slows the suite, and buries the handful of rows that actually communicate something.

What they are assessing

Awareness of a more recent addition.

Model answer

Introduced in Gherkin 6, it groups scenarios under a business rule, giving a level between Feature and Scenario. It is useful because it makes the relationship between rules and examples explicit in the file, mirroring the structure that example mapping produces: a story contains rules, and each rule is illustrated by examples. Before it existed teams approximated this with comments or file organisation, so it is a formalisation of something good teams were already doing.

What they are assessing

Execution control.

Model answer

Labelling features or scenarios so they can be selected at run time, with expressions combining them. Typical uses are marking a smoke subset, separating slow scenarios, grouping by feature area, and marking work in progress so unfinished scenarios do not fail the build. Tags are also used by hooks to apply setup selectively. The caution is that a work in progress tag applied during a rush and never removed is one of the most common ways scenarios quietly stop running for years.

What they are assessing

The single most important scenario writing concept.

Model answer

An imperative scenario describes the mechanics: enter a value in a field, click a button, see a message. A declarative scenario describes the intent: a customer with an expired card attempts a payment and is told to update their details. Declarative is almost always right, because it survives interface changes, reads as business behaviour, and keeps the implementation detail in the step definitions where it belongs. Imperative scenarios are the most common BDD failure, and they produce feature files nobody outside the team can read.

Likely follow-up

Rewrite a scenario that says click the Submit button declaratively.

What they are assessing

Quality criteria.

Model answer

It describes one behaviour with a single trigger. It is written in domain language with no interface mechanics. It is independent, so it can run alone and in any order. It uses only the data relevant to the point being made, since extra detail distracts from what matters. Its title states the behaviour rather than restating the steps. And it would be recognisable to a business stakeholder as something they care about, which is the test that catches scenarios that are really technical checks in disguise.

What they are assessing

A subtle point about readability.

Model answer

Only what is relevant to the behaviour. If the rule is about an order over a threshold, the scenario should say an order worth more than the free delivery threshold rather than listing a customer name, address, five line items and payment details. Irrelevant data obscures the point and couples the scenario to setup that will change. The pattern that supports this is a default fixture established in the step definitions, with the scenario overriding only the attribute that matters, which is where the Cucumber bank covers the mechanics.

What they are assessing

A principle with practical consequences.

Model answer

Yes. A scenario that depends on a previous one having run cannot be executed alone, cannot be parallelised, and produces a failure that points at the wrong place. The temptation arises with long journeys, where splitting across dependent scenarios feels natural. The right answer is for each scenario to establish its own preconditions programmatically, so the sequence reads as a narrative while each remains independently runnable. Shared state between scenarios is one of the hardest problems to unpick later.

What they are assessing

Keeping the readable layer readable.

Model answer

By pushing the complexity into the step definition and expressing the setup as a single meaningful Given. A step saying a customer has an active subscription with two months remaining can perform twenty API calls behind it, and the scenario stays readable. The alternative, spelling out the setup as fifteen Given steps, destroys the purpose of the layer. The general principle is that the feature file states what is true, and the step definitions are responsible for making it true as efficiently as possible.

What they are assessing

A specific and widely used discovery technique.

Model answer

A structured conversation technique from Matt Wynne using four colours of card. Yellow holds the story. Blue cards are the rules or acceptance criteria. Green cards are concrete examples illustrating each rule. Red cards are questions nobody in the room can answer. It is time boxed, typically twenty five minutes, and the output is a visible map of the story. Its great virtue is that it makes readiness obvious: a story with many red cards is not ready, and a story with many blue cards is too big.

Likely follow-up

What does a map with eight blue cards tell you?

What they are assessing

Follow-through, which determines whether the technique helps.

Model answer

They become explicit actions with an owner and a deadline, because an unanswered question that is merely noted gets answered implicitly by whoever writes the code. If the questions are material, the story is not ready and should not enter the sprint, which is the uncomfortable but correct outcome. If they are minor, the story can proceed with the assumption recorded. The value of the red cards is that they convert unknown unknowns into tracked items, and skipping that step wastes most of the session.

What they are assessing

The connection between discovery and formulation.

Model answer

The map is the input to formulation, not the output. Blue cards become rules, which in Gherkin 6 map onto the Rule keyword. Green cards become scenarios, often directly. But not every example needs to become an automated scenario: some are better covered at unit level, and the decision about which to automate is separate from the decision about which to discuss. Treating every green card as a scenario is how feature files become bloated, so the filter is whether automating it at this level adds value.

What they are assessing

A question that determines whether the suite is sustainable.

Model answer

At the lowest level that still exercises the behaviour meaningfully, which is frequently the service or API layer rather than the user interface. Scenarios describe business behaviour, and most business behaviour lives below the interface, so driving them through the UI adds fragility and runtime for no additional verification of the rule. A small number genuinely need the interface, where the behaviour is about the interface. Teams that automate every scenario through the browser produce suites too slow to run and too brittle to trust.

Trap to avoid

Assuming BDD means UI automation. It is the most common and most expensive misconception, and it is the main reason BDD suites get abandoned.

What they are assessing

Honest assessment of the trade-off.

Model answer

A translation layer between the readable scenarios and the code, which has to be written and maintained and which adds indirection when debugging. A failure in a Gherkin suite requires going from the scenario to the step definition to the helper to the actual code, which is slower than a direct test. The layer earns that cost only when someone outside engineering actually reads the scenarios. If nobody does, the team is paying for readability that nobody consumes, and a plain test would be better.

Likely follow-up

How would you find out whether anyone outside the team reads them?

What they are assessing

Whether the candidate understands where the value sits.

Model answer

Yes, and teams that do get most of the benefit. Discovery and formulation prevent the misunderstandings, and that happens before any automation exists. Automation adds regression protection and keeps the documentation honest, which is genuinely valuable but is the smaller part. The reverse is not true: automation without discovery produces executable specifications of what the team assumed, which is automation with extra ceremony. If a team had to choose one, the conversations are worth more.

What they are assessing

The mechanism, at a conceptual level.

Model answer

Through step definitions, which match step text by pattern and execute code. The framework parses the feature file, matches each step to a definition, and runs them in order, failing the scenario on the first failure. Parameters are extracted from the step text and passed in. The mechanics differ by tool and are covered in the Cucumber bank, but the model is the same across Cucumber, SpecFlow and Behave: text is matched to code, and the matching layer is what makes the scenario executable.

What they are assessing

A practice frequently named and rarely explained.

Model answer

A conversation between a business representative, a developer and a tester before a story is built. Three because those are the distinct perspectives needed: what is wanted, how it would be built, and how it could fail. Fewer and a perspective is missing, more and the conversation slows without adding much. The name is a convention rather than a limit, and adding a designer or an operations engineer is sensible where the story warrants it. The important part is that all three perspectives are genuinely present rather than represented by proxy.

What they are assessing

A real adoption obstacle.

Model answer

By making the benefit land on them, which it genuinely does. The argument that works is that the discovery conversation eliminates the rework caused by building the wrong thing, which is time they lose personally. It also helps to involve them in writing step definitions and treating that as production code rather than test scaffolding handed to the testers. Where it fails is when BDD is introduced as a QA initiative with developers asked to support it, because then it is correctly perceived as overhead imposed from outside.

What they are assessing

Recognition of the defining anti-pattern.

Model answer

Name it, because it means they are not doing BDD. Scenarios written afterwards document what was built rather than what was agreed, so they cannot prevent a misunderstanding and they will pass by construction. The practice has become automation with an unusual syntax, and the honest options are to fix it by moving the conversation earlier, or to stop paying the Gherkin cost and write ordinary tests. I would investigate why it happens first, since the usual cause is stories arriving in the sprint without refinement, which is a flow problem rather than a BDD problem.

Trap to avoid

Defending after-the-fact scenarios as still useful documentation. They document the implementation, including its defects, which is not the same thing.

What they are assessing

A claimed benefit that needs qualification.

Model answer

Documentation that cannot go stale because it is executed against the system, so if the behaviour changes and the documentation does not, the build fails. That is the genuine advantage over written specifications, which drift immediately and silently. The qualification is that it is only documentation if someone reads it, and only living if the suite actually runs. A feature file suite that is always partially disabled is neither.

Likely follow-up

What makes living documentation stop being living?

What they are assessing

Practical application of the claim.

Model answer

Organise feature files by business capability rather than by application screen or technical component, so a reader can find the rules for a domain area. Write declaratively so the content is behaviour rather than mechanics. Keep each file small enough to read. Use Rule to show which examples illustrate which rule. And publish the output somewhere accessible, since a reader outside engineering will not browse a repository. Tools such as Serenity and the Cucumber reports generate readable output, which is what makes the documentation claim real rather than theoretical.

What they are assessing

Honesty about the central claim.

Model answer

Rarely in raw form, and that is worth being candid about. What does happen in teams where it works is that stakeholders engage with the examples during discovery, review the scenarios when they are written, and consult the published report when a question arises about how something behaves. That is still consumption, and it still justifies the readable layer. What does not happen is stakeholders browsing feature files regularly, and a team that justifies the cost on that basis will not see the return.

What they are assessing

A specific scenario smell.

Model answer

A step containing more than one action or condition joined by and, such as a Given that both creates a customer and places an order. It is a problem because the step is less reusable, the failure message is ambiguous about which half failed, and it usually indicates the scenario is doing too much. The fix is to split into separate steps, or, where the combination is genuinely a single meaningful precondition, to name it as one concept rather than listing its parts.

What they are assessing

Breadth of recognition.

Model answer

Writing scenarios after the code. Imperative scenarios full of interface mechanics. Testers writing scenarios alone with no business involvement. Using Gherkin for exhaustive edge case coverage that belongs in unit tests. Scenario Outlines used as data driven test harnesses. Conjunction steps. Over-reuse of step definitions until steps mean different things in different contexts. Shared state between scenarios. Long Backgrounds. And treating BDD as synonymous with a tool, which underlies most of the others.

Likely follow-up

Which of those do you see most often?

What they are assessing

A subtle problem that appears as a suite matures.

Model answer

A step written generically enough to match many contexts stops expressing a specific meaning, so the same sentence does different things depending on where it appears, usually through hidden state. That makes scenarios hard to read and step definitions hard to change, since altering one breaks scenarios the author never saw. The balance is that reuse is good at the level of genuine domain concepts and bad when it is driven by wanting fewer definitions. A slightly duplicated step with a clear meaning is better than a shared one with none.

What they are assessing

Diagnosis and remediation of the standard failure state.

Model answer

Establish what the scenarios are actually verifying, because most of them will be covering business rules that do not need the interface. Those move down to the API or service layer, which is the single largest win in both runtime and stability. Identify duplicates, which accumulate when scenarios are written per story without reference to what exists. Cut scenario outlines being used for data coverage and replace them with unit tests. What remains at the interface should be a small set of genuine journeys. I would also ask whether anyone reads them, because if not, the Gherkin layer is cost without benefit and that is a separate conversation.

What they are assessing

Market awareness.

Model answer

Cucumber is the most widely used, with implementations for Java, JavaScript, Ruby and others. SpecFlow was the .NET equivalent and its open source successor is Reqnroll. Behave is the common Python choice, and pytest-bdd is an alternative that integrates with pytest. JBehave predates Cucumber in Java and is still found in older projects. Serenity BDD sits on top of Cucumber or JUnit and adds reporting and a structured page object model, and its reports are a large part of why teams choose it.

What they are assessing

The distinction, asked directly.

Model answer

No, and the inverse is also true. A team using Cucumber to automate tests written by testers after development is doing automation with a readable syntax. A team holding discovery conversations and capturing examples in a shared document without Cucumber is doing BDD. The tool supports the practice and does not constitute it. This is probably the most commonly asked question in BDD interviews because the confusion is so widespread.

What they are assessing

Familiarity with a common addition to the stack.

Model answer

Primarily reporting: it produces detailed living documentation showing which requirements are covered, the steps executed with screenshots, and aggregated results, which is substantially better than the default Cucumber report and is often the reason it is adopted. It also provides a structured approach to page objects and a screenplay pattern implementation that models tests as actors performing tasks, which scales better than classic page objects on large suites. It works with Cucumber or with JUnit directly, so it is not tied to Gherkin.

What they are assessing

Change management rather than tooling.

Model answer

Start with the conversations, not the tooling, which is the opposite of what most teams do. Run example mapping on a few stories and let the team see questions surface that would otherwise have become defects, because that experience is more persuasive than any explanation. Only once the conversations are habitual would I introduce formulation, and only then automation on a small number of scenarios. Installing Cucumber first produces a team writing Gherkin for existing tests and concluding BDD is overhead, which is the usual failed adoption.

Likely follow-up

What would you expect to be the hardest part of that sequence?

What they are assessing

Willingness to argue against the practice.

Model answer

When there is no genuine business stakeholder to converse with, such as a purely technical component or an internal library, since the readable layer has no audience. When the team is small and co-located with shared understanding already, where the conversation happens naturally and the formalism adds ceremony. When the domain is simple enough that misunderstanding is not the problem. And when the organisation will not commit the business time, because BDD without business participation is cost without benefit. In those cases well written acceptance criteria and ordinary tests are better.

Trap to avoid

Recommending BDD universally. Interviewers at senior level are often checking whether you can identify where it does not pay.

What they are assessing

Judgement about a common and usually wrong proposal.

Model answer

Against it, in most cases. Converting existing tests produces Gherkin that describes what the tests do rather than what the business wants, which is imperative by construction and serves nobody. It also adds a translation layer and maintenance cost to a suite that already works. If the motivation is readability for stakeholders, I would ask who specifically will read it and verify that is real. If the motivation is to adopt BDD, the right move is to start using it on new work, where the conversation can happen first, and leave the existing suite alone.

What they are assessing

Long term viability.

Model answer

By keeping the discovery conversations in the process rather than relying on individual discipline, which means they are part of refinement and part of the definition of ready. By keeping the suite fast and trusted, since a slow or flaky suite is abandoned regardless of how good the scenarios are. By pruning scenarios actively, because feature files only ever grow otherwise. And by periodically checking whether anyone reads the output, because the honest answer sometimes is that the readable layer has stopped earning its cost and the team should simplify.

What they are assessing

Outcome thinking about a practice that is hard to measure.

Model answer

By what happens upstream rather than by the suite. Fewer defects attributable to misunderstood requirements, which is the specific thing BDD targets. Fewer stories returned during acceptance because the behaviour was not what was wanted. Questions surfacing in refinement rather than mid-sprint. Business stakeholders engaging with examples. What does not indicate success is the number of scenarios, the pass rate, or coverage, all of which can rise while the practice delivers nothing.

Likely follow-up

How would you attribute a defect to a misunderstood requirement?

What they are assessing

Commercial framing.

Model answer

By separating the parts, because they have different returns. The conversations are cheap and have the highest return, since preventing one misbuilt story pays for months of sessions, and I would defend those unconditionally. The automation layer is a real cost and its return depends entirely on whether the readable form is consumed, so I would evidence that rather than assert it. If it is not being consumed, the honest recommendation is to keep the conversations and drop the Gherkin, which is a more credible position than defending the whole practice as a package.

What they are assessing

A distinction candidates often confuse.

Model answer

A data table attaches structured data to a single step, so one scenario receives a set of rows as input, such as a list of items in a basket. An Examples table belongs to a Scenario Outline and causes the whole scenario to run once per row. So a data table means one scenario with several pieces of data, and an Examples table means several scenarios differing by data. Using the wrong one produces either a scenario that runs once when it should run repeatedly, or a very slow suite running a full scenario per row.

What they are assessing

Where the boundary sits.

Model answer

By choosing error cases that matter to the business rather than every validation message. A scenario describing what happens when a customer tries to withdraw more than their balance is a business rule worth agreeing. A scenario for every field length validation is not, and belongs lower down. The test I apply is whether the business would have an opinion about the outcome: if they would say of course it should do that, it is probably not worth a scenario, and if they might say something unexpected, it is exactly what BDD is for.

What they are assessing

A related development approach.

Model answer

Starting from the externally visible behaviour and working inward: write the failing scenario describing what the user should experience, then drive down into the units needed to satisfy it, typically with TDD at each level. The point is that implementation is driven by a demonstrated need rather than by anticipated requirements, so you build what the behaviour requires and no more. It is the practice that connects BDD at the outer loop with TDD at the inner loop, and it is how the two coexist rather than competing.

What they are assessing

Facilitation under tension.

Model answer

Treat it as the most valuable outcome of the session rather than an obstacle, because a disagreement discovered in a conversation is a disagreement that would otherwise have been resolved silently by whoever wrote the code. Concrete examples help enormously here: two people can appear to agree on a general statement and immediately diverge on a specific case, which makes the difference visible and discussable. If it cannot be resolved in the room, it becomes a red card with an owner, and the story is not ready until it is settled.

What they are assessing

Basic mechanics.

Model answer

The scenario is reported as undefined rather than failed, and the tool typically prints a snippet suggesting the definition to write. The important consequence is that undefined steps do not necessarily fail the build unless configured to, so a suite can report success while a proportion of its scenarios never actually executed anything. Configuring strict mode so undefined and pending steps fail is one of the first things worth setting on a new project, and the Cucumber bank covers the specifics.

Trap to avoid

Leaving undefined steps non-failing. The suite stays green while scenarios silently do nothing, which is the worst possible state for a regression suite.

What they are assessing

Structure for readability.

Model answer

By business capability or domain area rather than by screen, technical component or test type, because the reader is looking for the rules governing a part of the business. One feature file per capability, small enough to read in one sitting, with Rule grouping the scenarios under the business rules they illustrate. Organising by screen produces files that fragment a single business rule across several places and that need restructuring whenever the interface changes, which defeats the documentation purpose.

What they are assessing

Recognising bloat and its cause.

Model answer

Because nobody reads it, which removes the entire justification for the format. It usually indicates one of two things: the feature covers too broad an area and should be split by capability, or technical detail has leaked in and cases belonging in unit tests have been written as scenarios. It also slows the suite and makes the Background, if there is one, apply to far more than it should. The remedy is to decide which scenarios genuinely communicate a business rule and push the rest down a level.

What they are assessing

Maintenance.

Model answer

By treating them as the specification rather than as a description of it, so changing the behaviour means changing the scenario first and then the code, in the same change. That is the discipline that keeps them honest. The mechanism that enforces it is the suite running in CI, since a scenario that no longer matches the system fails. Where it breaks down is scenarios that are disabled or tagged out, which drift silently, so keeping the disabled count at zero matters more than it appears.

What they are assessing

A distinction central to example mapping.

Model answer

A rule is a general statement of how the system should behave, such as orders over a threshold get free delivery. An example is a concrete instance illustrating it, such as an order of a specific amount receiving free delivery. Rules are what the business decides and examples are how we check we understood the rule the same way. The common problem is that teams state rules and stop, which feels like agreement and conceals divergent interpretations, and it is precisely the examples that expose the divergence.

What they are assessing

Applying the principle rather than stating it.

Model answer

By asking what the user is trying to achieve rather than what they are doing mechanically. A scenario that enters a username, enters a password, clicks login, then checks for a welcome message becomes a scenario where a registered customer signs in successfully. The mechanics do not disappear, they move into the step definition, so the behaviour is still exercised through whatever interface is appropriate. The test of success is that the scenario would survive a complete redesign of the login screen without editing.

What they are assessing

A practical concern that affects scenario readability.

Model answer

With defaults established in the step definitions and scenarios overriding only what matters to the behaviour, so a step saying a customer with an expired card builds a complete valid customer and alters one attribute. Data is created per scenario through an API rather than depending on shared fixtures, which keeps scenarios independent. The alternative, specifying full data in the feature file, both obscures the point of the scenario and couples it to a schema that will change.

What they are assessing

Conceptual understanding with a pointer to the detail.

Model answer

Code that runs before or after scenarios or steps, outside the feature file, used for setup and teardown such as establishing a session, resetting data or capturing a screenshot on failure. Hooks exist because that work does not belong in the scenario, where it would be noise to the business reader. They can usually be filtered by tag so they apply selectively. The specific mechanics differ by framework and are covered in the Cucumber bank.

What they are assessing

A specific and common misuse.

Model answer

A Given establishes context, so it should set up state as quickly and reliably as possible, which almost always means through an API or the database rather than by driving the interface. A Given that logs in through the form adds seconds to every scenario, introduces a failure point unrelated to the behaviour under test, and conflates setup with the subject of the test. If the login itself is what is being tested, that belongs in a When within a scenario about logging in.

What they are assessing

A precise and useful distinction.

Model answer

That the requirement is for business stakeholders to be able to read and validate the scenarios, not to author them. Writing good scenarios is a skill involving precision, consistency of language and awareness of the automation layer, which most business people have no reason to develop. Expecting them to write feature files is one of the most reliable ways to kill BDD adoption. Having them review scenarios drafted from a conversation they participated in achieves the same verification without the unrealistic expectation.

What they are assessing

Willingness to reverse a decision.

Model answer

By checking whether the three practices are actually happening. If discovery conversations are not occurring, the team is not getting the main benefit and the automation is a costly way to write tests. If nobody outside engineering reads the scenarios, the readable layer has no audience. If both are true, I would recommend keeping whatever conversation habits exist and converting the suite to ordinary tests, which removes the translation layer and makes debugging faster. That is a better outcome than maintaining the ceremony of a practice that has stopped functioning.

What they are assessing

Basic structure.

Model answer

A feature describes a capability of the system and is the unit of the file, carrying a title and a description that usually states who wants it and why. A scenario is a single concrete example of that feature behaving in a particular situation. One feature contains many scenarios. The feature description is frequently left empty, which is a missed opportunity, because a sentence on why the capability exists is often the most useful line in the file for a new reader.

What they are assessing

Influence.

Model answer

By quantifying what the alternative costs them, in their terms. The time requested is typically twenty five minutes per story; the cost of a misbuilt story is days of rework plus the delay. I would also make the sessions as cheap as possible to attend: short, well prepared, with the questions sent in advance so they are not spent on context. And I would start with one or two stories rather than asking for a blanket commitment, because a session where a real misunderstanding surfaces makes the argument far better than I can.

What they are assessing

A small practice with a large effect.

Model answer

The behaviour and its outcome, because the title is what appears in the report and what a reader scans. A title saying free delivery is applied to orders over the threshold communicates something; a title saying test delivery charge calculation does not. A good test is whether the list of scenario titles in a feature file reads as a summary of the rules, which is what makes the suite usable as documentation rather than only as a test run.

What they are assessing

Workflow mechanics.

Model answer

A step whose definition exists but is explicitly marked as not yet implemented, so the scenario is reported as pending rather than passing or failing. It is useful during development, where scenarios are written before the implementation exists and should visibly not be passing. The risk is the same as undefined steps: if pending does not fail the build, scenarios can sit pending indefinitely while the suite reports green, so strict mode in CI matters.

What they are assessing

Calibration.

Model answer

Usually a handful, in the range of three to eight, covering the main rules and the significant variations. Fewer than that often means the story is trivial or the rules have not been explored. Many more usually means either the story is too large and should be split, or that cases belonging at unit level have been written as scenarios. Example mapping gives a useful signal here, since a map with many blue cards indicates a story that should be split rather than a story needing many scenarios.

What they are assessing

Organisational application.

Model answer

By standardising the vocabulary rather than the tooling, since the ubiquitous language is the thing that must be consistent for scenarios across teams to be comprehensible together. Shared step definitions across teams are tempting and usually a mistake, because they couple teams and the steps become generic enough to lose meaning. What is worth sharing is the practice: facilitation skill, the definition of ready including discovery, and a community of practice where scenario quality is discussed. Reporting aggregated across teams is also valuable, since that is where the documentation claim becomes real.

What they are assessing

Understanding why the anti-pattern is so persistent.

Model answer

Because BDD is usually introduced by a QA function with existing browser automation, so Gherkin gets layered over what already exists, and because scenarios phrased as user behaviour feel like they should be driven through the user interface. The reasoning is mistaken: a scenario describes behaviour, and behaviour is verified at whatever layer implements it. Recognising this early is the difference between a suite that runs in four minutes and one that runs in four hours, and retrofitting the change later is expensive.

What they are assessing

A subtle quality issue.

Model answer

By deriving them from the examples discussed rather than from the criteria text, which is a different activity. Acceptance criteria are usually written as rules, and mechanically converting each into a scenario produces scenarios that restate the rule in Gherkin without adding the concreteness that makes examples valuable. A scenario should show a specific case with specific values, because that is what exposes differing interpretations. If a scenario reads as a rule rather than an instance, it has probably been translated rather than discovered.

What they are assessing

Role clarity.

Model answer

To bring the question of how it could fail into the conversation before the code exists, which is the perspective most often missing and the one that changes stories most. Beyond that, testers usually do a large share of the formulation, because precision in writing examples is a testing skill, and they often build the automation. What the role is not is owner of BDD as a QA initiative, since that framing is the most reliable predictor of a failed adoption.

What they are assessing

Metric judgement.

Model answer

No, and it is actively misleading, because a growing scenario count usually indicates bloat rather than coverage. Scenarios belong at the business rule level, and a healthy suite has relatively few, with detailed coverage below them. A team rewarded for scenario count will produce exhaustive outlines covering validation rules, which is precisely the anti-pattern. The useful signals are about the practice rather than the artefacts: are conversations happening, are questions surfacing early, are stories being returned less often.

What they are assessing

How the two artefacts coexist.

Model answer

Acceptance criteria state the rules a story must satisfy; BDD scenarios illustrate those rules with concrete examples. They are complementary rather than alternatives, and in example mapping terms the criteria are the blue cards and the scenarios are the green ones. Teams sometimes replace criteria with scenarios entirely, which works if the scenarios genuinely cover the rules, and sometimes duplicate them, which creates two sources of truth that drift. The cleaner arrangement is criteria as the rules and scenarios as the agreed examples of each.

What they are assessing

Acting on evidence that the practice is not delivering.

Model answer

I would separate what is working from what is not. If discovery conversations are happening and preventing misunderstandings, that is the main value and should continue regardless. The question is only whether the Gherkin layer is earning its cost, and on this evidence it is not serving its documentation purpose. The options are to make it accessible, by publishing readable reports somewhere the business actually goes and bringing scenarios into review, or to accept the finding and convert to ordinary tests. Either is defensible; continuing unchanged while claiming documentation value is not.

What they are assessing

A considered long term view.

Model answer

Discovery embedded in the process rather than dependent on individuals, so it survives people leaving. Scenarios automated below the interface, so the suite stays fast enough to run continuously and stable enough to trust. Active pruning, since feature files only grow otherwise. A ubiquitous language maintained as the domain evolves, because scenarios using outdated terms stop being readable. And honesty about the documentation claim, checked periodically rather than assumed, because the layer is only worth its cost while someone consumes it.

What they are assessing

Reflection, which reveals genuine experience.

Model answer

Separate the tooling decision from the practice decision by several months, because adopting Cucumber first frames BDD as a test framework and that framing is very hard to undo. Insist on the automation layer sitting below the interface from the first scenario, because retrofitting it after two hundred browser scenarios is a rewrite nobody will fund. And establish early who specifically will read the scenarios and how they will reach them, since the documentation benefit is the one most often assumed and least often delivered, and knowing the answer changes how much formalism is worth adopting.

What they are assessing

A closing question revealing depth of experience.

Model answer

Starting at automation. A team installs Cucumber, writes Gherkin over existing tests or writes scenarios after development, and concludes within a year that BDD is an expensive way to write tests. They are right about what they built: without the conversation beforehand the scenarios document assumptions rather than agreements, so they cannot prevent the misunderstanding that justified the practice, and the glue layer is pure cost. The whole value sits in a conversation that happens before any code exists, and it is the part teams consistently skip because it is the part that is hardest to schedule.