Feature/Scenario Review Checklist

When writing and reviewing .feature files, here are the quality indicators to be on the lookout for:

Features

The feature should:

• Comply with formatting standards
• Have an accurate business value
• Name the right system actor
• Describe the system actor's need/want consistently with the scenarios in the file

Scenarios

The scenario/s should:

• Comply with formatting standards
• Have one and only one given/when/then section (each with any number of And/But statements) in that order.
• Use Background statements appropriately to place the system in a known state
• Use Givens to place the system in a known state. Note, if you have a given in the background and another given step in a scenario, start the scenario with and, not a second given.
• Describe the steps the system actor takes to change the state of the system in the When block
• Describe the anticipated outcome of the actions the system actor performed in the Then block
• Clean up after themselves appropriately
• Use Scenario Outlines where ever there are repetitive checks
• Use random text step to fill in text fields in forms

The scenarios should never:

• Depend on actions performed or data created in other feature files
• Depend on data that is likely to change in the course of normal site use
• Create situations where a test run twice in a row would fail on a second run
• Leave data in the directory of the system running tests

Some exceptions:

• With some complex features, scenarios in a single feature file may need to be run sequentially, each depending on the success of the scenarios in the file that come before. Any dependent scenario must be tagged with @dependent