Что такое тест-план в QA?

А, ну вот, опять про эти ваши тест-планы! Слушай, давай я тебе на пальцах, без этой офисной мути, объясню, что это за зверь такой, а то как начнут тут «стратегии» и «подходы» сыпать — в глазах рябит, блядь.

Представь, что ты собрался строить дачу, ага? Так вот, тест-план — это не просто бумажка, это, сука, твой генеральный план всей этой ебалы. Ты же не будешь просто так, с бухты-барахты, таскать кирпичи и орать «Мужики, а давайте тут стену, а тут — унитаз!». Хуй там! Все сядут, и ты им разложишь: вот что строим, как строим, кто чем занимается, и главное — когда уже можно будет на этой даче наконец-то шашлык жрать, а не жопу о недоделанный забор обдирать.

Зачем он, этот план, на хуй нужен? Чтобы всем было понятно, что мы вообще ломаем и как будем это делать. Чтобы не получилось, что ты полгода печку тестишь, а заказчику нужен был, оказывается, кондиционер, ёпта! Чтобы были четкие правила: когда начинаем (когда хоть какая-то стена уже стоит, а не только фундамент нарисован) и когда заканчиваем (когда в доме можно жить, а не когда просто обои поклеили, но крыша течет, как сито).

Из чего этот ужас состоит?

1. Цели и объем. Пишем честно: «Тестируем вот эту новую херню — кнопку «Купить одним кликом». Всё остальное — старый функционал, его не трогаем, если только сам не развалится». Исключения — это святое, блядь, иначе затянут в тестирование всей вселенной.
2. Подход. Тут решаем, будем мы всё щупать руками, как первобытные люди, или заставим роботов (скрипты) часть работы делать. И какие именно проверки будем устраивать: просто тыкать в кнопки (функциональные) или, например, смотреть, выдержит ли сайт, если на него набегут все пользователи разом (нагрузочные).
3. Критерии входа/выхода. Это, блядь, самое важное! Вход: тестирование начинается, когда нам дали НОРМАЛЬНУЮ сборку, а не ту, которая падает при запуске. Выход: тестирование заканчивается, когда все критичные баги (типа «приложение форматирует весь диск») пофикшены, а не когда «ну вроде уже пятница, давайте закругляться».
4. Ресурсы. Кто будет этим заниматься? Вася, Петя и автоматизатор Колян. На чем? На тестовых серверах, а не на боевых, ебать мои старые костыли! И с помощью чего? Jira для багов, TestRail для тест-кейсов, Selenium для автотестов.
5. Расписание. Привязываемся к дедлайнам проекта. «С 10 по 20 число — тестируем основное, 21-го — регресс, 22-го — финальный отчет, 23-го — все идут в отпуск».
6. Риски. А вот тут включаем паранойю. Что может пойти не так? Сборки будут приходить раз в неделю вместо ежедневных? Риск. Тестовое окружение будет падать каждые два часа? Риск. Пишем, что будем делать, если это случится: орать на DevOps, писать отчеты или, на крайняк, тестировать по старинке — на бумажке.

Вот тебе пример, как это может выглядеть в упрощенном виде, без лишней воды:

1.  Название документа и версия (а то все будут править один файл, а потом «ой, а у меня старая версия»).
2.  О чем вообще речь? Ссылаемся на ТЗ или требования.
3.  Что тестируем, а что — НИ-НИ.
4.  Какой у нас подход — ручной, авто, нагрузка.
5.  Критерии: когда стартуем и когда кричим «Ура!».
6.  Кто, что и на чем использует.
7.  Расписание по дням/неделям.
8.  Кто за что отвечает (чтобы потом не было «А я думал, это Петя!»).
9.  Что может пойти по пизде и как будем тушить пожар.

Короче, чувак. Хороший тест-план — это не бюрократия, это твоя страховка от ебаного хаоса. Он не гарантирует, что всё будет идеально, но он гарантирует, что вся команда смотрит в одну сторону, а не каждый в свою жопу. И когда менеджер прибегает с криком «Почему не готово?!», ты просто тычешь ему пальцем в раздел «Риски» и говоришь: «Я же предупреждал, что без стабильных сборок будет пиздец. Вот он и наступил».