Как создать тест-план и тест-стратегию для проектов

Тест-план (Test Plan, план тестирования) — это глобальный документ, который описывает весь процесс тестирования конкретного проекта или его части. Чтобы увеличить ценность тест-плана, участники проектной группы должны время от времени рецензировать и утверждать его.

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

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

1. возможность приоритезации задач по тестированию.
2. построение стратегии тестирования, согласованной со всей командой.
3. возможность вести учет всех необходимых ресурсов, как технических, так и человеческих.
4. планирование использования ресурсов на тестирование.
5. Просчет рисков, возможных при проведении тестирования.

Наконец, ваши дизайнеры и команда программистов закончили работу над фантастически красивым и многофункциональным сайтом, будущие клиенты в максимальном восторге и уже готовы перечислить на счет вашей организации выплату и все, что еще остается сделать – это протестировать продукт перед финальным релизом.

Вот здесь и кроется все самое прекрасное и милое, что может случиться в рабочей обыденности любого тестировщика: у вас в голове проскакивает мысль, что вышла новая версия браузера, в среде мобильных гаджетов появилось еще одно расширение и вообще, по хорошему дизайну и милым анимациям. ВаУ! Чтобы хоть как-то прийти в себя и перестать паниковать, вы открываете в своем компьютере папку с документацией по плану тестирования сайта…

Но не стоит забывать о стратегии тестирования. О ней сейчас и поговорим.

Стратегия тестирования – необъемный документ, который по логике своего использования предшествует типовому тест-плану при работе с разрабатываемым веб-продуктом. Перед тем как писать детализированный план по работе с проверкой работоспособности программного продукта, следует максимально эффективно формализовать некоторые фундаментальные подходы к тестированию и убедиться, что все члены вашей группы одинаково понимают, что и как именно будет проверяться.

Тест-стратегия часть тест-плана и отвечает как тестировать и каким способом тестировать. Тест-стратегия не изменяется, а тест-план меняется.

Что же должен быть описано в стратегии?

Какие типы проверок намечены:

• Будет ли выполняться тестирование UI, производительность системных компонентов, работа конфигураций и прочее;
• Собирается ли команда QA реализовывать другие статические типы тестов, например рецензирование установленных требований;
• Будете ли вы проводить исследовательское тестирование, и в каком % соотношении.

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

Вы спросите зачем это делать? Чтобы не забыть ни о чем при разработке тест-плана.

Что пойдет в базу будущих тестов? С какой величины вы намерены выводить величины для проверки установленных тестов?

К примеру, это могут быть специальные требования, сценарии воспроизведения, типовые классификации и стандарты.

При работе со стратегией можно отметить список важных критериев, отвечающих за серьезность и приоритетность найденных дефектов или системных ошибок.

Как правило, оценка серьезности ошибок всегда вызывает оживленные споры, если обычно существует группа критериев, по которым их можно оценивать. Наиболее подходящий вариант – формализовать важность ошибок и стратегию их исправления именно внутри расписанной стратегии тестирования.

Логически продуманная и составленная стратегия тестирования – это весьма качественная основа для дальнейшей разработки остальной технической документации на проекте (в нашем случае тест-плана), которая помогает максимально избежать недоразумений в будущем.

Тест-план - это специализированный технический документ, внутри которого описывается весь будущий фронт работ по тестированию разрабатываемого продукта, начиная с документирования самого объекта, использованного в начале стратегии разработки, и критериев нахождения ошибок. Кроме этого, в нем изложена логика окончания проводимых работ с обязательной оценкой рисков, а также вариантами их эффективного решения.

Каждая существующая методология, используемая при проверке веб-продуктов, имеет свой оригинальный формат составления планов тестирования. Предлагаем дальнейшее обсуждение вопросов написания планов рассматривать на основе международного стандарта IEEE 829, а именно: TestPlanTemplate RUP; TestPlanTemplate IEEE 829. Изучив эти документы внимательно, сразу становится ясно, что их содержание описывает одни и те же детали, но в разных формах.

В ситуации, когда вы не хотите использовать классический шаблон или решили разработать и внедрить собственный в более подходящей для вашего проекта форме, следует создавать документ, который бы отвечал по меньшей мере на следующие вопросы:

1. Что именно нужно тестировать (объект тестов, используемая веб-среда, дополнительные приложения, какое оборудование при этом используется). В этом пункте нужно подробно обрисовать объект тестирования. Это может быть описание системы, приложения, оборудования. Если объектом тестирования является приложение, следует перечислить все его функциональные блоки. Также необходимо указать на каком оборудовании, в каких браузерах будет производиться тестирование. Что будет тестироваться (полный список системных функций, которые необходимо проверить на наибольшую работоспособность);
2. Как именно вы будете тестировать: пресловутая стратегия тестирования – типы проверок, а также их применение в отношении объекта тестов.
3. Когда будет производиться тестирование? На данном этапе описывается последовательность проведения работ: подготовка (Test preparation), тестирование (Testing), анализ результатов (Test result analysis) в разрезе планируемых фаз разработки. Обязательно должны быть указаны даты или критерии перехода от одной фазы к следующей. Логически описана структура выполняемой проверки: подготовительные работы, непосредственно процесс теста, анализ полученной информации о планируемых фазах веб-разработки на проекте.
4. Критерии начала тестирования. В зависимости от конкретного проекта, критерии начала тестирования могут быть разными. Примеры некоторых возможных вариантов начала тестирования перечислены ниже: готовность тестовой платформы (тестового щита); законченность разработки требуемого функционала; наличие всей требуемой документации.
5. Критерии окончания тестирования: требования к количеству открытых багов выполнены; выдержка определенного периода без изменения исходного кода Code Freeze (CF); выдержка определенного периода без открытия новых багов Zero Bug Bounce (ZBB); все тесты успешно пройдены; закрыты все баги с высокой и средней критичностью.

Если вы сможете максимально исчерпывающе ответить на все вышеперечисленные вопросы при составлении плана тестирования, то можете с уверенностью считать, что перед вами хорошо и главное правильно составлен тест-план проектов.

Затем, чтобы документ приобрел более завершенный вид, в него следует внести следующие пункты:

• Актуальное окружение проверяемой системы (описание программно-аппаратных средств);
• Оборудование для тестов и виртуальные системы;
• Потенциальные опасности и пути их решения.

В зависимости от конкретизации описываемых задач тест-планы делятся на определенные виды:

1. Мастер тест-план — это более статичный документ, содержащий высокоуровневую (high level) информацию. Он описывает общую стратегию тестирования, основные цели и подходы, но не меняется часто в ходе самого тестирования. Такой план скорее устанавливает общие рамки и основы проведения тестирования.
2. Детализированный тест-план (простой тест-план) — содержит более конкретную информацию о стратегии тестирования, расписании, деталях выполнения тестовых задач. Этот план считается «живым» документом, который активно редактируется и обновляется по мере проведения тестирования, отражая реальное состояние проекта и прогресс в тестировании.
3. План приемных испытаний (Product aceptance plan) – это документ, описывающий набор действий, связанных с приемочным тестированием (стратегия, дата проведения, ответственные работники и др.).

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

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

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

1-я страница:

1. шапка (логотип и адрес компании);
2. название тест-плана;
3. версия тест-плана;
4. год.

2-я страница:

1. история документа, представляющая собой таблицу изменений. Эта таблица содержит столбцы: дата, версия, описание, автор.

3-я страница:

1. содержание тест-плана.

4-я страница и далее:

1. вступление;
2. виды тестирования;
3. операционные системы, браузеры;
4. функционал приложения;
5. критерии начала тестирования;
6. критерии выхода из тестирования;
7. характеристики оборудования.

Предпоследняя страница:

1. сколько человеко-часов планируется на разных этапах (дата начала и окончания), например:
   1. на тест-дизайн;
   2. на выполнение тестов;
   3. на анализ тестирования;
   4. на отчёты.

Последняя страница:

1. выводы и рекомендации.

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

1. FAQ 1: Опишите своими словами отличие Тест Стратегии и Тест Плана (этот вопрос часто спрашивают на собеседовании, поэтому важно знать на него ответ). Ответ: Тест стратегия это неотъемлемая часть тест-плана. Тест стратегия это небольшой и не изменяемый документ отвечающий за то какие- типы проверок должны быть реализованы.  А тест план изменяемый технический документ описывающий весь будущий фронт работ по тестирования ПО (от документирования, до логики окончания работ, оценки рисков и вариантов их устранения.) Таким образом, основное отличие в уровне детализации и назначении: тест-стратегия задаёт общий путь и правила, а тест-план — конкретный план реализации этого пути в проекте.
2. Что такое Тест-стратегия? Ответ: это высокоуровневый, стабильный и достаточно обобщённый документ, который определяет общие подходы, цели и принципы тестирования продукта. В ней описываются типы и уровни тестирования, методы, критерии качества, распределение ответственности и основные риск-ориентированные приоритеты. Тест-стратегия задаёт направление для всех последующих действий по тестированию и вносится редко.
3. Что такое Тест-план? Ответ: это более подробный и изменяемый документ, основанный на тест-стратегии. Он описывает конкретный набор задач, ресурсов, расписание, объём работ, условия и критерии начала и окончания тестирования конкретного релиза или проекта. В тест-плане прописываются конкретные действия, инструменты, роли и критерии оценки результатов. Тест-план живёт во время всего цикла тестирования, может корректироваться в зависимости от хода работ.
4. Чем отличается Тест-репорт от баг-репорта? Тест-репорт — это обобщённый итоговый документ с обзором всего тестирования (нескольких тест-кейсов вместе), его статусом и заключениями. Отчёты по отдельным тестам — более мелкие записи или баг-репорты, отражающие статус и результат конкретного тест-кейса.
5. Что такое Тест сьют (Test Suite)? Ответ: В терминах QA называются также «тест-набор», «тестовый набор» или просто «свит» (suite). Тест сьют (Test Suite) — это набор (коллекция) тест-кейсов, которые сгруппированы вместе для проверки определённого функционала или части приложения. Тест сьют служит контейнером для выполнения и организации тестов по смыслу или назначению. Например для тестирования VPS можно использовать Phoronix Test Suite.
6. По какому принципу формируют тест сьюты?. Ответ: Тест сьюты формируют, группируя тест-кейсы по функционалу, типу тестирования, этапу разработки или логической связи между тестами. Это облегчает организацию, запуск и анализ тестирования.