Тест-план
Тема дорожной карты · QA-инженер
Тест-план — это формальный документ, определяющий область охвата, цели, подход, ресурсы, расписание и критерии выхода для всех тестировочных активностей программного проекта, служащий основным контрактом между QA-командой и стейкхолдерами проекта. Хорошо структурированный тест-план фиксирует, какие уровни тестирования (юнит, интеграционный, системный, приёмочный) и типы тестирования (функциональное, регрессионное, нагрузочное, безопасности) будут выполняться, указывает используемые инструменты — Selenium, Playwright, JMeter, Postman, OWASP ZAP — и задаёт, как результаты будут представляться через Allure, TestRail или Zephyr. Тест-план также определяет конфигурацию тестовой среды (включая Docker-среды, подготавливаемые через CI/CD), критерии входа и выхода, факторы риска, влияющие на STLC, и ответственность каждого участника команды. В Agile-проектах тест-план может быть «живым» документом, обновляемым каждый спринт, тогда как в традиционных SDLC-моделях это базовый артефакт, проверяемый и согласуемый перед началом выполнения тестирования.
Как это работает
Тест-план включает тест-планы (высокоуровневый scope, расписание, ресурсы), тест-кейсы (предусловия, шаги, ожидаемый результат), test charters (для exploratory-сессий), баг-репорты (шаги воспроизведения, severity, priority, окружение), test reports (executed, passed, failed, blocked). Современные тулы: TestRail, Xray, Zephyr, qase.io или markdown + git для engineering-driven команд. Баг-репорт — самый важный артефакт: расплывчатый репорт = баг, который не исправят.
Когда применять
Пишите баг-репорты так, будто автор больше недоступен — title, шаги, ожидаемое vs фактическое, окружение, скриншот/видео, severity. Тест-кейсы — короткие; длинные списки шагов никто не читает. Для exploratory-сессий — charter с целью + timebox (60-90 мин); резюме после. Регрессионные тест-кейсы поддерживайте, только если их гоняют; неисполняемая документация — это долг.
Типичные ошибки
Ловушки Тест-план: баг-репорт с title "не работает" (никто не может действовать); тест-кейсы — пошаговые рецепты того, что 5 unit-тестов сделали бы быстрее; tracking-тулы, которые никто не обновляет (documentation-театр); over-документирование тривиальных фич при undertest критичных флоу.