The article is referenced from the source: https://www.nagarro.com/en/blog/bdd-behavior-driven-development-agile-project-experience

1. What is BDD?

• BDD stands for (Behavior Driven Development) which is a method invented by Dan North that focuses on describing application behavior instead of focusing on test-oriented software development. When implementing BDD in a real project, there are many advantages in separating cases that are easy to do, easy to imagine, and members of the project team can interact with each other from the beginning (clarify requirement ) … but there are also certain difficulties and in this article we will see how the difficulty that BDD affects the project and what the project needs to do for BDD to be implemented properly in the project. for me.
• Based on the requirements of the system, the way BDD deployed is to write in natural language with three steps as follows:

Step 1: Write the user story (Given)

Step 2: Write your acceptance criteria (End)

Step 3: Write down scenario (Then)

Given-end-then: Can be compared to error reports because they both describe the steps to produce an expected system behavior. However, Given-When-Then is usually written before the system is deployed and error behavior is ignored, while error reporting is written after the system has been deployed and also contains errors:

Given-end-then can also be compared with the famous “Triple-A” Unit test:

2. Project overview

Our goal is to modernize electronic portal through service-oriented architecture. The standalone services are grouped into modules to enable functionality used by business processes.

To develop and test such services, we decided to use the BDD method.

3. Theoretical basis behind BDD implementation

To implement the required modules and services, we have chosen an iterative approach of an Agile model with a 2-week cycle of one Sprint. This means we have a steady stream of stories within the team, where a story typically describes the scope of a service to be developed.

We used development under BDD to:

• Clearly illustrate application behavior by describing specific use cases
• Create a general understanding of the project team requirements
• Include acceptance criteria for BDD situations
• Define the basis for Auto test

=> After a few sprints, we have identified a variety of useful methods and practices that have worked in our project.

3.1. Ten eyes saw more than two

The “Given, When, Then” syntax is proposed for behavior-oriented development that helps the group think clearly about the behavior of the system or the desired outcome of a described function. During our story improvement sessions featuring a person from all roles (tester, developer, analyst, product owner, software architect, etc.), we quickly realized that BDD allows them. I create general understanding of the requirement. This is also beneficial for us in building trust in the purpose of the story and understanding end-user requirements.

3.2. Check data availability

• When describing situations as a tester or test lead, it’s important to consider the test data you need to execute. If possible, try to include real and anonymous data from your system or test.
• This then helps execute scripts as test cases automatically and integrate them into test environment.

Example: The requirement is a data processing test for a given delivery address such as: “Street: Pham Hung – City: Hanoi”, which can be easily integrated on one stage using a test model but will never run on a phase that uses real data.

• Including enterprise or end-user during creation or review of BDD scripts may detect some edge instances or special data constellations may also be included in the test.
• By identifying the necessary test data, we often come across situations and situations that are not covered in the description of the story. Handles specific date / time formats for different countries.

3.3. Scenario classification

It is useful to immediately tag scenarios when creating them, so you can immediately know the type of scenario you’re dealing with (e.g. @Regression , @Smoketest , @ System-Integration, etc.). Doing so will allow you to find some test cases more easily and group them together to execute them in one run, especially if they are automated.

Example: After deployment, all test cases with category “Smoketest” pass before participating in any subsequent test activities.

3.4. Keep prerequisites to a minimum

One of the most important things in the project process is to keep the script outline (describing the scope of the scenario) and “Given” blocks as small as possible. If not, processing and automating scripts can quickly become very complicated and messy. Complex scenarios can reflect the quality and scale of the story. Often times, if the story is not detailed enough or comprehensive, the scenarios tend to be inaccurate. A good rule of thumb is to split a story if it has more than 8-10 acceptance criteria.

3.5. Managing complexity

Although the symbology or syntax of the DBD development is quite obvious, there are instances where you are more likely to describe certain user stories in your situations.

An example of BDD is as follows:

Given: I am on the “Choose Size” tab in the UI

And: the Size is 0 When I click the “Edit“ Button

And: I click in the Input field

And: I enter the value “50“

And: I click the save Button

Then: the new Size should be 50

This description is very detailed and is mainly based on UI elements such as “buttons” or “input fields”. It is also like a description of a process instead of a behavior. This will be time consuming at the maintenance stage if some UI buttons change or if the function switches to another tab.

Here is a better approach:

Scenarion: User wants to edit the size of an app to make purchases

Given: the Size is <initial>

When: the User changes the Size to <newSize>

Then: the new Size should be <ResultSize>

For example:

In this case, it doesn’t matter what the buttons are called or where to find the function – it’s just the behavior illustrated with three examples. The behavior will be the same no matter any of the implementation details described.

During the project, it took everyone on the team a few sprints to think on a more abstract level than focus on behavior.

3.6. Determination of responsibility

BDD helps a lot in understanding the responsibilities of the different roles in the software development team. There is a distributed team, which sometimes makes communication complex. With BDD, you can create tasks for different team members according to situations, thus making things clearer.

For example:

The tester is responsible for providing test data.

Developer and engineer Automation test are responsible for implementing the script in code form.

The Product owner receives suggestions on advanced cases from users.

The software architect makes sure that any functional flaws discovered in the requirements are reviewed in a new service.

Conclude:

BDD-oriented development has been of great help in enhancing understanding among team members, especially when there is clarity of different responsibilities and discussion of situations between roles. different. Getting started with BDD can be a little tricky, but sticking with it is really effective, as long as you always adapt and improve the way you use it as a team. The most outstanding benefit that BDD brings is that it encourages, requires team communication and coordination, thus ensuring high quality from the very beginning of the project.