Behavior Driven Development

Behavior Driven Development (BDD) Three Practices

First, take a small upcoming change to the system – a User Story – and talk about concrete examples of the new functionality to explore, discover and agree on the details of what’s expected to be done.
Next, document those examples in a way that can be automated, and check for agreement.
Finally, implement the behaviour described by each documented example, starting with an automated test to guide the development of the code. The aim is to:
make small changes rapidly
back up 1 level when need more info
automate and implement a new example to get feedback BDD Example:

- Feature: User Login
*As a user I want to login into the Company's website using my existing account so that I can use other features*
- Scenario Outline: Login with valid credential
Given I navigate to <Company Login Page>
When I input <Username>
and I input <Password>
and I click Login Button
Then I should be able to login successfully
- Examples:
| Email | Password
| abc@company.info | password 1
| abc2@company.info | Password@

Personal note on implementing BDD and TDD:
Mistakes are that people only implement BDD/TDD practices at Testing phase when they implemented automation test. However it should be as early as possible. Using “BDD” to only cover automation test is not BDD.
BDD helps products and developers realize different scenarios of a same feature, then cover as much as they could at requirement and implementation phase.
BDD borrows * ubiquitous language * concept from domain driven design so that everyone in the team can understand the term the same way.

Source: https://cucumber.io/docs/bdd/