Как составить тест-план: определяем объём, цели и стратегию тестирования проекта

Зачем это нужно?

Представьте, что вы собираетесь в длительное путешествие. Можно, конечно, просто сесть в машину и ехать куда глаза глядят — но скорее всего вы заранее составите маршрут: куда едете, что возьмёте с собой, сколько времени займёт поездка и что делать, если что-то пойдёт не так.

Тест-план — это именно такой «маршрут» для тестирования. Это документ, в котором команда договаривается заранее: что будем проверять, зачем, как, кто это делает и когда считаем работу законченной.

Без тест-плана тестировщики рискуют проверить одно и то же по несколько раз, пропустить важные части приложения или не успеть закончить работу в срок. С тест-планом — работа становится предсказуемой и управляемой.

На этом уроке вы узнаете, из каких частей состоит тест-план, как его написать с нуля и увидите готовый пример для учебного проекта.

Теория

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

Тест-план (от англ. test plan — план тестирования) — это документ, который описывает всё, что нужно знать команде перед началом тестирования. Он отвечает на шесть ключевых вопросов:

💡 Аналогия для понимания. Тест-план — как техническое задание для строителя. Прежде чем начать строить дом, нужно понять: что строим (дом или гараж?), из каких материалов, сколько комнат, кто за что отвечает и к какому сроку. Без этого строители будут делать каждый своё.

Из каких разделов состоит тест-план?

Тест-план не имеет единого жёсткого стандарта — каждая компания может оформлять его по-своему. Но есть классические разделы, которые встречаются почти везде. Рассмотрим каждый из них.

1. Введение и краткое описание проекта

Здесь вы объясняете, что за приложение тестируется и зачем вообще нужно тестирование в данном случае.

Что написать:

• Название приложения
• Что оно делает (2–3 предложения для человека, который видит его впервые)
• Версия приложения (если есть)

Пример:

Тестируется учебное веб-приложение «To-Do List» (список задач). Приложение позволяет пользователю добавлять, редактировать, отмечать выполненными и удалять задачи. Версия: 1.0 (учебная).

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

Цель тестирования — это конкретный результат, который вы хотите получить после проверки. Цели должны быть чёткими и измеримыми.

❌ Плохая цель: «Убедиться, что всё работает»
✅ Хорошая цель: «Проверить, что пользователь может создать, отредактировать и удалить задачу без ошибок»

Типичные цели тестирования:

• Убедиться, что основные функции работают корректно
• Найти баги до того, как приложение увидят реальные пользователи
• Убедиться, что после внесения изменений ничего не сломалось
• Проверить поведение приложения при некорректных данных (например, пустое поле или слишком длинный текст)

3. Объём тестирования

Объём тестирования (англ. scope — «охват») — это список того, что будем и что не будем проверять. Это очень важный раздел, потому что ресурсы всегда ограничены: время, люди, деньги.

Объём делится на две части:

«В области тестирования» (In scope) — что проверяем:

Функция добавления задачи, функция удаления задачи, отображение списка задач, работа на браузере Google Chrome.

«Вне области тестирования» (Out of scope) — что не проверяем и почему:

Мобильная версия приложения (не реализована в данной версии). Работа в браузере Internet Explorer (устаревший, компания его не поддерживает).

💡 Почему важно явно указывать, что НЕ проверяем? Чтобы потом не было претензий: «А почему вы не протестировали это?» Если это написано в тест-плане и все с ним согласились — ответственность распределена честно.

4. Виды тестирования

Вид тестирования — это угол зрения, под которым мы смотрим на приложение. Разные виды помогают найти разные проблемы.

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

💡 Регрессия — от лат. regressio («возвращение назад»). Регрессионное тестирование проверяет, что исправление одной проблемы не вернуло старые или не создало новые. Как ремонт в квартире: починили кран на кухне — не потёк ли при этом в ванной?

5. Стратегия тестирования

Стратегия тестирования описывает, как именно мы будем проводить проверки: вручную или с помощью автоматизации, в каком порядке, на каком окружении.

Ручное тестирование — тестировщик сам кликает, вводит данные и смотрит на результат. Как дегустатор на кухне ресторана.

Автоматизированное тестирование — компьютерная программа выполняет проверки вместо человека по заранее написанному сценарию. Как робот-сборщик на заводе.

Что описать в стратегии:

• Какие тесты будут ручными, а какие — автоматизированными
• В каком браузере и на какой операционной системе будем тестировать (тестовое окружение)
• В каком порядке будем тестировать (сначала — основные функции, потом — граничные случаи)

Пример описания стратегии:

Основные функциональные проверки выполняются вручную. Проверка добавления задачи автоматизируется с помощью Playwright. Тестирование проводится в браузере Google Chrome версии 124 на операционной системе Windows 11.

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

Это раздел, который часто забывают новички, но он очень важен.

Критерии входа (англ. entry criteria) — условия, при которых тестирование можно начинать.

Примеры:

• Приложение развёрнуто и доступно по ссылке
• Тест-кейсы написаны и согласованы
• Тестовая среда настроена

Критерии выхода (англ. exit criteria) — условия, при которых тестирование считается завершённым.

Примеры:

• Выполнены все запланированные тест-кейсы
• Все критические баги исправлены и повторно проверены
• Не найдено новых критических дефектов за последние 48 часов

💡 Аналогия. Критерий входа — это как осмотр машины перед поездкой (все ли шины накачены? достаточно ли бензина?). Критерий выхода — как финишная черта на гонке: когда её пересекаешь, соревнование закончено.

7. Риски и план действий при рисках

Риск — это то, что может помешать тестированию или снизить его качество.

Примеры рисков и реакции на них:

8. Ответственные и роли

Даже в маленькой команде (или учебном проекте) полезно записать, кто за что отвечает.

Пример:

Как объём, цели и стратегия связаны между собой?

Представьте треугольник:

        ЦЕЛИ
       /     \
ОБЪЁМ —————— СТРАТЕГИЯ

• Цели говорят нам, зачем мы тестируем (что хотим доказать или найти).
• Объём говорит, что именно мы проверяем (и что оставляем за скобками).
• Стратегия говорит, как мы это делаем (инструменты, порядок, методы).

Если цели размыты — непонятно, когда можно остановиться.
Если объём не определён — тестирование расползается и занимает вечность.
Если нет стратегии — каждый делает по-своему и результаты несравнимы.

Пример: тест-план для учебного приложения «To-Do List»

Ниже — готовый тест-план для учебного проекта. Он намеренно сделан коротким и понятным, чтобы вы могли использовать его как шаблон.

# Тест-план: приложение «To-Do List» v1.0

## 1. Введение
Тестируется учебное веб-приложение «To-Do List» — список дел.
Пользователь может добавлять, редактировать, отмечать выполненными
и удалять задачи. Приложение доступно по адресу: http://localhost:3000

## 2. Цели тестирования
- Убедиться, что пользователь может добавить новую задачу.
- Убедиться, что пользователь может удалить задачу.
- Убедиться, что нельзя добавить пустую задачу.
- Убедиться, что список задач корректно отображается.

## 3. Объём тестирования

### В области тестирования (In scope):
- Добавление задачи
- Удаление задачи
- Отметка задачи как выполненной
- Отображение списка задач
- Негативный сценарий: попытка добавить пустую задачу

### Вне области тестирования (Out of scope):
- Мобильная версия (не реализована)
- Тестирование производительности (вне рамок учебного проекта)
- Браузеры, кроме Google Chrome

## 4. Виды тестирования
- Функциональное тестирование
- Негативное тестирование
- Тестирование граничных значений
- Тестирование пользовательского интерфейса (UI)

## 5. Стратегия тестирования
- Ручное тестирование: все функциональные и негативные сценарии.
- Автоматизированное тестирование (Playwright): сценарий добавления
  задачи.
- Окружение: Google Chrome 124, Windows 11, разрешение 1920×1080.
- Порядок: сначала позитивные сценарии, затем негативные,
  затем граничные значения.

## 6. Критерии входа
- Приложение запущено и доступно по локальному адресу.
- Тест-кейсы написаны.

## 7. Критерии выхода
- Выполнены все тест-кейсы из плана.
- Все найденные баги задокументированы.
- Критических багов (блокирующих основные функции) не осталось.

## 8. Риски
| Риск                            | Действие                              |
|---------------------------------|---------------------------------------|
| Приложение не запускается       | Сообщить куратору, устранить причину  |
| Недостаточно времени            | Сократить объём до ключевых функций   |

## 9. Ответственные
- Написание тест-кейсов: учащийся (я)
- Проведение ручного тестирования: учащийся (я)
- Запуск автотестов: учащийся (я)

💡 Обратите внимание: это учебный тест-план. В реальных проектах он может быть длиннее (10–30 страниц), содержать ссылки на требования, список тест-кейсов и многое другое. Но структура остаётся той же.

Практика

Упражнение 1. Найдите ошибки в целях тестирования

Прочитайте список целей и определите, какие из них написаны правильно, а какие — нет. Для «плохих» целей напишите исправленную версию.

1. «Проверить, что приложение работает нормально»
2. «Убедиться, что пользователь может зарегистрироваться, введя корректный email и пароль»
3. «Всё должно быть хорошо»
4. «Проверить, что при попытке войти с неверным паролем появляется сообщение об ошибке»
5. «Протестировать сайт»

Подсказка: хорошая цель конкретна — из неё понятно, какое действие совершает пользователь и какой результат ожидается.

Упражнение 2. Заполните раздел «Объём тестирования»

Вы тестируете учебное приложение — форму регистрации пользователя. В форме есть поля: «Имя», «Email», «Пароль», «Повторите пароль» и кнопка «Зарегистрироваться».

Заполните таблицу:

Придумайте минимум по 3 пункта в каждой категории.

Подсказка для «Out of scope»: подумайте, что вы не можете проверить — например, как форма выглядит на старых телефонах, если у вас нет старого телефона.

Упражнение 3. Напишите мини-тест-план

Возьмите любое простое приложение или сайт, которым вы пользуетесь каждый день (например, калькулятор на телефоне, форма поиска в браузере или любой учебный сайт). Напишите тест-план по шаблону из этого урока.

Ваш тест-план должен содержать:

• Введение (2–3 предложения)
• Минимум 3 конкретные цели тестирования
• Объём (In scope / Out of scope)
• Хотя бы 2 вида тестирования
• Стратегию (ручное или автоматизированное, в каком браузере/устройстве)
• Критерии входа и выхода

Совет: не нужно писать идеально. Главное — пройти через все разделы и понять, о чём думать перед началом тестирования.

Упражнение 4 (повышенная сложность). Определите риски

Для тест-плана из Упражнения 3 придумайте 3 реальных риска, которые могут помешать тестированию. Для каждого риска опишите последствие и ваш план действий.

Используйте формат:

Пример начала: Риск: «Сайт может быть недоступен в день тестирования». Последствие: «Не смогу выполнить ни один тест-кейс». Что делаю: «Планирую запасной день для тестирования».

Ключевые выводы

• Тест-план — это документ-договорённость: что, зачем, как, кто и когда тестирует.
• Хороший тест-план отвечает на шесть вопросов: что, зачем, сколько, как, кто, когда.
• Цели должны быть конкретными и измеримыми — не «всё должно работать», а «пользователь может добавить задачу и увидеть её в списке».
• Объём защищает команду от бесконечного расширения работы — важно явно написать, что проверять не будем.
• Стратегия описывает инструменты и порядок — это помогает работать согласованно.
• Критерии входа и выхода дают чёткий ответ на вопросы «когда начинаем?» и «когда заканчиваем?».
• Риски лучше обдумать заранее, чем столкнуться с ними неожиданно.
• Тест-план — живой документ: его можно и нужно обновлять, если что-то меняется в проекте.

Что дальше? В следующем уроке мы возьмём этот тест-план и начнём наполнять его тест-кейсами — конкретными пошаговыми сценариями проверки каждой функции нашего учебного приложения.