docs: add Allure Report interview questions

src/pages/qa/index.md

@@ -317,9 +317,44 @@ database query duration, queue depth и timeout rate. Среднее время
 <summary>Что такое Allure Report?</summary><br>
 <table><tr><td>
 
-Allure Report — инструмент для красивой и структурированной отчетности по автотестам. Он показывает test suites, test
-cases, steps, attachments, history, duration, labels, severity, owners и trend по запускам. Allure не делает тесты
-качественными сам по себе, но помогает быстрее понять, что сломалось и где искать причину.
+Allure Report — open-source инструмент для визуализации результатов автотестов. Он преобразует структурированные данные
+о прогоне в интерактивный HTML-отчет с тестами, шагами, длительностью, ошибками, attachments, labels, историей и
+аналитикой.
+
+Allure не запускает тесты и не заменяет Playwright, Cypress, Jest, Vitest или другой test runner. Между test runner и
+Allure обычно работает adapter или reporter, который записывает результаты в понятном Allure формате.
+
+</td></tr></table>
+
+</details>
+
+<details>
+<summary>Как Allure Report работает от запуска тестов до готового отчета?</summary><br>
+<table><tr><td>
+
+Упрощенный процесс:
+
+1. Test runner запускает автотесты.
+2. Allure adapter получает события test runner: начало и завершение тестов, ошибки, steps, labels и attachments.
+3. Adapter записывает структурированные файлы в каталог `allure-results`.
+4. Allure CLI читает результаты и генерирует HTML-отчет, обычно в каталоге `allure-report`.
+5. Отчет открывают локально или публикуют как CI artifact либо статический сайт.
+
+Сбор результатов и генерация HTML-отчета — два отдельных этапа.
+
+</td></tr></table>
+
+</details>
+
+<details>
+<summary>Чем allure-results отличается от allure-report?</summary><br>
+<table><tr><td>
+
+`allure-results` содержит исходные данные, созданные adapter во время выполнения тестов: test result files, containers,
+attachments, environment и другие metadata.
+
+`allure-report` — готовый HTML-сайт, сгенерированный из этих результатов. Его можно открыть в браузере, сохранить как
+artifact или опубликовать на web server. Удаленный отчет можно сгенерировать заново, если сохранен `allure-results`.
 
 </td></tr></table>
 
@@ -335,7 +370,7 @@ cases, steps, attachments, history, duration, labels, severity, owners и trend
 - suite — группа тестов;
 - step — шаг внутри теста;
 - attachment — screenshot, trace, video, log, request или response;
-- label — feature, story, owner, severity, tag;
+- label — epic, feature, story, owner, severity, tag;
 - status — passed, failed, broken, skipped;
 - history — информация о предыдущих запусках.
 
@@ -345,20 +380,70 @@ cases, steps, attachments, history, duration, labels, severity, owners и trend
 
 </details>
 
+<details>
+<summary>Зачем нужны steps в Allure?</summary><br>
+<table><tr><td>
+
+Steps разбивают тест на понятные действия: открыть страницу, заполнить форму, отправить запрос, проверить результат. Они
+помогают увидеть, на каком этапе произошла ошибка и сколько времени занял каждый этап.
+
+Steps должны описывать бизнес-действия или значимые технические операции. Слишком мелкие steps создают шум, а один step
+на весь тест не помогает локализовать проблему.
+
+</td></tr></table>
+
+</details>
+
+<details>
+<summary>Что такое attachments в Allure и что стоит прикладывать к падению?</summary><br>
+<table><tr><td>
+
+Attachment — файл или данные, связанные с тестом либо step. Для E2E-теста полезно сохранять screenshot, video,
+Playwright trace, browser console logs и network logs. Для API-теста — request, response, headers и server logs. Для
+visual regression — actual, expected и diff images.
+
+Attachments должны помогать расследовать падение без повторного запуска. Нельзя публиковать access tokens, пароли,
+cookies, персональные данные и другие секреты: их нужно удалять или маскировать.
+
+</td></tr></table>
+
+</details>
+
 <details>
 <summary>Чем статус failed отличается от broken в Allure?</summary><br>
 <table><tr><td>
 
-Failed обычно означает, что проверка поведения не прошла: ожидали одно, получили другое. Broken чаще означает ошибку
-самого теста или инфраструктуры: exception в setup, некорректный selector, timeout окружения, ошибка fixture или
-неподнятый backend. Разделение помогает понять, это дефект продукта или проблема тестового слоя.
+`failed` обычно означает, что assertion не прошел или проверяемое поведение не соответствует ожиданию. `broken` чаще
+означает ошибку самого теста или инфраструктуры: exception в setup, ошибка fixture, timeout окружения или неподнятый
+backend.
+
+Точное преобразование ошибок в `failed` и `broken` зависит от конкретного adapter.
 
 </td></tr></table>
 
 </details>
 
 #### Middle
 
+<details>
+<summary>Как подключить Allure к Playwright, Cypress, Jest или Vitest?</summary><br>
+<table><tr><td>
+
+Общий принцип одинаковый:
+
+1. Установить совместимый с test runner Allure adapter или reporter.
+2. Подключить его в конфигурации test runner.
+3. Указать каталог для результатов.
+4. Запустить тесты и проверить, что появились result files и attachments.
+5. Сгенерировать или открыть отчет через Allure CLI.
+6. В CI сохранить результаты и готовый отчет как artifacts либо опубликовать отчет.
+
+Конкретные package names и options зависят от test runner и версии интеграции.
+
+</td></tr></table>
+
+</details>
+
 <details>
 <summary>Какие метрики смотреть в Allure?</summary><br>
 <table><tr><td>
@@ -372,11 +457,71 @@ Failed обычно означает, что проверка поведения
 - flaky tests и нестабильные suites;
 - самые медленные тесты;
 - падения по feature, story, owner, severity и tag;
-- история конкретного теста;
-- attachments: screenshots, videos, traces, logs, request и response.
+- история конкретного теста.
+
+Метрики нужны для решений: что чинить первым, где замедление и какие тесты перестали защищать продукт.
+
+</td></tr></table>
+
+</details>
+
+<details>
+<summary>Для чего нужны labels epic, feature, story, owner и severity?</summary><br>
+<table><tr><td>
+
+Labels позволяют искать, фильтровать и группировать тесты:
 
-Метрики нужны не для красивого dashboard, а для решений: что чинить первым, где замедление и какие тесты перестали
-защищать продукт.
+- `epic`, `feature`, `story` описывают продуктовую иерархию;
+- `owner` показывает ответственную команду или человека;
+- `severity` отражает критичность сценария;
+- `tag` добавляет классификацию, например `smoke`, `regression` или `payments`.
+
+Labels полезны, когда они стабильны и связаны с реальной структурой продукта.
+
+</td></tr></table>
+
+</details>
+
+<details>
+<summary>Как сохранить history и trends между CI-запусками?</summary><br>
+<table><tr><td>
+
+Для trends Allure должен получить history data предыдущего отчета при генерации следующего. Поэтому CI pipeline обычно:
+
+1. Загружает history предыдущего отчета или artifact.
+2. Добавляет эти данные к результатам нового запуска способом, который поддерживает используемая версия Allure.
+3. Генерирует новый отчет.
+4. Сохраняет новый отчет и его history для следующего запуска.
+
+Если CI job всегда начинается с чистого workspace и history не восстанавливается, отчет покажет только текущий запуск.
+
+</td></tr></table>
+
+</details>
+
+<details>
+<summary>Как Allure связывает retries и историю одного теста?</summary><br>
+<table><tr><td>
+
+Allure должен стабильно идентифицировать один и тот же test case между попытками и запусками. Обычно идентификатор
+зависит от framework, полного имени теста, параметров и metadata.
+
+Если постоянно менять title, suite или параметры, Allure может воспринимать тест как новый, и история разорвется. Retry
+может быть временным safety net, но не должен маскировать нестабильность теста.
+
+</td></tr></table>
+
+</details>
+
+<details>
+<summary>Как собрать единый Allure Report при parallel execution и sharding?</summary><br>
+<table><tr><td>
+
+Каждый worker или CI job генерирует свою часть Allure results. После выполнения shards результаты собирают в один
+каталог, а отчет генерируют один раз из объединенного набора.
+
+Обычно отдельный aggregate job скачивает artifacts всех shards, объединяет result files и запускает генератор. Важно не
+потерять attachments и не перезаписать файлы результатами другого worker.
 
 </td></tr></table>
 
@@ -400,8 +545,27 @@ Flaky test иногда проходит, а иногда падает без и
 
 Нужно воспроизвести падение, изучить trace, video, screenshot и logs, затем убрать недетерминизм. Помогают стабильные
 locators, явные ожидания состояния, изоляция данных, независимые тесты, test fixtures, mock network, отключение
-анимаций, контролируемые часы и отказ от произвольных sleep. Retry может быть временным safety net, но не заменой
-исправления.
+анимаций, контролируемые часы и отказ от произвольных sleep. Retry не заменяет исправление причины.
+
+</td></tr></table>
+
+</details>
+
+<details>
+<summary>Как расследовать падение теста по Allure Report?</summary><br>
+<table><tr><td>
+
+Полезный порядок:
+
+1. Проверить status, error message и stack trace.
+2. Найти последний успешный step.
+3. Открыть screenshot, trace, video и logs.
+4. Сравнить environment, параметры и test data.
+5. Посмотреть retries и историю теста.
+6. Проверить, падают ли соседние тесты по той же причине.
+7. Определить класс проблемы: product, test, data, environment или infrastructure.
+
+Allure собирает признаки в одном месте, но инженер все равно должен проверить гипотезу и локализовать причину.
 
 </td></tr></table>
 
@@ -419,6 +583,58 @@ thresholds, raw metrics и сравнение с baseline. Артефакты д
 
 </details>
 
+#### Middle+ or Senior
+
+<details>
+<summary>Чего Allure Report не заменяет?</summary><br>
+<table><tr><td>
+
+Allure Report не заменяет:
+
+- test runner и сами автотесты;
+- корректные assertions и test design;
+- CI/CD pipeline;
+- code coverage;
+- логи приложения и observability;
+- issue tracker и процесс triage;
+- test management систему, если команде нужны test plans и manual cases.
+
+Красивый отчет не исправляет flaky tests, слабые проверки или отсутствие важных сценариев.
+
+</td></tr></table>
+
+</details>
+
+<details>
+<summary>Можно ли использовать Allure как quality gate?</summary><br>
+<table><tr><td>
+
+Метрики отчета можно использовать как один из сигналов: количество failed и broken tests, pass rate, критичные сценарии,
+длительность или рост нестабильности. Но merge или release gate должен опираться на надежные machine-readable
+результаты, а не только на HTML-страницу.
+
+Нельзя автоматически блокировать релиз по любой нестабильной метрике без анализа причин: flaky tests и ошибки
+инфраструктуры могут остановить разработку.
+
+</td></tr></table>
+
+</details>
+
+<details>
+<summary>Какие риски безопасности есть при публикации Allure Report?</summary><br>
+<table><tr><td>
+
+Отчет и attachments могут содержать URL, headers, cookies, tokens, персональные данные, содержимое форм, screenshots
+внутренних систем и stack traces. Перед публикацией нужно маскировать секреты, ограничивать доступ и задавать срок
+хранения artifacts.
+
+Особенно внимательно нужно проверять automatic request/response attachments: они часто сохраняют больше данных, чем
+ожидает автор теста.
+
+</td></tr></table>
+
+</details>
+
 ### CI/CD and quality gates
 
 #### Middle

src/pages/react/index.md

@@ -1,7 +1,8 @@
 ---
 layout: ../../layouts/Layout.astro
 title: React
-description: React core, hooks, state, forms, data fetching, routing, ecosystem, отличия от Angular и практические задачи
+description:
+  React core, hooks, state, forms, data fetching, routing, ecosystem, отличия от Angular и практические задачи
 category: Frontend
 kind: questions
 order: 130