A large part of BDD (Behavior-driven Development) is determining the acceptance criteria for a new product feature or solution. The acceptance criteria become acceptance tests, and these are later automated. Have you heard of the Given-When-Then format, and Gherkin? This is typical BDD syntax, and is used to firstly describe a story and then further refine tests, often with additional acceptance criteria that works across various scenarios.
As the process commences, it’s sort of as though the team gets swept along through a funnel. At the top of the funnel, initial acceptance criteria defined in loose terms and with bare-minimum requirements are tossed around between various teams and players. The funnel starts to narrow as requirements become detailed and refined to outline expected behaviors. Finally, the funnel spits out automated acceptance tests based on the focused business requirements and these can be run at any time to validate that the system continues to function in accordance with the new expected behaviors. This is an oversimplification, of course - determining BDD requirements is a complex process involving many moving parts that might have trouble coming to a consensus at any stage of the process.
But once teams can agree on the expected behaviors and desired requirements for a story or feature, BDD offers some rewarding benefits:
Not in the mood to read? See our Lead Sales Engineer James Bent in action as he works with requirements here.
Have you written BDD requirements? Fantastic! This is the point where you can start creating automated tests. Users can import requirements directly into Virtuoso. The requirements are then embedded and with the click of a button, you can create the end-to-end paths a user might take. Virtuoso will create a checkpoint for each of the scenarios found within your requirements, ensuring that you have a framework for the various test cases you might want to implement. Test steps are written in Natural Language Programming, making it easy for any user to go in and change or update steps using plain English. No code needs to be in place - as long as you have the names of the elements that will appear in your application, the tests can be mapped out and refined as the development process continues.
Still wondering how automatically building tests from requirements can work for your organization? Simply book a free demo with one of our amazing customer success experts to find out.
How to shift your testing left and build web automation that keeps up with your development.Download eBook