Как навести порядок в отчётах Allure: 6 уровней аннотаций, которые реально работают

Если вы используете Allure, то знаете: отчёты могут быть разными: с фильтрами, деревом фич, ссылками на баги, а могут быть унылой простынёй из сотен тестов без смысла и структуры.

Всё зависит от того, как вы помечаете тесты. Allure даёт мощную систему аннотаций, и если её использовать с умом — отчёт превращается в полноценный инструмент для анализа и коммуникации.

Ниже 6 уровней аннотаций, которые помогают держать тестовую базу в порядке. Без перегруза — только то, что действительно работает.

Таблица аннотаций Allure по уровням

№	Уровень	Зачем нужен	Что использовать
1	Глобальная структура отчёта	Формирует дерево: подсистема → модуль	parentSuite, suite, subSuite
2	BDD-структура	Показывает логику: фича → сценарий	epic, feature, story
3	Важность теста	Определяет приоритет и критичность	severity
4	Ответственность	Кто за это отвечает	owner, lead (через label)
5	Классификация	Для фильтров, запуска, анализа	tag, framework, language
6	Интеграции и ссылки	Связь с багами, документацией, TMS	issue, tms, link

Расшифруем:

1. Глобальная структура

Сюда идут parentSuite, suite, subSuite. Это просто: на каком уровне находится тест. Например:

• Payments → CreditCardTests → NegativeCases

Такое дерево делает отчёт читаемым. Особенно, если тестов много.

2. BDD-структура

Здесь уже логика продукта:

• epic: большая функциональность (например, "Authentication")

• feature: часть эпика (например, "Login")

• story: конкретный юзер-кейс (например, "Valid login via email")

Если используете BDD или просто хотите, чтобы бизнес понимал, что проверяется — сюда.

3. Важность (severity)

Показывает, насколько критичен тест:

• BLOCKER: прям must-have

• CRITICAL, NORMAL, MINOR, TRIVIAL — дальше по шкале

Можно запускать только важные тесты, отслеживать падения и видеть, где действительно все плохо.

4. Ответственность

Кто починит упавший тест?
Аннотация @Owner("ivanov") говорит — вот этот человек.
А @Label(name = "lead", value = "petrov") — можно указать тимлида или команду.

Очень удобно, особенно в большой команде.

5. Классификация

Для всего остального:

• @Tag("smoke"), @Tag("regression")

• @Label("framework", "JUnit")

• @Label("language", "java")

Можно фильтровать тесты, запускать нужные группы, отсекать лишнее.

6. Интеграции

Привязка теста к багам, задачам и документации:

• @Issue("BUG-123") — баг из JIRA

• @TmsLink("TMS-456") — тест-кейс из TestRail или Qase

• @Link(name = "Docs", url = "https://...") — например, ссылка на требования

Allure сам превращает это в кликабельные ссылки — удобно!

Зачем всё это?

Без аннотаций	С аннотациями
Хаос в отчёте	Структура по модулям и логике (suite, epic)
Неясно, кто чинит тест	Ответственный (owner)
Все тесты одинаково важны	Есть приоритет (severity)
Трудно выбрать нужные тесты	Теги, фильтры (tag, language)
Никакой связи с багами и документацией	Прямые ссылки (issue, tms, link)

Вывод

Allure — мощный инструмент, если использовать его возможности. Эти 6 уровней аннотаций:

• добавляют структуру,

• экономят время при анализе падений,

• помогают команде понимать, что тестируется и зачем.

Немного внимания к меткам — и ваш отчёт будет говорить сам за себя.