Тест-план и тест-стратегия: преимущества, состав, советы по ведению

💡 Усі статті, обговорення, новини для початківців — в одному місці. Приєднуйтесь до Junior спільноти!

Всем привет! Меня зовут Дмитрий Штапаук, я Business Process Architect в Techstack. Примерно 10 лет моей карьеры мне доводилось занимать роли, так или иначе связанные с тестированием (manual testing, automation testing, QA Test Lead, QA Manager).

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

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

Преимущества ведения тестовой документации

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

Кто выигрывает от ведения документации

Если коротко: вся команда, в самом широком понимании этого слова (т. е. все причастные к работе с продуктом). А именно:

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

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

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

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

Заказчик. Не всегда клиент владеет тонкостями разработки ПО и пониманием процессов, которые происходят во время работы над продуктом, поэтому для него разработчики могут выглядеть как люди, нажимающие на кнопочки и создающие продукт, а тестировщики ─ как люди, которые хаотично тыкают везде и все ломают. Нередко тестировщики становятся козлами отпущения, виновниками всех бед и сбоев. В данном случае тест-план дает четкое понимание того, за что команда отвечает, а что не под ее контролем (3rd-party-сервисы и -продукты, edge-кейсы, которые невозможно отловить на тестовом окружении и т. д.).

Также я несколько раз сталкивался с ситуацией, когда наш продукт партнерился с другими крупными финансовыми или медицинскими продуктами. Многие из них запрашивают документацию, которая полностью регламентирует разработку продукта (управление рисками, business continuity plan, product development roadmap и т. п.). Помимо всей этой документации обычно запрашиваются документы, которые дают ответы на вопрос о комплексе мер, направленных на получение прогнозируемого качества продукта. Практически во всех случаях хорошо составленные тест-план и тест-стратегия полностью покрывают этот запрос (т. е. при условии наличия в них секций, покрывающих интересующие аспекты тестирования).

Аудиты и сертификации. Такие процессы очень «любят» и зачастую требуют подобные артефакты. Не будем подробно на этом останавливаться, так как далеко не все проекты сталкиваются с этими мероприятиями и проходят через процесс аудита и сертификации. Но если у вас запланировано нечто подобное, будьте готовы представить свою документацию.

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

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

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

Тест-план: элементы, примеры оформления и польза на практике

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

Scope of work. Секция включает в себя перечень компонентов и интеграций, которые будут тестироваться в рамка релиза, покрываемого данным документом, а также перечень того, за что команда тестирования не несет ответственности и перечень 3rd-party-компонентов, на качество которых команда влиять не может, но от которых зависит стабильность разрабатываемого приложения. С учетом вышесказанного эта секция включает в себя три подраздела:

• Components and Functions to be Tested.
• Components and Functions Not to be Tested.
• Third-Party Components.

Quality and acceptance criteria. Обычно представляет собой список условий, достигнув которых, команда поймет что продукт готов к релизу. В зависимости от процесса разработки, таких списков может быть несколько. Например, работая по скраму, можно выделить Release quality acceptance criteria и Sprint quality acceptance criteria.

Пример релизных критериев:

• Все тикеты релизного бэклога заимплеменчены, задеплоены, протестированы согласно acceptance criteria и описания тикета.
• Полный сет ручных и автоматизированных тестов пройден после код-фриза.
• Все E2E-сценарии пройдены.
• Все зафейленные сценарии проанализированы и баг-репорты заведены в баг трекере.
• Compatibility-тесты пройдены согласно списку браузеров и ОС с первым приоритетом, описанному в тест стратегии.
• Нет открытых багов с Critical- и Major-приоритетом.

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

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

1. Test Team Roles and Responsibilities содержит список ролей в команде тестирования, а также перечень активностей и зон ответственности по каждой из этих ролей. Например, для automation testing engineer этот список может выглядеть следующим образом:
   • Покрывает регрессионными тестами каждую отобранную для автоматизации историю согласно acceptance criteria параллельно процессу разработки этой истории.
   • Анализирует результаты прогона автотестов после каждого билда приложения.
   • Трекает покрытие стори/фичи автотестами.
   • Документирует найденные дефекты, тестирует результаты их исправления.
   • Взаимодействует с разработчиками продукта и разработчиками фичи/стори, над которыми работает.
   • Информирует тестлида о критических дефектах в тестируемом продукте или блокерах, с которыми столкнулся.
...и так далее. Этот список может быть довольно большим.
2. Testing Tools содержит название софта и его предназначения. Сюда может входить что угодно, чем тестировщик пользуется во время работы над тестированием продукта: тест-менеджмент система, баг-трекер, приложение для генерирования отчетов по тестированию, библиотеки и компоненты для автоматизированного тестирования, мобильные фермы для тестирования совместимости и т. д.
3. Environments — список энвайрментов и типов тестирования, которые там проводятся. Например:
   • Dev — для запуска юнит-тестов и интеграционных тестов после каждого нового билда в результате изменения кода.
   • Staging — основной энвайрмент для тестирования: функциональное тестирование фич, проверка профикшенных багов, регрессионное тестирование, тестирование совместимости, смоук-тестирование.
   • Demo — для UAT-тестирования и демо сессий бизнес команде.
   • Production — основной live-энвайронмент.

Например: 1) за тест-кейс отвечает каждый член мануальной команды тестирования, 2) частота обновления/создания: как только требования по соответствующей фиче/функционалу одобрены продакт оунером и стори передана тестовой команде, тестировщик начинает создание приемочных тестов, 3) способ распространения: через тест-менеджмент систему, упомянутую в разделе Testing Tools.

Defect and documentation tracking. Эта часть нужна для синхронизации понимания приоритетов между всеми участниками команды тестирования (и не только). Приоритеты могут быть, например, у багов и тест-кейсов и поэтому важно написать в каком случае какой приоритет мы ставим багу или тест-кейсу. Для наглядности разберем виды приоритетности для баг-репорта:

• Critical: повреждение или потеря данных пользователя, компонент или модуль полностью не работает или не доступен, дальнейшее тестирование или использование приложения/компонента/модуля заблокировано.
• Major: Часть основного функционала работает некорректно, поведение разработанного функционала противоречит acceptance критериям.
• Medium: Функционал работает некорректно, но есть обходные пути, второстепенные фичи работают неверно согласно требованиям, проблема имеет маленькое влияние на бизнес-логику.
• Low: косметический дефект.

В зависимости от специфики проекта, список приоритетов и их описание могут быть разными. На некоторых проектах приоритет выставляет на основе влияния проблемы на бизнес-логику, а влияние на критичность функционала выставляет в поле Severity.

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

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

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

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

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

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

Тест-стратегия: элементы, способы составления и использования

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

Testing Approach. Эта часть описывает типы тестов, которые будут применяться в ходе тестирования продукта, пирамиду тестирования на проекте и ее стек, а также расставляет приоритеты в таких видах тестов, как тестирование совместимости, инсталляционное, и т. п. Для удобства разобьем ее на подсекции.

Testing Levels. Состоит из самой пирамиды и описания уровней тестирования.

Testing Types. Включает перечень всех типов тестирования, которые команда планирует проводить на проекте, а также их цели, особенности процесса по каждому из типов и критерии окончания (acceptance criteria). Например, для Smoke Testing целью будет убедиться, что основные фичи не имеют критических дефектов, и определить, что приложение готово для последующих фаз тестирования.

Особенности процесса: смоук-тесты должны занимать не более 30 минут, запускаться после каждого нового билда, а также быть максимально покрыты автотестами.

Compatibility Testing Priorities (или другой вид тестов, где нужно расставить приоритеты в случае нехватки времени). Эта часть содержит перечень компонентов, или частей приложения, к которым применим этот вид тестов, а также матрицу этих самых приоритетов, которая может выглядеть следующим образом для различных браузеров и операционных систем:

Или для размера дисплеев:

Если у процесса тестирования есть нюансы по другим видам тестов, которые перечислены в таблице Testing Type и по которым нужно расписать дополнительные детали, их также следует вынести в отдельную подсекцию.

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

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

Приоритеты классифицируем по объему запуска соответствующих тестов в случае нехватки времени или других рисков:

• High — тестирование должно быть проведено в полном объеме.
• Medium — тестирование может быть проведено частично.
• Low — тестирование будет произведено, если останется время.

Testing Phases. В зависимости от процесса разработки, тестирование может проводиться на разных фазах. Например, при работе по скраму, фазы тестирования могут быть разбиты на те, которые происходят до спринта, во время спринта, приемочного тестирования и после релиза на продакшен.

Чтобы этот процесс был с прогнозируемым качеством, я рекомендую каждую из фаз формализовать и описать в виде: входных критериев, процесса тестирования во время фазы и выходных критериев. Чтобы было наглядно, приведем пример Production and post-production фазы тестирования, где выходными критериями будут:

• Приемочное тестирование пройдено.
• Релиз ноуты и релизная документация готова.
• Sign-off для релиза на продакшен получен.

Процесс тестирования этой фазы:

Release verification:

1. Пострелизное тестирование проводится на продакшене по необходимости и под руководством и надзором тестлида.
2. Проводится только смоук-тестирование без создания/обновления или удаления каких-либо данных.
3. Команда отчитывается о результатах тестирования включая проблемы, найденные при тестирование релиза на продакшен.

Reporting: Команда отправляет отчет о тестировании вышестоящему руководству и заинтересованным лицам.

Hotfix: Найденные проблемы должны быть пофикшены согласно их критичности и SLA, если они определены как критичные для продакшен окружения. (Далее можно списком расписать шаги исправления хотфикса, его тестирования и релиза на продакшен).

Выходные критерии:

• Смоук-тестирование пройдено.
• Найденные дефекты занесены в баг-трекер.
• Критические дефекты исправлены в рамках hotfix процесса.

CI/CD Testing Pipeline. Возможно, эта методология применима не везде, но на некоторых моих проектах приносила пользу. Эта диаграмма описывает кволити гейты и служит отправной точкой в конфигурации CI-пайплайнов.

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

Что в итоге

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

К тому же, работа в команде тоже станет прозрачнее и быстрее: вы всегда будете знать, где чья сфера ответственности, к кому идти с вопросами и как планируется работать над каждой задачей. Вам придется потратить время на качественное составление этих документов, но они точно помогут сэкономить много рабочих часов.

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

Всем стабильного продакшена и легких релизов!