Согласно стандарту IEEE 829, тест план должен состоять из 19 пунктов:
- Идентификатор тест плана
- Ссылки
- Введение
- Объекты тестирования
- Проблемы и риски
- Функции, которые нужно протестировать
- Функции, которые НЕ нужно тестировать
- Подходы
- Критерии прохождения тестов для объектов тестирования
- Критерии остановки и требования для возобновления тестирования
- Результаты тестирования
- Оставшиеся задачи тестирования
- Требования среды
- Требования по части кадров и их обучения
- Распределение обязанностей
- Расписание
- Планирование рисков и непредвиденных обстоятельств
- Утверждение
- Глоссарий
Хорошо написанная документация — залог эффективного тестирования. Она структурирует тестирование и привносит в него определенную логику. В некотором смысле документация объединяет членов команды вокруг поставленной цели, обеспечивая четкое понимание иерархии, задач и ожидаемых результатов.
Одна из важных частей документации — тест план.
В этой статье мы рассмотрим:
- что из себя представляет тест план
- чем он отличается от стратегии тестирования
- какова его роль в проекте
- какие виды тест планов бывают
- зачем команде нужен тест план
- и, самое главное, как его составить.
Прежде чем приступить к определениям и объяснениям, мы хотели бы объяснить еще один важный термин из сферы QA — артефакт тестирования.
Артефакты тестирования — побочные продукты, генерируемые в процесса тестирования ПО и использующиеся совместно с командой проекта. Проще говоря, это документы, которые помогают наладить коммуникацию между всеми участниками проекта.
А теперь давайте перейдем непосредственно к тест плану.
Что такое тест план?
Тест план — это артефакт тестирования, описывающий действия, которые будут происходить в процессе тестирования — от разработки стратегии до критериев поиска ошибок. Он также описывает логику завершения задач и оценку рисков со сценариями их разрешения.
Структура тест плана
Тест план имеет четкую структуру, установленную IEEE 829 — отраслевым стандартом для документации тестирования программ и систем. Это значит, что вы можете подготовить шаблон и использовать его для любого проекта, заполняя конкретными данными.
Создание тест плана в соответствии со стандартом IEEE 829 дает много преимуществ. Прежде всего, когда структура документа всем известна, такой документ и составлять легче, и пользоваться им проще. Стандарт IEEE 829 устраняет любые бесполезные дебаты относительно того, что включать в тест план и в каком порядке. Вместо этого тестировщики могут сосредоточиться на других, более важных вещах.
1. Идентификатор тест плана
В этом разделе мы указываем название и логотип компании, проводящей тестирование, название документа, его версию и год создания. Это титульная страница вашего тест плана.
2. Ссылки
Дальше идет история документа. Добавьте таблицу изменений со следующими столбцами:
- дата
- версия
- описание
- автор.
С помощью этой таблицы команда сможет эффективно фиксировать и отслеживать изменения в документе и процессе, который он описывает.
3. Введение
Здесь мы кратко обозначаем, что собираемся делать. Введение — это пояснительная записка для клиента. В паре предложений опишите, какие услуги предоставит команда QA и зачем. Например:
«Наша компания осуществляет функциональное и UI-тестирование для выявления ошибок в программном продукте до выпуска. Мы выполняем тщательное тестирование заявленных функциональных возможностей, чтобы помочь достичь заданных целей бизнеса для вашего программного продукта».
Включите все виды тестирования, которые вы согласились осуществить, но не входите в детали. На этом этапе достаточно обозначить все в общих чертах.
4. Объекты тестирования
Объекты тестирования — это общие функциональные возможности, которые будут протестированы. Например, установка программы, регистрация в системе, оформление заказа и т. д. По сути, это краткое содержание тест плана. В дальнейшем каждый из объектов будет описан отдельно. Список может быть расширен или сокращен в зависимости от задач или типа тестирования.
5. Проблемы и риски
В этом разделе мы описываем проблемы, с которыми команда может столкнуться во время тестирования. Например, если дедлайн установлен на летний период, разумно предположить, что люди могут уйти в отпуск, из-за чего возможны задержки. Здесь нужно упомянуть все значимые проблемы и риски: как связанные с кадрами, так и технологические аспекты.
6. Функции, которые нужно протестировать
Эта часть охватывает то, что, по мнению большинства людей, и должно быть в тест плане: подробный список функций для проверки и время, за которое они должны быть проверены.
Например, в «Объектах тестирования» мы упомянули функциональное тестирование. Тогда в функциях, которые необходимо протестировать, мы должны перечислить отдельные компоненты потока: ввод информации о доставке, выбор способа оплаты, подтверждение заказа и т. д. Что касается времени, клиент и компания, проводящая тестирование, обсуждают его до написания документации.
7. Функции, которые не нужно тестировать
Здесь вы перечисляете функции, которые тестировщики по каким-то причинам не будут тестировать. Неважно, почему вы не покрываете тестами эти фичи. Просто не забудьте указать, какие именно функции не охватываются тестированием и остаются в зоне ответственности клиента.
8. Подходы
Затем мы описываем методы и виды тестирования, которые будем применять. В этот раздел также включаются тест-кейсы. Благодаря этому клиент может получить полную картину действий по тестированию.
9. Критерии прохождения тестов
Каждый тест-кейс будет обозначен как «Pass» (пройден) или «Fail» (провален) в зависимости от двух критериев:
- Наличие и серьезность багов
- Уровень успешно выполненных требований.
И не забудьте определить критерии начала и окончания тестирования.
Критерии начала — то, что должно быть и что нужно сделать до начала тестирования. Например, вам могут понадобиться:
- законченная справочная документация
- программный продукт в том виде, в котором его будут получать клиенты
- специальные программные утилиты, конфигурационные файлы или данные
- требования к продукту и прочая документация и т.д.
Критерии начала тестирования служат для определения готовности или неготовности к тестированию. Будет полезно составить список того, что будет использоваться в качестве входных данных, и запросить материалы, необходимые для выполнения тестов.
Критерии окончания тестирования — это то, что вы считаете необходимым для завершения процесса тестирования. Тестировщики часто стараются сделать критерии окончания тестирования условием для поставки ПО, но это не реально. Это решение принимает собственник продукта (или другое ответственное лицо).
Пример критериев окончания тестирования:
«Все запланированные тесты проведены, все исправленные баги отмечены, сделаны уведомления обо всех новых обнаруженных багах. Все точки отказа (например, провал определенного набора тестов из-за неисправности железа) задокументированы».
10. Критерии остановки и требования для возобновления тестирования
Критерии остановки/возобновления описывают ситуацию, когда тестирование невозможно продолжать из-за найденных багов. Другими словами, если дела идут так плохо, что запланированные тесты нельзя провести, тестирование нужно остановить до устранения блокирующих багов.
11. Результаты тестирования
Чтобы засвидетельствовать результаты проведенной работы, мы отправляем их клиенту. Обычно результаты тестирования оформляют при помощи различных показателей: количество завершенных тестов, найденные баги и т.д. В некотором смысле эти показатели — индикаторы качества тестирования, хотя и не должны быть единственным критерием для оценки проделанной работы.
12. Оставшиеся задачи тестирования
Жизненный цикл ПО может быть непредсказуемым. Иногда проверка продукта занимает больше времени, чем первоначально ожидалось. Если времени мало, некоторые части функциональности могут оставаться непроверенными. В таком случае команда включает оставшиеся задачи в тест план. Кроме того, в этом разделе можно описать масштаб необходимой работы на случай, если все задачи будут закрыты до дедлайна.
13. Требования среды
В целом, в этом разделе описывается, что нужно для тестирования по части аппаратного обеспечения. Здесь мы перечисляем и инструменты, используемые для тестирования.
При необходимости вы можете описать какое-то особое оборудование и его функционал. Например, если в связи со спецификой проекта вам потребуется использовать комплект VR или какие-то специфические устройства, которые нужно приобрести.
14. Требования по части кадров и их обучения
Если мы получим задачу тестирования ПО для ядерных реакторов, вполне вероятно, что команда не будет полностью понимать специфику. Это, конечно, преувеличение. Но если команда должна протестировать проект из сферы, с которой они не знакомы, имеет смысл провести лекцию или краткий обучающий курс от экспертов. Это поможет тестировщикам понять особенности проекта и сделает их работу более эффективной.
15. Обязанности
В этом разделе описываются сферы ответственности каждого члена команды QA. Удобно составить таблицу с тремя столбцами — имя, должность и обязанности.
16. Расписание
Тест план должен также включать дедлайны. Команде нужно как-то оценивать скорость работы. Для этого им нужно знать, сколько времени отводится на тестирование. Если есть несколько этапов тестирования, нужно расписать их порядок и сроки.
17. Планирование рисков и непредвиденных обстоятельств
Этот раздел перекликается с п. 5 «Проблемы и риски». Здесь, в дополнение к перечню рисков, мы предоставляем разъяснения о том, как справиться с этими рисками, и что делать в случае форс-мажорных обстоятельств.
18. Утверждение
Каждый тест план должен содержать информацию о том, кто его составлял (имя, должность), и о том, кто его должен одобрить и дать команде зеленый свет на его использование.
19. Глоссарий
В этом разделе вы можете пояснить основные термины, используемые при написании тест плана. Глоссарий помогает предотвратить неправильное толкование используемой терминологии.
Виды тест планов
Несмотря на стандартную структуру, существует несколько типов тестовых планов. Они отличаются особенностями описанных задач и объемом работ. QA-команды, как правило, используют следующую классификацию:
Тест планы по уровням — планы модульного, интеграционного, системного, приемочного тестирования
Тест планы по типам — планы функционального тестирования, тестирования производительности или юзабилити, план автоматизированного тестирования и т.д.
Мастер тест план — это комплексный план тестирования. Включает высокоуровневую информацию, которая не часто меняется в ходе тестирования и требования к которой не часто пересматриваются.
По сравнению с простым тест планом мастер тест план более статичен. Это ключевое различие. Как правило, команда проекта использует один мастер тест план и несколько более подробных тест планов для разных уровней или типов тестирования, в которых описываются отдельные модули одного приложения.
Вы можете создать тест план любого типа без использования каких-то особых инструментов. Вам может повстречаться выражение «Инструменты управления тест планами», но это неточная формулировка. Тест план — это документ, и единственный инструмент, который вам нужен для управления им, это текстовый редактор. Обычно речь идет об инструментах управления тестированием, таких как TestRail, TestPad, Qmetry, KualItee и т. д.
Тест план и стратегия тестирования — в чем разница?
Многие считают, что разграничить тест план и стратегию тестирования сложно. Тем не менее, это два разных документа. Тест план более подробный и охватывает больше аспектов, чем стратегия тестирования. Последняя часто используется на организационном уровне и редко меняется. Между тем тест план более динамичен и используется на уровне проекта. Стратегия обычно является частью плана.
Существует также QA-стратегия, которая выходит за пределы тестирования и охватывает другие виды деятельности и методологии обеспечения качества.
Итоги
Как видите, тест план — объемный, часто сложный в написании, но очень важный артефакт тестирования. Он хорошо структурирует процесс тестирования, предотвращая много стрессовых ситуаций и недоразумений. Более того, тест план помогает всем членам команды быть в курсе происходящего, поскольку все заинтересованные стороны имеют к нему доступ.
Написание тест плана требует сильных аналитических навыков, внимания к деталям, а также способности продумывать действия на несколько шагов вперед. Но результат стоит свеч.
В общем, даже если написание документации кажется менее интересным, чем тестирование, только вместе они делают процесс QA эффективным.
