Best practices
Tagging policy
A small, enforced vocabulary keeps suites selectable and reports meaningful.
What you'll learn
How to assign suite tags, when to add feature tags, how modules make expectations explicit, and how to keep the vocabulary from growing.
- One layer, one suite, always. Lint enforces it; do not disable lint to get a green run.
@smokeis a budget. Keep it under a few minutes per browser; it runs on every pull request.@regressionis the truth. Everything with product value; nightly on every browser.@sanityis targeted. After a hotfix or a data migration.- Feature tags describe mechanics (
@visual,@a11y,@perf,@mock,@pool), not teams. Put ownership on modules (owner,jiraComponent). - Value tags carry facts (
@user:admin,@data:orders,@har:checkout,@jira:SHOP-42); lint validates them against the project. - Prefer
@skip:<browser>to code branches. The exclusion stays visible in reports. - Put
@req:<id>where the requirement lives. A requirement a whole feature verifies goes on theFeature; one scenario's goes on the scenario. Whoever signs the traceability export decides what the ids point at. - Retire tags. Remove entries from
tags.extrawhen nothing uses them; unknown tags warn, so drift is visible.