Nowadays writing tests is not only a good manner but one of the requirements to the code. We all know such abbreviations as TDD (Test Driven Development) and BDD (Behavior Driven Development) and many follow these approaches in development. In general, TDD means developing through tests. Actually, BDD is one of the varieties of TDD and was established later, when Dan North suggested that instead of writing tests you should think of specifying behavior or way the user wants the app to behave.
This methodology changes the testers’ role significantly. When ordinarily testers look for defects after the work is done, a great part of issues are requirements defects, so why not involve testers earlier? This is where BDD approach is necessary. Testers can apply their skills during the early stages of development process in order to analyze the requirements.
It is held by creating Executable Scenarios, in other words, the scenarios specified by users are converted to executable tests. BDD frameworks cope with it perfectly. As the whole team is creating the set of scenarios, it provides close collaboration between product owners, project managers, developers, testers and business analysts. This results in higher level of customer satisfaction.
Below are some tips for BDD testers.
Understand BDD Concept
BDD requires the absolutely different tester’s role and testers should know that according to this methodology, “bug is a missing scenario”. And if something does not work after implementation, it means that you haven’t created such scenario. To know the BDD process for testers means understanding that their goal is not to find bugs but to prevent them in the early stage of development.
Take Part in Specification Workshops
It is important to get clear requirements from the product owner, understand the system’s behavior and discuss all possible scenarios. At the meetings on specifications issues the testers’ goal is thinking of how to break the system and creating such scenarios is a way to prevent them after the project implementation.
Write Thorough Feature Files
After having communication with business you need to write down all scenarios, conditions and expectations in the form of feature files. All the quality assurance team should take part in this process in order to make feature files as comprehensive as possible. You can write better feature files using Gherkin Language and its “background” feature which helps to avoid repetitive tasks in each scenario, as well as “Data Tables” which allow to set certain data as a precondition to the tests. For better organization of scenarios and features you can use tags and sub-folders.
Know The Code-Base
Now you have to watch the process of implementations of those feature files and be in collaboration with developers. Knowing all details of the test code will speed up the full process as you will not need additional time to find out what is what if something goes wrong.
Make sure the developers change nothing in feature files
It might happen that developers would wish to change something in feature files thinking that it would make the code easier or more robust. But such changes mean changing requirements, and this has to be agreed by the whole team and business owners.
Know That Missing Scenarios Would Be A Bug
In case of insufficient understanding of a project concept and not considering all possibilities, the set of scenarios might not be full and comprehensive enough. In BDD practice a missing scenario is considered to be a bug, that is why the team working on the scenarios is essential.
It is always a challenge for testers to work with BDD methodologies but their participation is essential for the high-quality product.