Tagging Strategy: @smoke and @critical

Learning Objectives

By the end of this lesson you will be able to:

Write valid Gherkin tag syntax above a Scenario or Feature
Explain the standard meaning of @smoke, @critical, and @regression
Describe how tags let both a test runner and a human filter a suite

Tag Syntax

A tag is a word prefixed with @, placed on its own line directly above the Scenario: (or Feature:) it applies to. A scenario can carry more than one tag:

Feature: Checkout

  @critical @regression
  Scenario: Payment fails when the card is declined
    Given a cart containing one item priced at $50
    And a credit card that will be declined by the payment processor
    When the customer completes checkout
    Then the order is rejected with a payment-declined error

  @smoke
  Scenario: Standard checkout with a valid card
    Given a cart containing one item priced at $50
    And a valid credit card on file
    When the customer completes checkout
    Then the order is confirmed

Tag on Feature: instead of an individual Scenario: and it applies to every scenario in that file — useful when an entire feature shares the same priority.

The Standard Priority Conventions

Three tags cover most of what a QA/BA team needs to express:

@smoke — a small, fast subset of scenarios that verify the application isn't fundamentally broken. Run on every commit, in minutes, as an early warning system.
@critical — business flows that must never break: payment processing, login, data loss scenarios. These get the most attention during a release and are often run even when time is short.
@regression — the full, slower suite: everything, including edge cases and less commonly hit paths. Typically run nightly or before a release, not on every commit.

A scenario can hold more than one of these — a @critical flow is very often also @smoke, since "must never break" and "check it constantly" tend to go together.

Untagged Scenarios Are Meaningful Too

Not every scenario needs a priority tag. A scenario with no tags at all is implicitly saying "this matters, but it's neither a smoke check nor a release-blocker" — usually a regular functional case covered by the full suite but not singled out for extra attention. Leaving a scenario untagged is a deliberate signal, not an oversight, as long as your team's convention says so explicitly.

Tags Are Filters, for Machines and Humans

A test runner uses tags to decide what to execute: --tags @smoke runs only the fast subset; --tags "@critical and not @regression" combines them with boolean logic. That's the automation-facing use.

But tags are just as valuable to a human skimming a feature file. Someone reviewing test coverage before a release doesn't need to read every scenario in detail to know what's at stake — the @critical label already tells them.

Pro Tip: Resist inventing a new tag on the spot mid-scenario. If a tag isn't already part of your team's documented convention, it's noise the next person has to decode — write it down first, then use it.

Key Takeaways

A tag is @word on its own line directly above the Scenario or Feature it applies to
@smoke = fast subset run constantly, @critical = must-never-break flows, @regression = the full slower suite
A scenario can carry multiple tags, and an untagged scenario is a deliberate, meaningful choice
Tags filter a suite for test runners via boolean expressions, and communicate priority to human readers just as well