Allure и QA Деск — отчёт становится прогоном с историей, а не артефактом сборки

Отчёт и деск решают разные задачи

Allure отвечает на вопрос «что случилось в этом прогоне» и делает это хорошо: шаги, вложения, разбивка по фичам. Чего у него нет — жизни после сборки. Через неделю ссылка на артефакт протухла, история «этот сценарий падает третий спринт» не собирается, ручные проверки в отчёте не отражены вовсе, а дефект всё равно заводится руками в другом месте.

QA Деск не заменяет Allure и не пытается: пусть команда смотрит подробности там, где привыкла. В деск уезжает результат, чтобы у него появились история, покрытие и дефекты.

Приём

# pytest, JS-раннеры, Vanessa Automation — всё пишет allure-results
pytest --alluredir=allure-results
QADESK_TOKEN=qdit_… qadesk-cli upload --run "regress" --env stage ./allure-results

Утилита сама узнаёт формат по наличию файлов *-result.json. Без утилиты — тот же приём одним запросом:

curl -H "Authorization: Bearer $QADESK_TOKEN" \
     --data-binary @results.ndjson \
     "https://api.qadesk.ru/ingest/v1/allure?name=regress&environment=stage&ciRunId=$CI_PIPELINE_ID"

Токен приёма выпускается на проект (qdit_…), показывается один раз и отзывается в кабинете.

Ключ кейса

Источники в порядке приоритета: label qadesk_case, затем fullName, затем name.

import allure

@allure.label("qadesk_case", "QAD-C18")
def test_checkout_with_expired_card():
    ...

// allure-playwright
allure.label('qadesk_case', 'QAD-C18');

Результаты без ключа не записываются и печатаются поимённо с причиной. Список несматченных — это не ошибка приёма, а честная карта того, где разметка ещё не проставлена.

Статусы: почему broken не зелёный

Статус Allure	В прогоне
`passed`	пройдено
`failed`	упало
`broken`	упало
`unknown`	упало
`skipped`	пропущено

broken означает, что тест не смог доехать до проверки — упал на подготовке, на селекторе, на таймауте. Считать это «не падением» удобно ровно до первого релиза, где половина сценариев отвалилась на авторизации, а дашборд остался зелёным. Поэтому же при повторе одного кейса в отчёте побеждает худший исход: ретрай, прошедший со второго раза, не красит прогон.

Идемпотентность и шарды

Приём идемпотентен по паре «прогон CI + попытка»: перезапуск задания не создаёт второй прогон. Если один пайплайн шардит тесты, дайте каждому шарду свой --attempt или свой --ci-run-id — иначе одинаковый ключ с другим содержимым получит отказ 409 вместо тихой перезаписи.

Ручное и автоматическое в одном покрытии

Главное, ради чего отчёт вообще куда-то уезжает: сценарий Allure и ручной тест-кейс с тем же ключом занимают одну строку покрытия. Пока автотестов десять, разница незаметна; когда их триста, а ручных проверок сто пятьдесят, вопрос «что реально проверено перед релизом» без общей таблицы не имеет ответа.

Отсюда же берётся история: видно, что сценарий падал в трёх последних прогонах, а не только в текущем, и что дефект по нему уже заведён и лежит в работе. Прогон хранит окружение, платформу и сборку, поэтому «упало на стейдже на сборке 412» — это фильтр, а не строчка в чате.

Вместо allurectl

Отдельного сервера отчётов ставить не нужно: приём — это HTTP-ручка и один статический бинарник, которому не нужны ни Java, ни Node в раннере. Прогон появляется сразу в проекте, где лежат ручные кейсы, дефекты и метрики.

Чего в продукте нет

нет переноса вложений Allure (скриншоты, видео, логи шагов): они остаются артефактами сборки;
нет дерева фич и разбивки по эпикам из Allure — структура в деске своя: проект, план, прогон;
нет автозаведения дефектов по упавшим результатам.

С чего начать

Выпустите токен приёма на проект.
Добавьте шаг qadesk-cli upload ./allure-results с when: always.
Проставьте label qadesk_case у сценариев, которые дублируют ручные кейсы, — именно они дают экономию.
Сравните первый прогон с отчётом Allure: числа должны совпасть, кроме несматченных, — их список утилита печатает явно.

Попробуйте на своём проекте

Заведите проект, загрузите первый отчёт или заведите первый дефект — бесплатный тариф без карты. Нужно демо на ваших сценариях — напишите на hello@qadesk.ru.

Создать проект

Рядом по теме

Платформы

Django

pytest отдаёт отчёт в JUnit XML или Allure, а QA Деск превращает его в прогон с ключами кейсов, где рядом лежат ручные проверки админки, интеграций и миграций.

Django — pytest в пайплайне, покрытие в деске

Автотесты, CI и мониторинг

Playwright

Playwright пишет отчёт, QA Деск делает из него прогон: ключ кейса связывает автотест с ручной проверкой, повтор задания не плодит дубли, а упавший сценарий превращается в дефект.

Playwright — сценарии в браузере, результат в покрытии