Тест-план: пример, шаблон и чем он отличается от тест-стратегии

Тест-план — документ, который в учебниках занимает десять страниц, а в реальных проектах чаще всего не существует вовсе: «мы же и так знаем, что проверять». Пока команда маленькая и релизы редкие, это работает. Ломается на первом релизе, где надо было проверить ещё и обмен с 1С, а никто не записал, что он есть.

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

Определения

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

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

Тестовый прогон — исполнение плана: конкретные кейсы, конкретное окружение, конкретный тестировщик, отметки «прошёл / упал» по каждому шагу. Один план может породить несколько прогонов — по одному на каждую конфигурацию среды или на каждый цикл после исправления дефектов.

Критерий выхода — условие, при котором проверку считают законченной: «все кейсы с критичным приоритетом прошли, открытых блокирующих дефектов нет». Без критерия выхода план не заканчивается никогда: всегда есть ещё один кейс, который стоило бы прогнать.

Тест-кейс — единица, из которых план собирается; о том, как их писать, — отдельная статья.

Из чего состоит тест-план

Восемь разделов — это верхняя граница. Для регулярного события — еженедельного релиза, обновления облачного Битрикс24 — план сжимается до трёх: объём, кейсы, критерий выхода. Остальное живёт в стратегии и не переписывается.

Объём: что входит и что не входит

Раздел «не входит» важнее раздела «входит». Пока не написано «интеграция с телефонией в объём не входит», кто-нибудь спросит, почему её не проверили. Явное исключение — это решение, а не упущение; его можно оспорить до прогона, а не после.

Кейсы: как отбирать

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

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

Окружения

Одна и та же функция на разных окружениях ведёт себя по-разному, и план должен это учитывать. Для веб-приложения — браузеры и мобильная версия; для Битрикс24 — облако и коробка, веб и мобильное приложение; для 1С — копия базы и рабочая база, файловый и клиент-серверный вариант. Каждая конфигурация — отдельный прогон одного плана: результаты не смешиваются, и видно, что «не работает только в Safari».

Роли и сроки

Три роли — прогоняет, чинит, принимает — и четыре даты: начало прогона, срок исправлений, повторный прогон, приёмка. Если одну роль занимают два человека, между ними делится объём кейсов, а не ответственность. Если принимающий не назначен, план завершится «по умолчанию» — выкаткой в пятницу вечером, потому что «вроде проверили».

Риски

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

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

Критерий должен быть проверяемым: по нему кто угодно может сказать «да» или «нет». «Все критичные кейсы прошли, блокирующих и критичных дефектов нет, значительные — не больше трёх и все с датой исправления» — проверяемый критерий. «Качество приемлемое» — нет.

Пример: план на релиз доработки CRM

Пример собран на типовой ситуации интегратора Битрикс24 — релиз доработки, которая добавляет обязательные поля на стадии воронки и робота, отправляющего письмо клиенту. Числа условны, структура — рабочая.

Событие и цель. Релиз доработки CRM «обязательные поля и уведомление клиента на стадии „Согласование“». Цель — убедиться, что доработка работает по постановке и не сломала существующие сценарии CRM.

Объём. Входит: стадия «Согласование» и её обязательные поля; робот отправки письма; движение сделки по всей воронке; права ролей «менеджер» и «руководитель отдела» на изменённые поля. Не входит: остальные воронки; телефония; обмен с 1С (не затронут, проверяется отдельным планом раз в месяц).

Кейсы. Из библиотеки: папка «CRM → Сделки → Стадии» — все кейсы (6); папка «CRM → Роботы» — кейсы с тегом письмо (3); новые кейсы по постановке — обязательные поля и уведомление (4, статус «актуален» после ревью); смоук CRM — кейсы с приоритетом «критичный» из пакета регресса CRM (9). Итого 22 кейса.

Окружения.

Роли и сроки. Прогон — вторник, тестировщик; исправления — среда, разработчик; повторный прогон упавших и соседних кейсов — четверг; приёмка — руководитель проекта, четверг до 18:00; выкатка на рабочий портал — пятница утром.

Критерий выхода. Все 22 кейса прошли на Chrome; на Safari и iOS — все кейсы по обязательным полям и роботу; открытых дефектов серьёзности «блокирующий» и «критичный» нет; дефекты «значительный» — не больше двух, с датой исправления в следующем релизе.

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

Результат. Заполняется по итогу: ссылка на прогоны по каждой конфигурации, сводка «прошло / упало / пропущено», список дефектов, решение о выкатке с подписью принимающего.

Двадцать два кейса, три конфигурации, четыре дня — план умещается на одну страницу и читается за две минуты. Именно поэтому его откроют в четверг, когда надо принимать решение.

Шаблон тест-плана

Скопируйте и заполните. Разделы в квадратных скобках — необязательные, для регулярных событий удаляются.

Тест-план: [название события]

1. Событие и цель
   Что: релиз / обновление / приёмка …
   Зачем: …

2. Объём
   Входит: …
   Не входит: …

3. Кейсы
   Изменённые функции: папки / теги / номера …
   Соседние функции: …
   Смоук: кейсы с приоритетом «критичный» из …
   Итого: N кейсов, ссылка на план в TMS

4. Окружения
   Конфигурация | Стенд | Кто прогоняет

5. Роли и сроки
   Прогон: кто, когда
   Исправления: кто, когда
   Повторный прогон: когда
   Приёмка: кто, когда

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

[7. Риски]
   Риск → что делаем

8. Результат (по итогу)
   Прогоны: ссылки
   Прошло / упало / пропущено: …
   Открытые дефекты: …
   Решение: …, кто принял, дата

Типовые ошибки

План переписывает стратегию. Двадцать страниц про виды тестирования, из которых два абзаца относятся к этому релизу. План — про это событие; всё общее — в стратегии, на неё ссылка.

Нет раздела «не входит». Каждый релиз заканчивается вопросом «а почему не проверили X». Явное исключение снимает вопрос до прогона.

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

Одно окружение по умолчанию. «Проверили» означает «проверили в Chrome на ноутбуке тестировщика». Дефект в мобильном приложении находит клиент.

Критерий выхода не проверяем. «Когда всё будет хорошо» — не критерий. Число кейсов, серьёзность допустимых дефектов, сроки — критерий.

План не закрывается результатом. Прогон прошёл, дефекты завели, решение приняли в чате — а в плане пусто. Через месяц неизвестно, чем кончился релиз. Раздел «Результат» заполняется всегда, даже одной строкой.

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

Чек-лист: план готов к прогону

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

Как это устроено в QA Деск

В QA Деск тест-план составляется из кейсов библиотеки — по папкам, тегам и приоритетам, — то есть разделы «Кейсы» и «Объём» из шаблона живут в самом плане, а не в отдельном документе. Для каждой конфигурации среды — браузер, ОС, стенд — план стартует отдельный прогон и хранит снимок конфигурации на момент старта. В прогоне тестировщик отмечает результат по каждому шагу, заводит дефект из упавшего шага с автоматической связью, таймер считает время по строке и по прогону целиком. Сводный экран прогона — пройдено, упало, пропущено, открытые дефекты — это раздел «Результат» и материал для критерия выхода.

Текстовые разделы плана — цель, роли, сроки, риски, решение — короткие, и их удобно держать в описании плана или в задаче Битрикс24, из которой приложение QA Деск показывает дефекты релиза. Если план — на обновление платформы, а не на релиз, готовые наборы кейсов для Битрикс24 и 1С есть в Каталоге: пакет добавляется в проект, план собирается из его кейсов по приоритету, и первый прогон начинается через десять минут после регистрации.