Стратегия тестирования (Test strategy)

Стратегия тестирования (test strategy): Высокоуровневое описание уровней тестирования, которые должны быть выполнены, и тестирования, входящего в эти уровни, для организации или программы из одного или более проектов. (ISTQB)

Стратегия тестирования - это статический документ высокого уровня, обычно разрабатываемый менеджером проекта. Это документ, который отражает подход к тестированию продукта и достижению целей, и дает четкое представление о том, что команда тестирования будет делать для всего проекта. Обычно он выводится из Спецификации бизнес-требований (BRS). Как только стратегия тестирования готова, группа тестирования начинает писать подробный план тестирования и продолжает дальнейшие этапы тестирования. В мире Agile некоторые компании не тратят время на подготовку плана тестирования из-за минимального времени для каждого выпуска, но они поддерживают документ стратегии тестирования. Это один из важных документов в test deliverables, которым команда тестирования делится с заинтересованными сторонами для лучшего понимания объема проекта, рисков, подходов к тестированию и других важных аспектов.

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

● Обзор и объем (Scope and overview): объем работ по тестированию (что тестировать и зачем тестировать) и обзор тестируемого продукта;

● Подход к тестированию (Test Approach):

○ Уровни тестирования (Test levels);

○ Виды тестирования (Test Types);

○ Роли и обязанности (Roles and responsibilities);

○ Требования к окружениям (Environment requirements);

● Инструменты тестирования (Testing tools): инструменты, необходимые для проведения тестов (TMS, багтрекинговая система, стек автоматизации);

● Отраслевые стандарты, которым необходимо следовать (Industry standards to follow): В этом разделе описывается отраслевой стандарт для производства высококачественной системы, которая соответствует ожиданиям клиентов или превосходит их. Обычно менеджер проекта определяет модели и процедуры тестирования, которым необходимо следовать для достижения целей проекта;

● Результаты тестирования (Test deliverables): документация, которую необходимо создать до, во время и по окончании тестирования;

● Метрики тестирования (Testing metrics): метрики, которые следует использовать в проекте для анализа статуса проекта;

● Матрица отслеживания требований (RTM);

● Риски и способы их снижения (Risk and mitigation): все риски тестирования и план по их снижению;

● Инструмент отчетности (Reporting tool): как будут отслеживаться дефекты и проблемы;

● Результаты тестов (Test Summary): виды сводных отчетов о тестах, которые будут создаваться, с указанием периодичности. Сводные отчеты о тестах будут генерироваться ежедневно, еженедельно или ежемесячно, в зависимости от критичности проекта.

Источники:

● The Complete Guide To Writing Test Strategy

Доп. материал:

● Большая качественная подборка материалов по теме

● Practical test strategy using heuristics

● Примеры: раз, два, три

План тестирования (Test plan)

“План тестирования (test plan): Документ, описывающий цели, подходы, ресурсы и график запланированных тестовых активностей. Он определяет объекты тестирования, свойства для тестирования, задания, ответственных за задания, степень независимости каждого тестировщика, тестовое окружение, метод проектирования тестов, определяет используемые критерии входа и критерии выхода и причины их выбора, а также любые риски, требующие планирования на случай чрезвычайных обстоятельств.” (IEEE 829)

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

Хотя есть рекомендации по составлению тест плана (IEEE 829 (1, 2), RUP), нет единственно правильного шаблона или формата для написания тест-планов. В обзорных статьях можно встретить и свои варианты:

Такой:

● Перечень планируемых тестовых активностей (Test Activities);

● Тестовая логистика (Test Logistics);

● Необходимые ресурсы (Resources);

● Необходимые коммуникации (Your Support Network);

● Оценки трудозатрат (Estimates);

● Зависимости и риски (Dependencies, Risks and Assumptions);

● Порядок обсуждений и отчетности в процессе работы (Communication, Commitment and Progress Reporting);

Или:

● Какие ресурсы требуются и когда;

● Когда задачи нужно начинать и заканчивать, и кто их будет выполнять;

● Навыки, необходимые для выполнения задач;

● Инструменты и технологии, поддерживающие план;

● Результаты и когда они будут доставлены;

● Затраты на усилия и необходимые ресурсы;

● Процесс продвижения проекта / процесса по стадиям;

● Риски, угрожающие доставке.

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

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

“В зависимости от размеров команды, сложности продукта, количества зависимостей и строгости критериев качества эти вопросы могут быть иными. Если процесс тестирования имеет большое количество зависимостей, например разные команды должны выполнять разные этапы тестирования в строго определенном порядке - это необходимо фиксировать. Без этого ты не только не сможешь планировать работу команд, но и несколько раз выстрелишь себе в ногу, когда команды будут блокировать друг друга из-за того, что заранее не проговорили зависимости. Чем более комплексным является объект тестирования (и как результат само тестирование), тем более подробного описания требует методология тестирования, применяемые подходы и практики - просто за счёт увеличения объема того, что необходимо проверить. Без этого сложно оценивать объемы работ, давать эстимейты и строить планы по релизам. Чем более точно и строго необходимо оценивать уровень качества, тем более детально должны быть описаны критерии прохождения тестирования, ключевые метрики и quality gate `ы. Потому что без их формализации нельзя будет однозначно оценить результаты тестирования. Люди, находящиеся за пределами команды тестирования (а иногда и команды разработки в целом) хотят понимать, что вообще происходит на этапе тестирования и как обеспечивается качество продукта. Иногда это связано с регуляторикой отрасли, иногда для согласования объемов работы с заказчиком, иногда из-за высокой степени рисков или просто потому, что работа этих людей напрямую зависит от результатов процесса обеспечения качества.“ (с) Shoo and Endless Agony: What's the plan?

Виды тест-планов:

● Мастер Тест-План (Master Test Plan): “Главный план тестирования (master test plan, project test plan): План тестирования, обычно охватывающий несколько уровней тестирования.” (ISTQB). Это может быть как единственный базовый план, так и главный в иерархии нескольких планов, самый статичный и высокоуровневый. Нужен когда:

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

○ различные тестовые команды работают над одним продуктом, выполняя различные задачи, которые необходимо объединить в рамках одного документа;

● Детальный Тест-план (Phase Test plan): “Уровневый план тестирования (level test plan): План тестирования, обычно относящийся к одному уровню тестирования.” (ISTQB). Детальный план составляется на каждый релиз/итерацию или для каждой команды в рамках проекта и является динамическим, т.е. может претерпевать изменения по необходимости. Его основная цель - кратко и доходчиво отразить задачи тестирования. Детальных планов может быть несколько для отдельных модулей ПО или команд тестирования. Кроме того, могут быть созданы планы для отдельных уровней тестирования (Level Test Plan) или видов тестирования. В Agile проектах могут быть планы итерационного тестирования (iteration testing plans) для каждой итерации;

● План приемочных испытаний (Acceptance Test Plan, ПСИ):план приемочного тестирования отличают от обычного плана тестирования факторы, которые приводят к принятию бизнес-решения. План приемочного тестирования - это один из жизненно важных документов, который содержит руководство по выполнению приемочного тестирования для конкретного проекта. Пишется на основе бизнес-требований (Business Requirements). Ревью этого плана обычно выполняется by Managers/Business Analysts/Customers.

Источники:

● Leadership in test: test planning

● Acceptance Testing Documentation With Real-Time Scenarios

Доп. материал:

● Тест-план не для галочки, или 8 вопросов к заказчику на старте проекта

● Blog: What Should A Test Plan Contain?

● The One Page Test Plan

● TEST PLAN: What is, How to Create (with Example)

● Примеры: раз, два; Acceptance Test Plan Template