Question 1

What do you think about BDD? Have you used Cucumber?

Accepted Answer

I open with a distinction, because the question conflates two things: BDD is a collaboration practice, Cucumber is a tool. They're independent — you can do BDD without Cucumber, and you can use Cucumber without doing BDD (which is, unfortunately, the most common case). BDD's real value is the three amigos conversation: business, developer and QA discussing the requirement through examples. I practise this without Cucumber too — talking through concrete examples in refinement ("what happens if the coupon is applied twice?") resolves at the start the misunderstandings you'd otherwise find at the end of the sprint. That's the most useful part of BDD for me. On Cucumber my position is conditional: it pays off only if non-technical people genuinely read the Gherkin. Otherwise you get double maintenance, an unmanageable step-definition collection and harder debugging — with nothing in return. In Playwright, describe + a clear test name + test.step() gives nearly the same readability with one layer less abstraction. [If you lack the experience, be honest:] "I haven't worked with Cucumber on a project, but I know the syntax and I'm familiar with playwright-bdd. I do apply the principles — example-based discussion is part of how I work." That is far stronger than invented experience, because one follow-up question doesn't unravel it.

Question 2

The project uses Cucumber and the team complains about it. What would you do?

Accepted Answer

I wouldn't jump to "let's remove it" — changing a working system has its own cost, and the problem behind the complaint isn't always obvious. First, the diagnosis: (1) who besides QA actually opens the .feature files? Git history answers this objectively — who edited the scenarios in the last six months? If there's no trace of the business side, the Gherkin layer no longer serves its purpose. (2) What is the complaint about — Gherkin itself, or badly written step definitions? Those are entirely different problems. If the Gherkin layer itself is the problem (nobody reads it): I'd propose a gradual exit — new tests written in plain Playwright, old ones migrated as they're touched. A big "migrate everything at once" project usually stalls halfway and makes things worse: now you have two approaches. If the implementation is the problem (business does read the Gherkin, but the work is painful): I'd keep the layer and fix the quality — clean up and consolidate step definitions, lift technical steps ("I click the button with id...") into business language, and move from @cucumber/cucumber to playwright-bdd (parallelism, fixtures and traces come back — often the missing pieces behind the complaint). I wouldn't decide alone: I'd talk to the business side too — perhaps they do value the scenarios and simply never told QA. That step matters, because removing the layer is an expensive decision to reverse.

Question 3

The product owner says "write our tests in Gherkin so I can read them too". Your response?

Accepted Answer

That's good news — there's a real audience, which is Gherkin's most important precondition. But before agreeing outright I'd clarify a few things, because "I want to read them" and "I will read them regularly" are different. My questions: (1) Which tests do you want to read? The whole suite, or the critical business flows? Writing API contract tests in Gherkin helps nobody. (2) Why do you want to read them — what question are you trying to answer? Sometimes the real need is "which functionality is covered?", and that has a cheaper answer. (3) Will you write or review the scenarios yourself? This is the crucial one: it's where BDD's value actually comes from. Then I'd present alternatives, because Gherkin isn't the only option: (a) test names in the HTML/Allure report — if written clearly ("a valid coupon reduces the total") they already form a readable list at zero extra cost; (b) test.step() making the stages visible in the report; (c) full Gherkin — if the PO will genuinely participate in writing/reviewing scenarios. More often than not the conversation lands on (a) and both sides are satisfied. If the PO really does want into the authoring process, I'd pilot Gherkin on one feature rather than converting the whole suite at once. This answer works because it doesn't reject the request — it finds the need behind it and proposes a measured step.

Question 4

What separates a good Gherkin scenario from a bad one?

Accepted Answer

A one-sentence criterion: a good scenario states WHAT the user achieves, not HOW the UI does it. A bad scenario is an imperative UI script: "When I click the button with id 'apply-btn' / And I wait 3 seconds / Then the element '.total' should contain '90'". Its problems: business won't read it (so the Gherkin layer has no reason to exist), it breaks when the UI changes even though the behaviour didn't, and the .feature file becomes code rather than documentation. A good scenario is declarative, in business language: "When I apply the coupon 'QA10' / Then the cart total should be '90.00 AZN'". How the UI is built is the step definition's internal business. My other criteria: (1) one scenario — one behaviour; a 15-step scenario is usually several tests glued together; (2) Background only for shared context — dumping all setup there makes scenarios unreadable; (3) Scenario Outline for similar variations — a table beats three copy-pasted scenarios; (4) technical detail (IDs, selectors, timeouts) never appears in a scenario; (5) the scenario name states the outcome — not "Coupon test 1". I'd close with an observation worth making: most of these criteria aren't Gherkin-specific — they apply identically to ordinary test names and test.step(). "Speak at the level of user intent and hide the technical detail" is good test design regardless of tooling.

Situation	Does Cucumber pay off?	Why
A business analyst writes and reviews the scenarios	Yes	The communication gain covers the extra layer's cost
A regulated domain: requirement ↔ test traceability is required	Yes	Scenarios double as audit-suitable documentation
Only the QA team ever opens the .feature files	No	All of the cost, none of the communication gain
Technical tests: API contracts, error codes	No	Gherkin is a clumsy way to express technical detail
A small team iterating fast	Usually no	The extra layer slows you down and there's no audience
Complex business rules with many variations	Maybe	Scenario Outline tables make the rules legible

BDD/Cucumber: when it pays off and when it doesn't

📚 Sources and documentation