 |
The ability to document test scripts in the exact way the user intends has always been the ultimate dream for testers. Until the early 2000s, the communication gap between the technical teams and the stakeholders was notorious. Just like a game of Chinese Whispers, system specifications would get distorted by the time they reached the engineer’s ears. This, in turn, would lead to the development of products that did not match the stakeholder’s blueprint. Since the development team would have a skewed image of the requirements, even the testers would end up measuring the system’s legitimacy against incorrect standards.
This led to the search for better strategies to enhance collaboration between the involved parties.
Enter BDD …
What is BDD?
BDD (Behavior-Driven Development) is an Agile software development approach that emphasizes what the software should do rather than just how it should do it. It aims to bridge this gap by focusing requirements on user-centric stories and clear communication.
BDD drew inspiration from existing agile methodologies, such as Test-Driven Development (TDD) and Acceptance Test-Driven Development (ATDD). It also aligns well with agile methodologies like Scrum, which emphasize iterative development and collaboration. It is widely used as a framework for capturing user stories and defining success criteria within agile projects.
Impact of BDD on software testing
When it comes to software testing, BDD helps guide testers to focus on ‘what the user wants‘ rather than ‘how the system is built‘. This user-centric undertone is reflected in every single testing-related activity, like writing test cases, interpreting test results, and reporting findings to the development team and stakeholders. Since the user’s point-of-view is such a huge deal, BDD extensively relies on end-to-end testing to adhere to this criteria.
Having requirements defined clearly as user stories in simple language works in favor of the QA team. This clarity in requirements translates to creating well-defined and easy-to-understand test cases. Everyone involved, from developers to testers, has a shared understanding of what’s being tested.
You’ll see that there are many BDD frameworks available, such as Cucumber. Most of them integrate with test automation tools, allowing the creation of automated tests from BDD specifications. This translates the plain language descriptions into executable tests, saving time and effort during the testing process.
Another interesting impact of BDD is that it generates ‘living documentation‘, that is, documentation that keeps growing and evolving like the product. These BDD specifications that are part of the documentation evolve alongside the software development process. They become a valuable resource for testers throughout the project lifecycle.
Key aspects of BDD
BDD has a few distinct concepts that make it popular:
- The main goal of BDD is to achieve collaboration among all stakeholders, such as developers, testers, business analysts, and product owners, in defining the system’s requirements and behavior.
-
It is a common language that is understood by both technical and non-technical stakeholders is adopted. This language typically involves domain-specific terminology and is used consistently across the project. The idea was to allow users to write specifications in Gherkin Language, which looked like this:Scenario: Eric wants to withdraw money from his bank account at an ATM
Given Eric has a valid Credit or Debit card And his account balance is $100 When he inserts his card And withdraws $45 Then the ATM should return $45 And his account balance is $55
- BDD uses user stories to describe the desired functionality of the software. These stories are written in plain language and focus on what the user wants to achieve. User stories are further broken down into specific scenarios that outline how a user interacts with the system to achieve a particular goal. Scenarios typically follow a Given-When-Then (Gherkin) syntax.
How does BDD help?
Once a scenario is created, a QA Engineer can write code (usually in Selenium) to implement the specification in code before the actual implementation is ready.
The advantages of that are supposed to be:
- Business users build the specifications for how the application is supposed to work before it is implemented.
- Once implemented, it is supposed to double down as a regression test, ensuring that the functionality still functions as expected.
Issues with BDD
In theory, BDD is fantastic – it promotes continuous collaboration while keeping the user’s needs at the heart of these discussions. But as great of an idea as it seemed, when put to practice, there are several problems with BDD when written with Selenium or any other code-based testing tool:
- Specifications are useless until the code (Selenium or similar) is written.
- To write code for each of the specifications, experts in coding are needed. This creates a middle-man situation where business folks and manual testers cannot directly alter specifications. These unnecessary steps create communication, and eventually, implementation problems.
- Gherkin Language is hard for business users to understand and use despite its being in an English-like format.
- Writing detailed scenarios becomes time-consuming, especially for complex systems with many edge cases. This slows down the initial phases of development as the team invests time in defining comprehensive specifications.
- It adds additional overhead because of the need to maintain the additional, tightly-coupled specification code pieces.
- The maintenance suffers from all the issues of the underlying implementation (Selenium, etc.), namely the reliance on the HTML/XML structure of the page/screen as opposed to the end-user’s point of view.
- It is almost impossible to write the implementation of the Gherkin specification until the actual feature is released because the implementation of Gherkin relies on XPaths.
BDD poses a risk of misuse since teams end up focusing too much on the tools and syntax rather than the underlying principles of collaboration and communication. This leads to most implementations of BDD to fail because they cannot deliver enough value to justify the additional overhead.
BDD 2.0 (SDD)
BDD 2.0, or Specification-Driven Development (SDD), builds upon the foundation of Behavior-Driven Development (BDD) with the goal of addressing some of BDD’s limitations. The limitations it addresses are:
- Limited user participation: While BDD promotes collaboration, writing user stories and scenarios might still require some technical knowledge, potentially limiting participation from non-technical stakeholders.
- Focus on steps: BDD can get bogged down in the specific steps a user takes, potentially missing the bigger picture of the desired behavior.
- Test case translation: There can be an extra step of translating BDD specifications into executable test cases.
How is BDD 2.0 (SDD) better?
This is how BDD 2.0 overcomes the above challenges:
- BDD 2.0 emphasizes using a subset of clear and concise English commands. This enables business users to describe steps from an end-user’s perspective, enhancing readability and reducing reliance on technical jargon.
- Unlike BDD, which relies on HTML/XML structures, SDD completely removes this dependency. Everything is expressed from the user’s viewpoint, promoting a more natural flow of conversation.
- A core benefit of SDD is the ability to execute specifications directly as they are. This eliminates the need to write additional code like Selenium in Java or Python, streamlining the testing process.
Automating SDD testing
SDD enables business users to write executable specifications in a domain-specific language that they are familiar with. Just like other forms of testing, even the SDD approach involves repetitive tasks that can be automated. In fact, with the right testing tool, stakeholders need not depend on others to dive into the nitty gritty of test automation.
testRigor for SDD testing
Creating truly executable specifications from natural language descriptions remains a challenge in SDD. But this is where testRigor reigns champion over other test automation tools.
One of the best test automation tools in the market, testRigor is the embodiment of SDD-based testing. It uses AI to allow stakeholders to write their specifications in plain English language. That is why it is a powerful Test Automation Tool For Manual Testers.
Unlike most other BDD tools that require writing code to define each and every English specification, testRigor executes the English language commands out-of-the-box.
click "Register"
generate by regex "[a-z0-9]{30}\@testrigor-mail\.com", then enter into "Email" and save as "newEmail"
enter "password123" into "Password"
click "Sign Up"
check that email to saved value "newEmail" was delivered
check that page contains button "Confirm Registration"
click "Confirm Registration"
check that page contains text "Successfully confirmed"
Each instruction is executable out of the box. There’s the provision for modularity allowing to assign a sequence of steps to any arbitrary name like ‘checkout a product’. Read more about testRigor’s reusable rules.
Through testRigor’s BDD 2.0 implementation, you can foster a more collaborative and user-centric approach to software testing. The tool gives you all that you will need to make your test automation endeavors fruitful.
By using plain English (or any other natural language) and executable specifications, you can improve communication, reduce development time, follow BDD seamlessly, and ensure the delivered software meets user expectations. testRigor lets you write plain English commands for complex scenarios such as:
- Global Variables and Data Sets: You can import data from external files or create your own global variables and data sets in testRigor to use them in data-driven testing.
- 2FA, QR Code, and Captcha Resolution: testRigor easily manages the 2FA, QR Code, and Captcha resolution through its simple English commands.
- Email, Phone Call, and SMS Testing: Use simple English commands to test the email, phone calls, and SMS. These commands help validate 2FA scenarios, with OTPs and authentication codes being sent via email, phone calls, or phone text.
- File Upload/ Download Testing: Execute the test steps involving file download or file upload without the requirement of any third-party software. You can also validate the contents of the files using testRigor’s simple English commands.
- Database Testing: Execute database queries and validate the results fetched.
- Cross-browser and Cross-platform Support: testRigor supports seamless cross-browser and cross-platform testing on real devices, ensuring your application functions correctly on various browsers and operating systems.
Read more about testRigor’s features to see what else it can do for you to make your testing process simpler and more robust.
Summary
In theory, BDD is great for promoting clear communication and user-centric efforts among the development and testing teams. However, when put to use, numerous challenges emerge. To overcome these challenges, SDD was brought into the picture. The system specifications are written as executable steps in a user-friendly language. Thus, the focus is brought back to the user rather than the implementation hassles, as is the case with BDD.
The challenge with SDD is to implement the specifications in executables. For this, you need to look for testing tools that allow you to do this easily and quickly. Your best bet is to migrate from legacy tools to modern and intelligent ones, like testRigor.
