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

Предлагает тестовую стратегию

Определяет критерии качества

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

Что такое тест план?

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

• Кто Product Manager?
• Команда?
• Что мы будем делать?
• Что за приложение?
• Когда?
• Где брать детали?

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

Структура тест плана

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

1. Introduction – данный раздел содержит ответы на вопрос: Что мы будем делать? Зачем? Для какого клиента? Кто будет использовать продукт? Для чего будет использоваться продукт? Хочется отметить, что здесь нужно быть максимально конкретным, не нужно использовать общих фраз.
2. Scope of Work – в этом разделе содержится информация о том, какие компоненты и функции, нужно протестировать, а какие тестироваться не будут. Также, какое программное обеспечение нам понадобится?
3. Quality and Acceptance Criteria – здесь определяется критерии, по которым оценивается качество продукта и условия завершения тестирования.
4. Critical Success Factors – этот пункт отражает ответы на вопросы: что нужно, чтобы проект завершился успешно. Что необходимо для качественного тестирования (полноценный доступ в багтрекинговую систему, тест менеджмент систему, отсутствие задержек от команды разработки и тд.)
5. Risk Assessment — это самая важная секция, и она специфична для каждого проекта. Важно продумать риски, а не взять уже придуманный кем-то список. Следует описать все, что может пойти не так и добавить меры по предотвращению.
6. Resources – суда относятся все ключевые ресурсы, необходимые для проведения тестирования: команда, тулы, железо.
7. Test Documentation – в этом пункте содержит список проектных документов: Test plan, Test result report, Test cases, Bug reports. Также указывает: Ответственных и частоту их создания. Здесь же не забываем перечислить место хранения тест кейсов, тест планов и тд. (багтрекинг, облачные хранилища, сервер и т.п.)
8. Test Strategy – этот пункт содержит:

• Entry Criteria
• Test Methods (manual, automated)
• Test types (functional, installation, regression, new feature, compatibility, integration, localization, etc)
• Test levels (smoke, critical, extended)

1. Testing Schedule – здесь отражаются сроки проведения тестирования.

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

• Можно работать с шаблоном заказчика, такое бывает.
• Тест план должен обновляться!
• Удаляем устаревшие вещи.
• Давать корректное имя файлу (Не 1111.doc)
• Заполнять все свойства файла
• Обновлять все автозаполняемые поля
• Вставлять записи версий документа
• Согласовывать записи
• Поддерживать в актуальном состоянии

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

Зачем создавать тест план?

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

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

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

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

Как написать хороший тест план?

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

1. Проанализировать продукт

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

2. Разработка стратегии тестирования

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

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

3. Определить область действия

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

4. Разработка графика

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

5. Определите роли и обязанности

В хорошем тест плане четко перечислены роли и обязанности команды тестирования и менеджера команды. Раздел «Роли и обязанности» вместе с «графиком» рассказывает всем, что делать и когда делать.

6. Предвидеть риски

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

Тест план: пример

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

Тест план тестирования интернет сайта (type pdf, docx)

Источник статьи: http://veraksoff.info/test-plan/

Тестирование

Раздел: Тестирование > Тестовые Артефакты > Тест План (План тестирования)

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

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

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

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

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

1. Что надо тестировать?
   • описание объекта тестирования: системы, приложения, оборудования
2. Что будете тестировать?
   • список функций и описание тестируемой системы и её компонент в отдельности
3. Как будете тестировать?
   • стратегия тестирования, а именно: виды тестирования и их применение по отношению к объекту тестирования
4. Когда будете тестировать?
   • последовательность проведения работ: подготовка (Test Preparation), тестирование (Testing), анализ результатов (Test Result Analisys) в разрезе запланированных фаз разработки
5. Критерии начала тестирования:
   • готовность тестовой платформы (тестового стенда)
   • законченность разработки требуемого функционала
   • наличие всей необходимой документации
   • .
6. Критерии окончания тестирования:
   • результаты тестирования удовлетворяют критериям качества продукта:
     • требования к количеству открытых багов выполнены
     • выдержка определенного периода без изменения исходного кода приложения Code Freeze (CF)
     • выдержка определенного периода без открытия новых багов Zero Bug Bounce (ZBB)

ZBB = Zero Bug Bounce
После завершения фазы разработки новой функциональности, начинается фаза стабилизации, когда разработчики занимаются только исправлением дефектов. В какой-то момент, когда скорость исправления начинает превосходить скорость открытия новых, может наступить момент, когда у вас будет 0 открытых/активных дефектов (ZB — Zero Bugs). Именно тогда и можно сказать, что мы выходим на стадию — Zero-Bug Bounce. Начиная с этого момента каждый новый дефект проходит проверку, и если он не критичен для данного релиза, то он переносится на следующий. Если же дефект оказался критичным, то его придется исправить, что значит, что мы вышли из состояния ZB, и нам придется вернуться туда еще раз, пока мы, наконец, не удовлетворим все критерии готовности продукта к выпуску.

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

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

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

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

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

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

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

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

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

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

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

Вывод

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

Источник статьи: http://www.protesting.ru/testing/plan.html

0 0 голоса

Article Rating

Подписаться

авторизуйтесь

Уведомить о

новых последующих комментариях новых ответах на мои комментарии

Label

{} [+]

Имя*

Email*

Веб-сайт

Δ

Label

{} [+]

Имя*

Email*

Веб-сайт

Δ

0 Комментарий

Старые

Новые Популярные

Межтекстовые Отзывы

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