План тестирования (Test plan)
Last updated
Was this helpful?
Last updated
Was this helpful?
“План тестирования (test plan): Документ, описывающий цели, подходы, ресурсы и график запланированных тестовых активностей. Он определяет объекты тестирования, свойства для тестирования, задания, ответственных за задания, степень независимости каждого тестировщика, тестовое окружение, метод проектирования тестов, определяет используемые критерии входа и критерии выхода и причины их выбора, а также любые риски, требующие планирования на случай чрезвычайных обстоятельств.” (IEEE 829)
В то время как стратегия излагает общие принципы или теорию, план детально описывает практические аспекты того, как проект будет протестирован в реальности.
Хотя есть рекомендации по составлению тест плана (IEEE 829 (, ), ), нет единственно правильного шаблона или формата для написания тест-планов. В обзорных статьях можно встретить и свои варианты:
:
Перечень планируемых тестовых активностей ();
Тестовая логистика ();
Необходимые ресурсы ();
Необходимые коммуникации ();
Оценки трудозатрат (Estimates);
Зависимости и риски (Dependencies, Risks and Assumptions);
Порядок обсуждений и отчетности в процессе работы (Communication, Commitment and Progress Reporting);
Или:
Какие ресурсы требуются и когда;
Когда задачи нужно начинать и заканчивать, и кто их будет выполнять;
Навыки, необходимые для выполнения задач;
Инструменты и технологии, поддерживающие план;
Результаты и когда они будут доставлены;
Затраты на усилия и необходимые ресурсы;
Процесс продвижения проекта / процесса по стадиям;
Риски, угрожающие доставке.
В какой-то момент можно заметить, что все они предлагают плюс-минус похожую структуру и пункты, а итоговый вариант всё равно будет уникальным для каждого конкретного проекта. Весомая часть литературы по данной теме предполагает работу по водопадной модели разработки и эта информация не так актуальна в наше время. Это не значит, что в гибких методологиях не бывает тест-планов. Даже в Agile необходимо предварительное планирование для структурирования работы, распределения ресурсов и планирования - по крайней мере, на высоком уровне - процесса выпуска на ближайшие месяцы. Но итерация за итерацией, а часто и день за днем, общий план постоянно корректируется с учетом событий и новой информации, которая появляется на свет. Планирование - это непрерывное обучение, а не задача с конечным результатом.
В гибких методологиях всё чаще говорят о концепции одностраничного тест-плана, а в случае необходимости дополнений и уточнений просто создаются ссылки на внешние страницы/документы. Такой план может быть и в гугл-таблицах, в виде дашборда, mind map, и как вам самим вздумается. Тест-план призван отвечать на те вопросы, ради которых его создают. Порой весомую часть пользы от данной активности можно получить на этапе самого планирования и составления плана, а не от самого документа. Если команда понимает, что никакой практической “боли” этот документ и его создание не решает, на него нет времени, то можно прекрасно обойтись и без его формализации, т.к. в некоей словесной форме он всё равно будет существовать всегда.
Виды тест-планов:
продукт имеет множество релизов или итераций, между которыми сохраняется общая информация, которую нет смысла повторять;
различные тестовые команды работают над одним продуктом, выполняя различные задачи, которые необходимо объединить в рамках одного документа;
План приемочных испытаний (Acceptance Test Plan, ПСИ): план приемочного тестирования отличают от обычного плана тестирования факторы, которые приводят к принятию бизнес-решения. План приемочного тестирования - это один из жизненно важных документов, который содержит руководство по выполнению приемочного тестирования для конкретного проекта. Пишется на основе бизнес-требований (Business Requirements). Ревью этого плана обычно выполняется by Managers/Business Analysts/Customers.
Источники:
Доп. материал:
“В зависимости от размеров команды, сложности продукта, количества зависимостей и строгости критериев качества эти вопросы могут быть иными. Если процесс тестирования имеет большое количество зависимостей, например разные команды должны выполнять разные этапы тестирования в строго определенном порядке - это необходимо фиксировать. Без этого ты не только не сможешь планировать работу команд, но и несколько раз выстрелишь себе в ногу, когда команды будут блокировать друг друга из-за того, что заранее не проговорили зависимости. Чем более комплексным является объект тестирования (и как результат само тестирование), тем более подробного описания требует методология тестирования, применяемые подходы и практики - просто за счёт увеличения объема того, что необходимо проверить. Без этого сложно оценивать объемы работ, давать эстимейты и строить планы по релизам. Чем более точно и строго необходимо оценивать уровень качества, тем более детально должны быть описаны критерии прохождения тестирования, ключевые метрики и `ы. Потому что без их формализации нельзя будет однозначно оценить результаты тестирования. Люди, находящиеся за пределами команды тестирования (а иногда и команды разработки в целом) хотят понимать, что вообще происходит на этапе тестирования и как обеспечивается качество продукта. Иногда это связано с регуляторикой отрасли, иногда для согласования объемов работы с заказчиком, иногда из-за высокой степени рисков или просто потому, что работа этих людей напрямую зависит от результатов процесса обеспечения качества.“ (с)
Мастер Тест-План (): “Главный план тестирования (master test plan, project test plan): План тестирования, обычно охватывающий несколько уровней тестирования.” (ISTQB). Это может быть как единственный базовый план, так и главный в иерархии нескольких планов, самый статичный и высокоуровневый. Нужен когда:
Детальный Тест-план (Phase Test plan): “Уровневый план тестирования (level test plan): План тестирования, обычно относящийся к одному уровню тестирования.” (ISTQB). Детальный план составляется на каждый релиз/итерацию или для каждой команды в рамках проекта и является динамическим, т.е. может претерпевать изменения по необходимости. Его основная цель - кратко и доходчиво отразить задачи тестирования. Детальных планов может быть несколько для отдельных модулей ПО или команд тестирования. Кроме того, могут быть созданы планы для отдельных уровней тестирования (Level Test Plan) или видов тестирования. В Agile проектах могут быть планы итерационного тестирования () для каждой итерации;
Примеры: , ;
