Тестирование Django-проектов — pytest и Allure в QA Деск, кейсы и дефекты рядом с прогонами

Что обычно болит

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

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

Что даёт QA Деск

Результат живёт дольше артефакта. Прогон остаётся в проекте: видно, что падало на прошлой неделе, что чинилось, какой сборкой.

Ручное и автоматическое в одном покрытии. Кейс на проверку миграции руками и автотест на ту же логику — одна строка, если у автотеста стоит ключ кейса.

Дефект из упавшего шага. Заводится из прогона: шаги и наблюдение переносятся, окружение и сборка заполняются полями, а не текстом.

Allure-статусы не зеленят прогон. broken и unknown считаются падением; повторяющийся кейс в отчёте берёт худший исход. Это принципиально: отчёт, который сам себя красит зелёным, бесполезен.

Рецепт: pytest → QA Деск

Два формата на выбор — что уже есть в проекте.

# JUnit XML — ничего доустанавливать не нужно
pytest --junitxml=reports/junit.xml

# или Allure, если он уже принят в команде
pytest --alluredir=allure-results

Шаг выгрузки один и тот же:

QADESK_TOKEN=qdit_… qadesk-cli upload --run "django regress" --env test ./reports

Утилита сама определит формат: если в каталоге лежат *-result.json, это Allure, иначе JUnit по *.xml. Несколько файлов (например, шарды pytest-xdist) склеиваются в один отчёт.

Ключ кейса в тесте

import allure

@allure.label("qadesk_case", "QAD-C31")
def test_password_reset_link_is_single_use(client, user):
    ...

# без Allure — ключ прямо в имени теста
def test_QAD_C31_password_reset_link_is_single_use(client, user):
    ...

Приоритет источников: явная разметка (property qadesk.case для JUnit, label qadesk_case для Allure), затем полное имя теста, затем имя. Регистр нормализуется, ключ дефекта (QAD-31) с ключом кейса (QAD-C31) не путается — они не пересекаются по построению.

Что стоит завести кейсами, а не тестами

Есть часть Django-проекта, которую дешевле проверять руками по чек-листу, чем автоматизировать:

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

Эти проверки живут тест-планом, а прогон по нему показывает, кто и когда их сделал. В сумме с автотестами получается ответ на вопрос «релизить или нет», который не зависит от того, кто сегодня дежурит.

Браузерные проверки

Playwright для Python пишет тот же JUnit XML через pytest, поэтому отдельного пути для e2e нет — он приезжает вместе с остальными. Подробнее — Playwright.

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

нет плагина для pytest: разметка делается стандартными средствами, а выгрузка — одним шагом, чтобы не тянуть зависимость в ваш requirements.txt;
QA Деск не собирает покрытие кода (coverage) — это другой инструмент и другая метрика;
нет автоматического заведения дефектов по упавшим тестам: решение принимает человек.

С чего начать

Заведите проект и выпустите токен приёма: Настройки → Интеграции → CI / автотесты.
Добавьте --junitxml или --alluredir в команду тестов и шаг qadesk-cli upload в пайплайн.
Возьмите кейсы регистрации и авторизации и проставьте ключи у соответствующих автотестов.
Заведите отдельный тест-план «релиз с миграциями» — именно он объясняет заказчику, почему выкатка занимает не пятнадцать минут.

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

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

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

Рядом по теме

Платформы

Laravel

Отчёт PHPUnit или Pest уезжает в QA Деск одним шагом пайплайна и превращается в прогон, где автотесты лежат в одной таблице с ручными проверками, а не в отдельной вкладке CI.

Laravel — отчёт Pest или PHPUnit становится прогоном

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

Playwright

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

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