I am using the Cucumber BDD framework for test automation. I have read articles on keyword-driven which state that keywords such as sign_in are exposed to nonprogrammers and the implementation is mentioned in definition files. We use a similar technique in Cucumber which describes actions in simple English using Gherkin language.

I would wish to understand with an example how is Keyword driven automation framework different from BDD like Cucumber?


First understand BDD:

BDD is not just about testing it is a type of development practice, that avoids the difficulty of providing a definition of "Done".

https://dannorth.net/introducing-bdd/ the author of BDD style defines

As per the document

“Behaviour” is a more useful word than “test” Now I had a tool – agiledox – to remove the word “test” and a template for each test method name. It suddenly occurred to me that people’s misunderstandings about TDD almost always came back to the word “test”.

That’s not to say that testing isn’t intrinsic to TDD – the resulting set of methods is an effective way of ensuring your code works. However, if the methods do not comprehensively describe the behaviour of your system, then they are lulling you into a false sense of security.

I started using the word “behaviour” in place of “test” in my dealings with TDD and found that not only did it seem to fit but also that a whole category of coaching questions magically dissolved. I now had answers to some of those TDD questions. What to call your test is easy – it’s a sentence describing the next behaviour in which you are interested. How much to test becomes moot – you can only describe so much behaviour in a single sentence. When a test fails, simply work through the process described above – either you introduced a bug, the behaviour moved, or the test is no longer relevant.

I found the shift from thinking in tests to thinking in behaviour so profound that I started to refer to TDD as BDD, or behaviour- driven development.

It shows that focusing on the behavior of the system than on functionality we get more clear understanding on

  1. What to implement
  2. What to test
  3. What to consider as acceptance criteria for marking a story "done"
  4. Where to start , keep story as the starting point it defines what functionality and what behavior the system should have. It avoids the cases of having misunderstanding about the system and ensures there is no "absence of error fallacy" (absence of error fallacy mean there is no errors but the system itself is not usable as it was not build the way it was required to be )
  5. What changes to make and what are its effect on the system behavior
  6. Provides more traceability and visibility of system functionality and features
  7. More test coverage traceability as you know what all scenarios or behaviors to be covered

Difference between BDD and KDT



Behaviour-driven development uses a story as the basic unit of functionality, and therefore of delivery. The acceptance criteria are an intrinsic part of the story – in effect they define the scope of its behaviour, and give us a shared definition of “done”. They are also used as the basis for estimation when we come to do our planning.

Most importantly, the stories are the result of conversations between the project stakeholders, business analysts, testers and developers. BDD is as much about the interactions between the various people in the project as it is about the outputs of the development process.


Keyword driven testing is a way of achieving the BDD approach in testing , you can define the behavior of a system using keyword.

you can also do this using Gherkin as in cucumber

Framework like Robotframework supports both keyword abstraction and use of Gherkin(Given,when,then)


BDD is a development practice where user stories are defined by defining the expected behavior of the system. It allows more clarity on what to develop, test and deliver.

and KDT is the approach of implementing BDD in test framework so that we get test coverage and one to one traceability with our test scripts and user stories

Gherkin* is another syntactical way of defining BDD in test,

so you can use both Gherkin, Keyword driven , or simple page object method abstractions that defines behavior than functionality in your BDD test framework.


Unless the keywords or Gherkin or test methods defines the behavior of the system , non of Gherkin , Keyword driven or simple test methods cannot be considered as Behavior driven, they become just Gherkin , KDT or plain low test methods.

so not all keywords or Gherkin or test methods are BDD compliant

  • 1
    Thank you so much for this detailed explanation. – JKC Mar 22 at 5:26
  • 1
    Great answer, but a small fix correction- KDT existed before BDD and as a separate method after it. You can use KDT as a "poor mans automation" for example for teams with non technical testers, the same way as no-code frameworks of now. One can claim that this is a simpler kind of BDD, but officially they were unrelated. – Rsf Mar 22 at 7:21
  • Yes it's just a abstraction , when your keyword explains behavior of the system than functionality then it becomes bdd. Thanks for mentioning that will update it in answer – PDHide Mar 22 at 7:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.