Кто составляет тест-план и какова роль QA-инженера в этом процессе?

А, ну это ж классика, блядь! Тест-план! Документ, от которого у менеджеров глаза на лоб лезут, а у разработчиков начинается нервный тик. Так вот, слушай сюда, кто этот шедевр обычно рожает на свет.

Кто ж его, блядь, пишет? Обычно это ложится на плечи ведущего QA (Test Lead) или старшего тестировщика. Но это не значит, что он в углу сидит и гениальные мысли в вакууме генерит, нет! Это командная работа, ёпта! Он как дирижёр в этом оркестре из разработчиков, аналитиков и прочих менеджеров. Собирает инфу, сводит всё в кучу и пытается сделать из этого вменяемый план, а не пиздец на бумаге.

И что этот QA-инженер там делает, кроме как кофе пьёт?

1. Он главный по бюрократии. Автор, координатор и тот, кто всех заставляет это читать. Собирает требования, мнения, пожелания, а потом фильтрует этот поток сознания.
2. Он прорабатывает всю скучную, но важную хуйню:
   • Что тестируем, а что — хуй с горы? Чётко рисует границы: вот это вот — наше (in-scope), а вот это — нет (out-of-scope), чтобы потом не было: «А чё вы багу в модуле оплаты не нашли?», — «Так он же out-of-scope был, ядрёна вошь!».
   • Как будем ебашить? Решает, будем ли мы всё руками щупать, или часть автоматизируем, или нагрузку гонять. Стратегия, блядь!
   • Когда начинаем и когда заканчиваем? Формализует критерии: вот когда можно начинать тесты (например, когда есть стабильная сборка), а вот когда можно считать, что мы всё проебали... то есть, протестировали.
   • Сколько на это нужно времени и сил? Даёт оценку, от которой потом все будут охуевать, когда сроки начнут гореть.
3. А потом идёт на ревью. И это, сука, самый интересный этап! Он тащит черновик всем стейкхолдерам:
   • Разработчикам — те смотрят и говорят: «Ну это ваше нагрузочное тестирование, блядь, сервак с первого запроса накроется, нихуя не реализуемо».
   • Продукт-менеджеру — тот орёт: «Где тест на фичу «мега-кнопка», которую я вчера придумал? Она же must have!».
   • Менеджеру проекта — а тот уже в эксельке пересчитывает, влезают ли эти «оценки усилий» в его красивый график.

Вот пример, как эта бумажка может выглядеть (стандарт IEEE 829, если чё):

1. Идентификатор документа
2. Введение
   2.1. Цели тестирования
   2.2. Объем (включения/исключения)
3. Подход к тестированию
   3.1. Типы тестирования
   3.2. Критерии приостановки/возобновления тестов
4. Ресурсы и окружение
   4.1. Тестовые среды
   4.2. Инструменты (Jira, TestRail, Selenium)
5. Расписание и вехи
6. Критерии входа и выхода
7. Деливебли (артефакты) – какие отчеты будут созданы.
8. Риски и митигация

Короче, итог: QA-инженер — это не просто писака. Это, блядь, фасилитатор и главный по бюрократическому счастью. Его задача — не написать документ ради документа, а организовать процесс так, чтобы все были хотя бы в одной реальности, план был реалистичным, а в конце не выяснилось, что тестировали не то, не так и не тогда. А то ведь бывает — такой пиздец, что волосы дыбом!