План тестирования программы пример

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

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

1. Test Plan Template RUP
2. Test Plan Template IEEE 829

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

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

Видео 9. Как написать тест-план

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

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

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

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

Тестировщик с нуля / Урок 5 / Тест план

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

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

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

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

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

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

Источник: testirovanie24.ru

План тестирования программного обеспечения

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

Пришлось мне обратиться к стандартам, чтобы составить план тестирования. Изучив рекомендации методологии RUP (Rational Unified Process) и стандарт IEEE 829 я понял, что я сторонник RUP и поэтому план тестирования начал составлять, отталкиваясь от их рекомендаций.

При написании плана тестирования и изучения данных, которые в нём должны присутствовать, у меня сложилось впечатление, что обе методологии или оба стандарта (кому как угодно) привязываются к каскадной методологии разработки программного обеспечения (далее ПО). Возник вопрос, а что же делать тем, кто работает по гибкой методологии разработки ПО (далее Agile) включая нас?

Многие могут воскликнуть: тут план не нужен! Вы не правы. План тестирования нужен в любом случае, ведь в нём описан весь процесс тестирования программного обеспечения (тут не подразумевается подробная, пошаговая инструкция для «несмышлёнышей»). И данная информация полезна, а в некоторых случаях и важна, для нового человека, который включается в проект и особенно тестировщику.

Я решил написать план так как рекомендуют, не обращая внимания на привязку к методологии разработки ПО. Составив план тестирования, изучив свой труд и осмыслив написанное я пришёл к выводу, что план применим и к Agile, для этого достаточно исключить из плана сроки проведения тестирования — это меня смущало всё время при написании плана тестирования. Также из плана я исключил риски.

Я считаю, что риски в план можно вносить при проектной деятельности и каскадной методологии разработки ПО, а при Agile нам они в плане не нужны. Нам – это означает команду, в которой я работаю. Вам возможно описание рисков понадобится.

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

Эпилог

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

Файлы для скачивания

Приложенный архив включает в себя составленные мной планы тестирования, а также шаблоны RUP и IEEE 829. Планы, составленные мной, не являются идеалом рекомендуемым для всех, поэтому вы можете их кардинально переделать под себя.

Источник: victorz.ru

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

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

Что бы сделал я? Взял бы пару листов А3 и написал:
— Что вообще можно тестировать — вообще все знакомые слова — юзабилити, орфографию, логику, регрессию, безопасность, нагрузочное тестирование, боевой сервер, тестовый стенд. Слов 20.
— Как я могу тестировать: пецкать руками, найти рабов бета тестеров, написать автотесты, записать сценарии, столкнуть работу на коллегу,
— Когда я буду это делать? Ночами, по утрам, 4 часа в день, срок — ближайший месяц, день, год. Исходя из сроков вычеркнуть нереальное из первых двух пунктов.
— Узнать, на кой это все надо. Чего от меня ждут. Может ждут сто багов. Может ждут качество. Может ждут отчет.

С учетом этой строки — пересортировать все, что выше.
— Представить себе конечный результат. Список багов? Где этот список? На листочке? В трекере? Налаженный процесс разработки и тестирования? Как выглядит налаженность? Отчет?

В экселе, в ворде? Как выдадут бабло? На карту, налом, вебманями?

#2 clipsa

Отправлено 15 сентября 2015 — 11:14

Не следует заставлять тестировщиков тестировать быстрее. Что может быть хуже испуганных, усталых, цинично настроенных тестировщиков?
——————
Хорошо, когда человек заводит баги . Плохо, когда баги заводят человека (с)
——————
Проект для начинающих тестировщиков Хомячки

Источник: software-testing.ru