We definitely recommend that you not bother with G/W/T during example mapping. My preferred technique is to divide the card into 3 columns and write context/action/outcome in each column. Sketches can also be really powerful.  

Typically Gherkin hasn’t been the issue. However, there are other tools that address similar functionality. FIT/Fitnesse is the most venerable. Pryce/Freeman’s book Growing Object Oriented Code Guided by Tests uses JUnit directly. 

Context/Action/Outcome can be expressed in technical terms if that is appropriate for the story. We typically don’t find teams using BDD for performance/load/penetration testing, although even that can be structured as examples. 

At present, there is no automated way to convert example maps into feature files. The CucumberStudio team have this on their backlog. 

Neither. Gherkin is an Open-Source project that defines a syntax and delivers multi-language parsers. Many automation tools make use of Gherkin.  
 
Using Gherkin does not imply that you are doing BDD - it’s just a syntax. BDD is the application of the three core practices - Discovery, Formulation, Automation. 

Yes. 

I’d recommend reserving time at the end of the example mapping session to collaboratively de-duplicate. Without deduplicating it’s hard to see if rules have been adequately illustrated by examples and splitting stories can be problematic. If you run out of time, de-duplicate at the start of the next example mapping. 

From a discovery perspective, there is no difference. Once you have the illustrative examples you’ll have to decide whether to document them using domain language or pass them to the technical team who can use them to drive out the technical solution using programmer/unit tests. 

I’ve seen significant benefits from adopting Discovery, because it prioritises early learning, leading to reduced misunderstandings and therefore less rework. Customers and colleagues have reported that Formulation adds additional benefits, notably unambiguous manual test scripts written in a shared language, business-readable language. 

You can link CucumberStudio to any Jira Issue, regardless of issue type. That would include Xray issue types. 

If you are interested in test management tools, also consider taking a look at our Zephyr products, where we are actively working with their product teams to support BDD. We offer both standalone and Jira add-ons as options.  

The purpose of example mapping is for the team to imagine how the system will behave once the requirements of the story have been implemented. Ensure that they create at least two examples for each story. You may need to prompt them with your own questions if you think they haven’t considered a story’s implications sufficiently. 

Never mention other scenarios in the scenario that you are formulating. When a specific scenario requires the system to be in a very specific state (which they often do), try to find a succinct way of expressing it. 

For example, if you want to check minimum order $20 for free delivery, instead of: 

Write: 

Yes, it does, and the Gherkin editor is under active development. 

We support it now with Okta. 

This will vary from team to team, because in many situations the UX forms an important part of the business rules. I’ve seen teams have success when UX is sketched out alongside the initial story. Then PO/BA and UX go to the attend the example mapping session and respond to examples provided by the delivery team. 

+1 

Christophe, the Product Owner, says:  

“We are working to build a more coherent BDD workflow on one side, and a tighter integration between Cucumber Reports and CucumberStudio on the other side.

More coherent BDD workflow means integrated with Git, Jira, and Cucumber Open: we want teams to be able to take a user story from Jira, run discovery and refine it with example mapping, formulate new and existing features from this discovery work, get their formulation reviewed, push it to git so that developers and automation engineers can start implementing the stories, and fill the feedback loop with the continuous push of Cucumber Open execution results that will update CucumberStudio’s living documentation, and this should be visible from Jira and other tools as well.

For Cucumber Reports, it’s a free service, and anytime users want to enroll in a more complete environment, they’ll have the ability to do it in a snap and start editing and reviewing the features they initially pushed in Cucumber Reports.

Finally, I’d like to seize the opportunity to recruit users that are ok to try beta software and participate in usability tests. "

It is in final edit at the moment & the Leanpub e-book is available via bddbooks.com (& free updates will be available in the coming weeks). The printed version should be available 2021Q3 

The “BDD with Cucumber” project type pushes & pulls from GH 

It is ideal to have a team that works on the full solution stack. In that case the scenarios should be expressed describing business behaviour. Advanced teams can make use of hexagonal port/adapter architecture to automate the scenarios at variable levels of the architecture (see https://skillsmatter.com/skillscasts/9971-testable-software-architecture-with-aslak-hellesoy)