This section contains Gherkin notes

The main point of this site is that Selenium, Specflow, Gherkin and NUnit work like a hand in a glove. Together they ensure your automation efforts in Selenium give you the maximum return on your investment.

For an application and company you can create a Gherkin Dictionary. The idea of the Gherkin Dictionary is that your BA, Testers and Developers can mix and max Gherkin commands that have been written to extend the testing of the product without having to know how to code. This will all become clear as you read through this web site and understand Gherkin and the Gherkin Dictionary. My focus here is on Agile and Specflow. There are many ways to implement and these are just my suggestions.

Specflow's use of Gherkin and my notes

In Specflow Gherkin commands are stored in Feature files. Personally, I have one feature file mapping to one User Story (Agile) and then scenario's mapping to each acceptance criteria of that user story. (More details and screen shots in the Specflow section)

Gherkin commands are in bold.
Feature I tend to give the user story number. This then give a clear trace from your user story from your BA (Should be documented in a system) that will map into your manual testing repository (ALM for example) then link to your automated tests. This ensures any audit or compliance have a clear map from end to end. The Feature description is not mandatory but a good template to follow is:-
In order to <meet some goal>
As a <type of stakeholder>
I want <a feature>
Notes: Feature is used as the method title so no spaces. The parser will ignore everything after the first Feature line as the rest is for human information only.
I will add a graphic example as I populate this site.

Given I clear the already created users
Notes: The background operation is performed before every Scenario is run.

The Scenario is the work horse of the feature file.
I give it the name of the user story number appended with the acceptance criteria number that is being addressed. You might have several scenario numbers from ALM to meet an acceptance criteria due to testing such as boundary analysis. Again you have a clear audit trail from BA through ALM into Automation. (Should be clearer in the NUnit section)
Within the Scenario you have a number of statements that are possible.
Given This is used for setup context. i.e. I have gone to the site URL. (More details later)
When Tends to be used for interaction with the system. i.e. I click the button.
Then Tends to be a check on the outcome of an interaction. i.e. I then see
And This is an augment for the previous statement. You could have
When I click button 'Yes'
And I click Button 'No'
This can is the same as the following two lines as the And just repeats the command from the line above
When I click button 'Yes'
When I click Button 'No'
I am not a fan of the And as the aim here is to have Manual testers, BA, developers etc etc writing and testing feature files. They can cut and paste lines from the Gherkin dictionary into existing feature files. The And just causes people confusion. They paste a Then between a When and And causing the And to fail as it is trying to find a Then statement when it needs a When. Examples to follow.

Notes: Each scenario must be stateless. (Must make sense and be able to be executed independently of any other scenario).

Scenario outline:
This is different from Scenario: because it contains embedded references to examples. It contains all the standard Given When etc. So it might contain:-
When I enter <Username>, <Password> into field
Then I should see <Username> has been logged on
Notes: Column headers are case sensitive.

An # at the start of any line will comment that line out. This is quite useful when doing exploratory testing.