Что такое тест-план в разработке ПО?

Да ты послушай, что за документ такой интересный — тест-план! Это ж, блядь, не просто бумажка, а целая стратегическая карта, на которой отмечено, где мы будем воевать с багами, а где — отдыхать. По сути, это такой развёрнутый план захвата, только вместо крепости — твой софт, а вместо солдат — тестировщики с голодными глазами.

Итак, из чего же эта хитро-жопа состоит:

1. Зачем мы здесь собрались?

   • Тут расписываем, нахуя вообще всё это затеяли и какие конкретно модули или функции будем мучать. Чтобы потом не было: «А мы думали, вы это тестите!».

2. Что трогаем, а что — руки прочь!

   • ВКЛЮЧЕНО: Вот это вот — наше, будем щупать, ломать и смотреть, как дышит. Функционалка, интеграции, нагрузка — всё по списку.
   • ИСКЛЮЧЕНО: А это — святое, не тронь, иначе будет больно. Например, легаси-система, которая упадёт, если на неё чихнуть, или новая фича, которую ещё в код не залили. Пишем честно, чтобы менеджмент не ждал чудес.

3. Как будем издеваться? (Стратегия)

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

4. Чем и кем будем делать?

   • Команда: Кто ручной маньяк, кто автотестами управляет, а кто баги в трекере хоронит.
   • Окружение: На каких серваках, браузерах и телефонах будем танцевать. «У меня на маке работает!» — это не аргумент, блядь.
   • Инструменты: Чем будем бить: TestRail для кейсов, Jira для багов, Selenium для автоматизации — весь этот арсенал.

5. Когда всё это будет?

   • Расписание, привязанное к спринтам или релизам. Оценка трудозатрат, чтобы потом не вышло, что на двухнедельный тест-plan отвели три дня. Ёпта, волнение ебать!

6. Когда скажем «Всё, готово»?

   • Метрики качества: например, 95% покрытие требований и ноль критических багов. Отчёты, чтобы все понимали, тонем мы или уже почти приплыли.

7. Что может пойти не так? (Риски)

   • Тут включаем параноика: а если среда упадёт? А если разработка опоздает? А если, хуй с горы, половина команды на больничный уйдёт? План по смягчению: что будем делать, если этот пиздец всё-таки случится.

Вот смотри, кусок плана для модуля оплаты, чтоб понятнее было:

Цель: Проверить, чтобы деньги не улетали в никуда в релизе v2.1.
Что трогаем (In-Scope):
    - Форма оплаты (карта, PayPal) — чтобы кнопки жались.
    - API платежного шлюза — чтобы деньги действительно уходили куда надо.
    - Расчёт комиссий — чтобы с нас не содрали лишнего.
Что не трогаем (Out-of-Scope):
    - Интеграция с 1С (это на потом, в v2.2).
    - Мобильное приложение (этим другие ребята занимаются, им тоже не сладко).
Критерии начала: Есть сборка, которая не разваливается при запуске, и есть список, что проверять.
Критерии окончания: Все баги, из-за которых нельзя платить, — пофикшены. Дымовые тесты проходят, и мы не видим пламени.

Главное помни: тест-план — он живой, сука. Как трепетная лань. Требования поменялись, сроки съехали, риски материализовались — план надо обновлять, а не класть на него болт. Иначе получится классика: «А мы по плану от прошлого квартала работали». Пиздец и развод руководства, вот что получится.