Test Design

Как написать тест-план: шаблон и реальные примеры

10 min readMay 2026

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

Что такое тест-план (и чем он не является)

Что это

Документ определяющий область охвата, подход и ресурсы для тестирования фичи или релиза. Способ коммуникации между QA, разработчиками и стейкхолдерами. Ориентир во время тестирования чтобы все знали что должно произойти.

Что это не

Не список тест-кейсов (это отдельный документ), не гарантия что баги не попадут в прод и не что-то требующее 40 страниц.

Одностраничный тест-план для небольшой фичи совершенно уместен. Цель: ясность, а не объём.

Основные разделы

1. Фича или система под тестированием

Что именно тестируем? Конкретно.

Расплывчато

Тестирование процесса чекаута

Конкретно

Тестирование чекаут-флоу для зарегистрированных пользователей: корзина → адрес доставки → оплата (Stripe) → подтверждение заказа. Исключены: гостевой чекаут (тестируется отдельно) и возвраты (ещё не реализованы).

2. Цели тестирования

Чего хотим достичь этим тестированием?

Пример

- Проверить что зарегистрированные пользователи могут совершить покупку физических товаров

- Убедиться что интеграция оплаты со Stripe работает корректно в сценариях успеха и отказа

- Подтвердить что письма с подтверждением заказа отправляются в течение 2 минут после покупки

- Проверить что остаток на складе корректно уменьшается после покупки

3. Область охвата

В области охвата

Регистрация и логин пользователей
Добавление товаров в корзину
Применение промокодов
Чекаут с банковской картой
Страница подтверждения заказа
Письмо с подтверждением заказа

Вне области охвата

Интеграция PayPal (Фаза 2)
Гостевой чекаут (отдельная фича)
Возвраты и рефанды
Мобильное приложение (отдельный тест-план)

Это самый важный раздел для тщательного написания. Расползание области охвата в тестировании так же реально как в разработке.

4. Подход к тестированию

Как будет выполняться тестирование?

| Тип | Подход | Кто |

|-----|--------|-----|

| Дымовое тестирование | Ручное, перед регрессией | QA-команда |

| Функциональное тестирование | Ручные тест-кейсы | QA-команда |

| API-тестирование | Автоматизированное Playwright | QA-автоматизация |

| E2E-регрессия | Автоматизированное Playwright | QA-автоматизация |

| Нагрузочное | k6 | DevOps |

| Исследовательское | 2-часовая сессия за спринт | QA-команда |

5. Тестовое окружение

Где будет проходить тестирование?

Окружение: Staging (https://staging.myapp.com)
Данные: Чистая staging-БД с тестовыми данными
Браузер: Chrome (основной), Firefox (регрессия)
Мобайл: iOS Safari через BrowserStack (только smoke)

API-ключи: Stripe test mode
Тестовая карта Stripe: 4242 4242 4242 4242
Карта отказа: 4000 0000 0000 0002

6. Тестовые данные

Какие данные должны существовать до начала тестирования?

Пользователи

3 зарегистрированных пользователя с разными ролями (admin, member, viewer)
1 пользователь с сохранённым способом оплаты
1 пользователь с просроченным способом оплаты
Граничный случай: пользователь с очень длинным именем (для тестирования усечения в форме)

Товары

Стандартный товар (в наличии)
Товар не в наличии
Товар с применённым промокодом
Цифровой товар (доставка не требуется)

Промокоды

SAVE10   - 10% скидка, активен
SAVE50   - 50% скидка, активен
EXPIRED99 - просрочен, не должен применяться

7. Оценка рисков

Какие области наиболее рискованные? Что может пойти не так?

|------|-------------|---------|-----------|

Чем выше риск, тем больше тестового покрытия нужно.

8. Критерии входа и выхода

Критерии входа

Тестирование можно начинать когда все фичи из области охвата задеплоены на staging, дымовые тесты проходят, тестовые данные подготовлены и API-документация актуальна.

Критерии выхода

Тестирование завершено когда все высокоприоритетные тест-кейсы пройдены, нет открытых P1 или P2 багов, нагрузочные тесты пройдены (загрузка страницы < 2 с) и регрессионный набор проходит.

9. Расписание тестирования

|------------|--------|-------|-----|

10. Управление дефектами

Как будут отслеживаться баги?

Инструмент: Jira
Проект: CHECKOUT
Метки приоритета: P1 (блокер), P2 (критичный), P3 (минорный), P4 (косметический)

P1 блокеры: стоп, исправлять немедленно
P2 критичные: исправить до релиза
P3 минорные: исправить в следующем спринте если возможно
P4 косметические: добавить в бэклог

Шаблон баг-репорта:
- Окружение
- Шаги воспроизведения (пронумерованные)
- Ожидаемый результат
- Фактический результат
- Скриншот/видео
- Браузер/ОС

11. Роли и ответственность

| Человек | Роль |

|---------|------|

| Анна Смит | QA Lead: общий план, финальное подписание |

| Боб Джонс | QA-инженер: написание тест-кейсов, ручное тестирование |

| Кэрол By | QA-автоматизация: скрипты Playwright |

| Дейв Ким | Разработчик: фиксы багов, технические вопросы |

| Ева Браун | Продакт-менеджер: требования, критерии приёмки |

Полный мини тест-план

Вот как выглядит реальный тест-план для небольшой фичи: редактирование профиля пользователя.

Тест-план: Редактирование профиля пользователя

Версия 1.0 | Автор: QA-команда | Дата: 2026-01-15 Фича: Пользователи могут редактировать отображаемое имя и аватар на странице профиля.

Область охвата

В области: смена имени, загрузка аватара (JPEG/PNG, максимум 5 МБ), валидация имени. Вне области: смена email (требует верификации, отдельный план) и смена пароля.

Подход к тестированию

Ручное функциональное тестирование хэппи-паса и граничных случаев, API-тестирование эндпоинта PUT /api/users/{id}, а также автоматизированная регрессия для критических флоу.

Окружение: Staging с тестовыми аккаунтами

Нужные тестовые данные

Аккаунт с существующим аватаром, аккаунт без аватара и тестовые изображения: валидный JPEG (2 МБ), валидный PNG (4 МБ), превышающий лимит (10 МБ), невалидный формат (PDF).

Риски

Ограничение размера файла может проверяться только на клиенте: нужно тестировать и серверную сторону. Хранилище аватаров (S3): нужно проверить что происходит при ошибке загрузки.

Критерии выхода: все P1/P2 баги закрыты, имя и аватар обновляются корректно для всех тест-кейсов, регрессионный набор зелёный

Вот и всё. Хороший тест-план умещается на одной странице.

Частые ошибки

Слишком расплывчато: «Мы будем тестировать фичу логина.» Как именно? Во всех браузерах? Для всех ролей пользователей? Только API? Только UI? Слишком длинно: 20-страничный документ который никто не читает ничего не коммуницирует. Если стейкхолдеры не читают, он бесполезен. Нет раздела области охвата: без явных пунктов «вне области охвата» каждый стейкхолдер считает что его вещи покрыты. Нет оценки рисков: потратишь одинаковое время на низкорисковые и высокорисковые области вместо приоритизации. Нет критериев выхода: как понять что закончил? «Когда закончилось время» не критерий выхода.

Что охватывает тест-план

1. Что тестируется (и что нет)

2. Как будет тестироваться (вручную, автоматически, исследовательски)

3. Где происходит тестирование (окружения)

4. Какие данные нужны

5. Какие риски существуют и как их снизить

6. Когда тестирование начинается и заканчивается (критерии входа и выхода)

7. Кто за что отвечает

All articles