Testers provide evidence that the system under development is built conform to its requirements. Based on requirements, testers develop test cases that when executed prove the system works correctly or needs corrections. Some test approaches (e.g. Test Driven Development aka TDD) suggest to start with writing test cases and test code and once test code fails continue with development of production code that passes the tests(*). This is kind of a begin with the end in mind philosophy, isn’t it?

The truth is that writing good (and challenging) test cases requires deep understanding of what the system is required to do and qualities with which it has to happen. Developing tests directly helps in clarifying requirements.

Behavior Driven Development recommends to define the expected system behavior in a domain-specific language called Gherkin. Teams together with stakeholders collect examples of required system behavior, group them into features and document them as scenarios. The main structure of an example/scenario is:

SCENARIO: name of a scenario

GIVEN certain system and environmental conditions

WHEN a trigger is applied or an event happens

THEN the system should display certain, observable to users behavior

Gherkin is a language of little words: ten to be precise, all understandable to different stakeholder groups. If you want to read more about the Gherkin syntax I recommend an article from Guru99. The focus of a scenario is on the observable system response to an event/ trigger. This characteristic makes Gherkin very usable technique at refinement sessions and requirements workshops. Many teams use Gherkin to document acceptance criteria of a user story.

Main benefit of using Gherkin, is that teams and stakeholders move from discussing abstract concepts to gathering tangible and concrete examples, right from the battle field where the improvements are needed. Discussions are channeled to what is the context in which the system is used, what stakeholders want from the system reflected in a trigger and finally the definition of expected behavior. Scenarios trigger questions; scenarios trigger discovery of new scenarios simply by asking a question “What if?”; scenarios help clarifying expectations; scenarios help defining exceptional behavior (frequently forgotten). All that resembles business analysis work a lot, don’t you agree?

Dan North, creator of BDD, explained in his article “Introducing BDD” that scenarios unite different disciplines: stakeholders, programmers, analysts, testers by creating a common ground for the development efforts. If one decides to automate scenarios and link them to your code and tests, it is possible to realize a unity between different disciplines within a team… But if you are starting your journey with Gherkin, start small. Check with your team whether defining the scenarios (examples) and documenting them with Given… When… Then… results in more clarity and better discussions with your Product Owners and stakeholders. When it proves its added value extend the practice.

Good luck!

(*) This approach gives the developers confidence that the code they produce does what it supposes to do: no waste of effort or gold plating.