Writing your scenarios at the right level of abstraction is critical to building an effective test suite. Here are a few guidelines that can help you get there.

• Tests should be independent of the user interface of the application.
• Tests should strive to be at the highest level of abstraction possible, without sacrificing readability.
• Don't repeat yourself: Repeating a series of steps at any level -- at a scenario, or in the implementation can increase the maintenance overhead.
• Use Extract Concept and Push to Implementation to achieve granularity that reflects your domain and also promotes reuse
• Your test should ideally be an illustration of the functionality as opposed to some UI mechanics. For instance, if a test reads:

  shopping cart

  • enter "5" in units and "10.0" in price and select "air shipping" in shipping dropdown
  Description of the UI clutters the intent here. Instead the test:

  shopping cart

  • create order for "5" units at price "10.0" for "air shipping"
  helps clarify the intent.

Using Contexts appropriately can help keep your Scenarios simple and avoid side effects.

• Actions that are part of the execution of scenario, but not relevant directly to the test should be modeled as a Context.
• Contexts help you bring the application to a defined state before execution of your tests. Contexts also help bring the application back to the state before execution of the test using setUp and tearDown).

Tags provide you with the ability to quickly select a subset of your scenarios for execution. Appropriate tagging can help you identify the affected scenarios easily when you make changes to the application.

Some of the suggested ways of tagging scenarios are:-

1. Based on the functionality covered (like shopping cart, account transaction, etc.)
2. Type of test (smoke, regression and so on)
3. Status related tags (Like In Progress: For instance, this allows you to quickly isolate scenarios that are not complete yet from being executed as part of your project build.)