Learning Objectives
By the end of this lesson you will be able to:
- Explain why a tagging convention needs to be agreed on and written down, not left implicit
- Decide the correct priority tag for a new scenario using a worked example
- Recognize tag sprawl and describe why it makes a convention useless
A Convention Only Works If Everyone Shares It
Knowing what @critical should mean doesn't help if half the team uses it for "this is important to me personally" and the other half reserves it for "the business loses money if this breaks." Tags are only useful as a filter if every author applies them the same way — which means the meaning of each tag has to be agreed on by both BA and QA, and written down somewhere everyone can check.
A short tag glossary is enough — a table in a project wiki or a comment block at the top of a shared feature directory:
@smoke — fast subset, runs on every commit, verifies the app isn't broken
@critical — revenue, security, or data-loss impact if this scenario fails
@regression — full suite, runs nightly / before release, includes edge cases
(no tag) — normal functional coverage, not singled out for priority
Short enough to read in ten seconds, specific enough that two different people reach the same tagging decision independently.
Worked Example: Tagging a New Scenario
Say a new scenario needs a priority tag: "Admin deletes a user account." Walk through the glossary:
- Is it a fast, cheap check that should run on every commit? Deleting a user usually involves confirmation dialogs and cascading effects — not a quick smoke check. Not
@smoke. - Does failure here have serious business consequences? Yes — an admin accidentally (or a bug) deleting the wrong account, or deletion silently failing to cascade, is a real data-integrity and trust problem. This is
@critical. - Should it also run in the full nightly suite? Yes, virtually all critical scenarios do. Also
@regression.
Compare that to "Admin changes a user's display theme preference" — low business impact, no data-loss risk, a fine candidate for no tag at all, or @regression only. The glossary gives both a BA and a QA the same reasoning path, so they land on the same tag independently of who's deciding.
The Risk of Tag Sprawl
Once tags exist, it's tempting to keep inventing new ones for every situation: @edge-case, @needs-review, @flaky, @author-jane, @sprint-14. Each new tag might feel useful in the moment, but a convention with fifteen undocumented, overlapping tags stops being a convention — nobody can tell which ones matter, filtering by tag becomes unreliable, and new team members have no way to learn the "real" meanings without asking around.
Tag sprawl is avoided the same way scope creep in any process is avoided: every new tag has to earn its place in the glossary before it appears in a feature file, and existing tags are reused rather than duplicated with a slightly different name.
Pro Tip: If you're about to add a tag and can't summarize its meaning in one sentence that a teammate would agree with without asking follow-up questions, it's not ready for the glossary yet.
Key Takeaways
- A tagging convention is only useful if BA and QA agree on it together and document it as a short glossary
- Deciding a new scenario's tag means walking through the glossary's criteria, not guessing by feel
- Tag sprawl — too many overlapping, undocumented tags — makes filtering unreliable and the convention meaningless
- A new tag should earn a documented place in the glossary before it's used in any feature file