четверг, 12 июня 2008 г.

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

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


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


Рекомендации по написанию Тест Плана

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

  1. TestPlanTemplate_RUP
  2. TestPlanTemplate_IEEE_829

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

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

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

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


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

Чаще всего на практике приходится сталкиваться со следующими видами тест планов:

  • Мастер Тест План (Master Plan or Master Test Plan)
  • Тест План (я его называю детальный тест план)

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

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


Рецензия и Утверждение

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

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

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


Вывод

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



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

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

Анонимный комментирует...

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

Alexey Bulat комментирует...

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

Анонимный комментирует...

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

Анонимный комментирует...

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

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

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

Kirill комментирует...

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

Алексей Булат комментирует...

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

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

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

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

M_a_r_i комментирует...

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

Анонимный комментирует...

сильно напоминает http://www.protesting.ru/testing/plan.html

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

Алексей Булат комментирует...

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

Анонимный комментирует...

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

Алексей Булат комментирует...

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

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

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

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

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

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

Условия копирования публикаций:

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