Как сделать тест план

Добавил пользователь Алексей Ф.
Обновлено: 04.10.2024

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

11.1. Тест-планы

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

На основании тест-требований составляются тест-планы - программы испытаний (проверки, тестирования) программной реализации системы. В отличие от тест-требований в тест-плане описываются конкретные способы проверки функциональности системы, т.е. то, как должна проверяться функциональность. Как правило, тест-план состоит из отдельных тестовых примеров, каждый из которых проверяет некоторую функцию или набор функций системы. Для каждого тестового примера однозначно определяется критерий успешного прохождения ( pass/fail criteria ), при помощи которого можно судить - соответствует ли поведение системы заданному в требованиях или нет (Рис 11.1).

Критерием качества тест-плана является покрытие (выполнение) всех требований к проверке правильности функционирования программной реализации. Желательной характеристикой тест-плана является проверка исполнения всех веток схемы программной реализации.

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

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

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

11.1.2. Возможные формы подготовки тест-планов

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

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

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

11.1.3. Сценарии

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

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

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

Так, неудачной ожидаемой реакцией при ручном тестировании была бы запись

Степень приемлемости здесь будет зависеть от терпеливости тестировщика, и обеспечить повторяемость тестирования будет затруднительно. Более удачной формой описания той же самой ожидаемой реакции будет

Ниже приведен пример описания тестового примера в виде сценария, предназначенного для ручного тестирования :

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

Сценарии тестирования для автоматического тестирования часто описывают на том или ином языке программирования. Например, методы в тестирующих классах Microsoft Visual Studio Team Edition представляют собой именно пошаговые описания действий, которые необходимо выполнить тестовому окружению для проведения тестирования. Возможна и более близкая к естественному языку форма подготовки тестовых примеров. Например, при тестировании логической функции с уровнем покрытия MC/DC и описании тестовых примеров на одном из диалектов Visual Basic Script возможно записать сценарий тест-плана в такой форме:

При такой форме представления сценарий каждого тестового примера состоит из последовательности вызовов функций (в данном случае функция всего одна), которые передают данные в среду тестирования.

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

Каждая методология или процесс пытаются навязать нам свои форматы оформления планов тестирования. Предлагаю вам, как пример, шаблоны тест планов от RUP (Rational Unified Process) и стандарт IEEE 829:

Test Plan Template RUP
Test Plan Template IEEE 829

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

стратегия тестирования, а именно: виды тестирования и их применение по отношению к тестируемому объекту

последовательность проведения работ: подготовка (Test Preparation), тестирование (Testing), анализ результатов (Test Result Analisys) в разрезе запланированных фаз разработки

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

Окружение тестируемой системы
Необходимое для тестирования оборудование и программные средства
Риски и их разрешение

Мастер Тест План (Master Plan or Master Test Plan)
Тест План (Test Plan, назовем его детальный тест план)
План Приемочных Испытаний (Product Acceptance Plan) - документ, описывающий набор действий, связанных с приемочным тестированием: стратегия, дата проведения, ответственные работники и т.д. (Шаблон плана приемо-сдаточных испытаний от RUP)

Явное отличие Мастер Тест Плана от просто Тест Плана в том, что мастер тест план является более статичным в силу того, что содержит в себе высокоуровневую (High Level) информацию, которая не подвержена частому изменению в процессе тестирования и пересмотра требований. Сам же детальный тест план, который содержит более конкретную информацию по стратегии, видам тестировании, расписанию выполнения работ, является "живым" документом, который постоянно претерпевает изменения, отражающие реальное положение вещей на проекте.

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

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

Ведущий тестировщик
Тест менеджер (менеджер по качеству)
Руководитель разработки
Менеджер Проекта

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

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

В рамках процесса тестирования (ISO/IEC/IEEE 29119-2) можно обозначить следующие активности, которые обычно выделяют в 4 группы:

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

В этой статье мы сфокусируемся на первой стадии процесса тестирования.

Планирование тестирования и контроль

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

Планирование тестирования начинается как только инициируется процесс тестирования на проекте и продолжается на протяжении всего проекта. В рамках этой активности, мы должны убедиться, что понимаем цели и задачи проекта\заказчика\пользователей, а так же связанные с этим риски. Результатом работы на данном этапе будет созданный план тестирования (Test Plan).

План тестирования (Test Plan) — документ, описывающий цели, подходы, ресурсы и график запланированных тестовых активностей. Он определяет объекты тестирования, свойства для тестирования, задания, ответственных за задания, степень независимости каждого тестировщика, тестовое окружение, метод проектирования тестов, определяет используемые критерии входа и критерии выхода и причины их выбора, а также любые риски, требующие планирования на случай чрезвычайных обстоятельств. [IEEE 829]

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

Активности в рамках планирования тестирования:

Определить объём работ, риски и цели тестирования:
- Мы должны понимать, что именно мы будем и не будем тестировать: какие программные продукты, компоненты и системы;
- Определить бизнес, продуктовые, проектные и технические риски и обработать их;
- Определить главные цели тестирования: Найти как можно больше дефектов; показать, что система удовлетворяет требованиям, атрибутам качества и т.д;
- На основе рисков и целей определить виды тестирования;
- Для каждого вида тестирования определить уровни, методы и техники тестирования;
Мониторинг и контроль тестирования:

Управление любыми активностями не заканчивается на их планировании.

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

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

Стадия планирования и контроля тестирования является крайне важной для всего процесса в целом. Ведь чем лучше мы спланируем нашу работу, тем с большей вероятностью сможем сделать её качественно.

На сегодня это всё.
В следующий раз мы познакомимся поближе со стадией анализа и дизайна тестирования.

Недавно прогулявшись по форумам и по ресурсам посвященным тестированию ПО, нашел определенный дефицит информации по планированию тестирования. Точнее информация есть, но не всегда в доступной форме. Постараюсь разжевать и объяснить на простом языке "Кто? Где? Когда?" занимается планированием и какая информация должна входить в тест план. Начнем с определения:

Тест план(Test Plan) - это документ описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.
1. что надо тестировать (объект тестирования: система, приложение, оборудование)
2. что будете тестировать (список функций и компонент тестируемой системы)
3. как будете тестировать (стратегия тестирования - виды тестирования и их применение по отношению к тестируемому объекту)
4. когда будете тестировать (последовательность проведения работ: подготовка, тестирование, анализ результатов, в разрезе запланированных фаз разработки проекта)
5. критерии начала и окончания тестирования
- Окружение тестируемой системы
- Необходимое для тестирования оборудование и программные средства
- Риски и их разрешение
- Мастер Тест План (Master Plan or Master Test Plan)
- Тест План (я его называю детальный тест план)
На мой взгляд явное отличие этих документов в том, что мастер тест план является более статичным в силу того, что содержит в себе High Level информацию, которая не подвержена частому изменению в процессе тестирования и пересмотра требований. Сам же детальный тест план, который содержит более конкретную информацию по стратегии, видам тестированияи, расписанию выполнения работ, является "живым" документом, который постоянно притерпевает изменения, отражающие реальное положение вещей на проекте.

В повседневной жизни на проекте может быть один Мастер Тест план и несколько детальных тест планов, описывающих отдельные модули одного приложения.
- Ведущий тестировщик
- Тест менеджер (менеджер по качеству)
- Руководитель разработки
- Менеджер Проекта
Каждый из перечисленных участников проекта, перед утверждением, проведет рецензию и внесет свои комментарии и предложения, которые помогут сделать Ваш тест план более полным и качественным.

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

Переработки и дополнения к статье смотрите на сайте ПроТестинг - Тест план

Автор: Aliaksei Bulat

11 комментариев:

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

Саша, спасибо за комментарий.
На счет разных тест планов дам тебе наводку. Есть 2 тест плана - Master Test Plan и просто Test Plan.
На сколько я понял, повозившись с интернетом и документацией, мастер тест план составляется для крупных проектов, где функционал разделен на несколько частей. И в нем все описано достаточно поверхностно High Level, а вот уже детализация начинается в конкретных тест планах. Но об этом я думаю еще немного дополнить статью. Вот.

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

Понравилось, как логично и чётко изложено.

С высот QA я спустился в низины QC, и написал вот такое дополнение - План тестирования должен быть внятным, четким, небольшим.

Не сочтите за спам или желание линки раскидать. Все по-делу. Как дополнение к основному тексту, но на более низком уровне.

Статья совершенно бесполезная. Если читатель откроет для себя что-то новое в этой статье то статья точно ему навредит. Моя рекомендация - сначала ответьте себе на вопрос - а зачем вам тестплан? Из своего же ответа на этот вопрос вы получите всю необходимую информацию о содержании тестплана. Если не можете ответить - не делайте тестплана, потеряете время даром, не доросли еще. Всем удачи, abbuk ;)

Кирилл, спасибо за то, что читает мой блог.

На счет навредит не навредит, посмотрим. Время нас рассудит.

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

С уважением,
Алексей

Спасибо вам большое за такую нужную информацию.

а там эта статья появилась куда раньше, чем здесь.

Ничего страшного. автор у статьи всёравно Я :)

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

Зачем нужен план тестирования?
- исходя из определения, для формального описания всего того, что надо протестировать, при каких условиях, на чем, кто будет тестировать и т.д.

Когда его нужно использовать?
- в процессе работы над проектом.

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

А не является этот план всего лишь бумажкой, отпиской, которую просто нужно сделать?
- Все зависит от строгости процессов в вашей команде/компании. Для кого-то это отписка, для кого-то артефакт, без которого быть невозможно.

Получается, что мы намечаем себе план о том, что и когда будем тестировать, каким способом. Спрашивается, зачем?
- Тут надо представлять себе сам процесс работы над проектом. При использовании формальных методологий, таких RUP - тест план это один из ключевых артефактов в тестировании. Его начинают писать на начальной фазе подготовки проекта. Уже там мы приблизительно определяем объем работ, виды тестирования, количество человек для тестирования, конфигурацию тествого стенда, критерии начала и окончания, некоторые риски и т.д. На следующих фазах мы дорабатываем тест план добавляя в него уже более подробную информацию. Вы спрашиваете: "Зачем все это?", - да чтобы ничего не упустить.

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

Читайте также: