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 first describe a story and then further refine tests, often with additional acceptance criteria that work across various scenarios.

As the process commences, it’s as though the team gets swept through a funnel. At the top of the funnel, initial acceptance criteria defined in loose terms and 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:

• The development stage of the SDLC speeds up significantly for faster releases and better-quality software
• Tests can be written at an early stage in the development cycle (that’s a good example of shifting left, by the way)
• Different roles (product developers and owners, testers, software engineers, stakeholders, etc.) are able to join the process of writing user behavior expectations and story scenarios
• BDD offers better transparency in the process of developing and implementing new features and sets out clear rules and expectations for existing features
• BDD requirements are an excellent form of living documentation that provide a clear roadmap for upcoming features and can be used by any staff regardless of technical ability
• A set of established, agreed-upon requirements means a single source of truth from which any team can develop and maintain the feature, while still ensuring that the behavior stays true to the original intention at the time of implementation

Where Virtuoso comes in

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 journeys 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.