Как составить план испытаний

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Наверх

Обзор

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

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

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

Следующие рекомендации помогают подготовить и сформулировать требования для теста, риски, приоритеты и стратегии теста.

Подготовка требований для теста

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

• Требование должно относиться к наблюдаемой и измеряемой величине. Если требование относится к величине, которую
  нельзя наблюдать или измерить, то невозможно будет определить, выполнено ли требование.
• Требования варианта использования или вспомогательные требования не связаны однозначно с требованиями для теста.
  Часто варианты использования представляют более одного требования для теста, а вспомогательные требования могут
  представить одно требование, несколько требований или вообще ни одного (например, требования, относящиеся к
  маркетингу или созданию пакетов).

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

Требования для функциональных
тестов

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

Требования для
тестов производительности

Требования по производительности возникают на основе изучения поведения, связанного с производительностью целевого
объекта тестирования. Обычно производительность оценивается в единицах времени ответа и/или использования ресурсов в
разных условиях, а именно:

• различная нагрузка и/или состояние системы
• различные варианты использования
• различные конфигурации

Требования по производительности описаны в вспомогательных спецификациях. При работе с этими материалами обратите
особое внимание на следующее:

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

Каждый из этих моментов спецификации должен быть отражен как минимум в одном требовании.

Требования для тестов
надежности

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

При работе с этими материалами обратите особое внимание на следующее:

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

Каждый из этих моментов должен быть отражен как минимум в одном требовании.

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

В следующих разделах описаны способы определения приоритетов тестов.

Оценка риска и
определение приоритетов в тестировании

Определение требований теста — это только часть подготовки к тестированию. Также необходимо определить приоритеты и
очередность выполнения работы. Это этап необходим по следующим причинам:

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

В оценке рисков и определении приоритетов тестирования можно выделить три момента:

• Оценка риска
• Определение профайла заданий
• Определение приоритета теста

Для каждого из этих моментов далее приведены соответствующие рекомендации.

Оценка риска

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

Начните с описания степени риска, используя следующие обозначения:

• H — неприемлемо высокий риск. Серьезный резонанс для компании. Компания потерпит серьезные убытки, может быть
  привлечена к ответственности или безвозвратно потеряет репутацию.
• M — средний риск, приемлемый, но нежелательный. Минимальный резонанс для компании, компания понесет убытки, но не
  будет привлечена к ответственности и не потеряет репутацию.
• L — приемлемый невысокий риск. Минимальный резонанс для компании или вообще никакого, компания понесет минимальные
  убытки и не будет привлечена к ответственности. Репутация компания не пострадает.

После этого составьте список всех вариантов использования и компонентов целевого объекта тестирования. Для каждого
варианта использования и компонента укажите степень риска и краткое обоснование.

Оценка риска может выполняться в трех проекциях:

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

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

Далее оценка риска в этих трех проекциях описана более подробно.

Последствия

Для оценки риска по последствиям выберите условие, событие или действие и попробуйте определить его воздействие.
Задайте вопрос:

«Что произойдет, если ___________?»

Пример:

• «Что произойдет, если при установке программного обеспечения закончится место на диске?»
• «Что произойдет, если если соединение с Internet будет утеряно в ходе транзакции запроса?»
• «Что произойдет, если если соединение с Internet будет утеряно в ходе транзакции оплаты?»
• «Что произойдет, если пользователь введет непредвиденное значение?»

Ниже приведена соответствующая таблица:

Причина

Оценка риска по причинам противоположна оценке по последствиям. Начните с того, что укажите нежелательное событие или
состояние, и определите набор событий, которые могут к нему привести. Задайте вопрос:

«Как могло произойти ___________ ?

Пример:

• «Как могло произойти то, что не все файлы были скопированы в систему, и не все записи реестра были созданы?»
• «Как могло произойти то, что транзакция не была отражена в главной базе данных?»
• «Как могло произойти то, что в счете отражена только часть записей базы данных, отвечающих заданным критериям?»

Ниже приведена соответствующая таблица:

Вероятность

Оценка риска по вероятности позволяет определить вероятность отказа варианта использования или компонента. Обычно
вероятность рассчитывается по внешним факторам, таким как:

• Частота отказов
• Скорость изменений
• Сложность
• Источник / автор

Отметим, что при работе с этой проекцией риска, показатели факторов риска связаны с вероятностью отказа, а не с
последствиями отказа, как это было при оценке риска по причинам и последствиям.

Эти факторы и вероятность отказа связаны между собой, как показано ниже:

Пример:

• Установка нового программного обеспечения
• «Были обнаружены изъяны в компонентах, применяемых для реализации вариантов использования 1, 10 и 12, а наши
  заказчики запросили много изменений в вариантах 14 и 19.»

Ниже приведена соответствующая таблица:

Определение операционного профайла

Далее необходимо определить операционный профайл, с тем чтобы оценить риски и определить приоритеты тестов.

Начните с описания уровня операционного профайла, используя следующие обозначения:

• H — очень частое использование, много раз в течение заданного интервала времени или многими субъектами или
  вариантами использования.
• M — частое использование, несколько раз в течение заданного интервала времени или несколькими субъектами или
  вариантами использования.
• L — нечастое использование, малое число субъектов или вариантов использования.

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

• число раз, которое ОДИН субъект (или вариант использования) применяет вариант использования (или компонент) в
  течение заданного времени
• число субъектов (или вариантов использования), работающих с вариантом использования (или компонентом)

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

После этого составьте список всех вариантов использования и компонентов целевого объекта тестирования. Определите
операционный профайл для каждого элемента списка и обоснуйте это значение. В оценке может помочь документ Рабочий продукт: документ анализа рабочей нагрузки.

Примеры:

• Установка нового программного обеспечения
• Заказ предметов из электронного каталога
• Запрос клиентов о выполнении их электронного заказа
• Окно выбора элемента

Определение приоритета теста

Наконец необходимо определить приоритеты тестов.

Начните с описания степени приоритета теста, используя следующие обозначения:

• H — тестирование необходимо
• M — тестирование следует выполнить, но после выполнения всех элементов H
• L — тестирование может выполняться, но только после тестирования всех элементов H и M

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

При определении приоритета тестов примите во внимание следующее:

• индикатор величины риска, указанный ранее
• операционный профайл, указанный ранее
• описания субъектов (есть ли у них опыт, готовы ли устранять ошибки)
• обязательства по контракту (будет ли принят целевой объект тестирования, если какой-либо вариант использования или
  компонент не будут поставлены)

Ниже перечислены основные принципы определения приоритетов:

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

Примеры:

• Установка нового программного обеспечения
• Заказ предметов из электронного каталога
• Запрос клиентов о выполнении их электронного заказа
• Окно выбора элементов

Если для указания приоритета используется наибольшее значение:

Если для указания приоритета используется наибольшее значение какого-либо одного фактора (риск):

Если для определения приоритета учитывается вес факторов:

В таблице H = 5, M = 3, L = 1. Общее взвешенное значение свыше 30 — это элемент тестирования с высоким приоритетом, от
20 до 30 включительно — со средним приоритетом, и ниже 20 — с низким приоритетом.

Стратегия тестирования

Стратегия тестирования описывает общие подходы и цели какого-либо аспекта тестирования.

Хорошая стратегия тестирования включает следующее:

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

Тип теста и цели

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

Примеры:

«Функциональный тест. Функциональный тест, посвященный проверке выполнения указанных вариантов использования,
реализованных в целевом объекте тестирования, в его пользовательском интерфейсе.»

«Тест производительности. Тест производительности системы, посвященный измерению времени ответа системы в вариантах
2, 4 и с 8 по 10. В этих тестах нагрузка создается одним субъектом, выполняющим эти варианты использования, и
никакая другая нагрузка при этом на тестовую систему не возлагается.»

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

Этап тестирования

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

Методика

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

Пример:

Функциональный тест:

• Для каждого потока событий в варианте использования определяется представительный набор транзакций, каждый из
  которых относится к действиям, выполняемым субъектом в ходе работы с вариантом использования.
• Для каждой транзакции будут разработаны хотя бы два тестовых набора, первый из которых будет отражать
  позитивное условие, а второй — отрицательное (неприемлемое) условие.
• В первой итерации будут тестироваться варианты использования с 1 по 4 и 12, а именно:
  • Вариант использования 1:
    • Вариант использования 1 начинается с того, что субъект уже вошел в систему и работает с главным
      окном, и заканчивается, когда пользователь выбирает действие Сохранить.
    • Каждый тестовый набор будет реализован и выполнен с помощью Rational Robot.
    • Проверка выполнения и оценка результатов для каждого тестового набора будет выполнена следующим
      способом:
      • Выполнение сценария теста — были ли все тестовые сценарии выполнены полностью и
        успешно?
      • Способы проверки показа окон и данных объектов должны будут проверить, что главные окна
        системы будут показаны, а данные записаны и отображены целевым объектом тестирования в
        ходе теста.
      • Будет изучена база данных целевого объекта тестирования (Microsoft Access), сначала до
        теста, потом после теста, в ходе чего будет проверена правильность данных, измененных в
        ходе теста.

Тест производительности:

• Для каждого варианта использования будет реализован и выполнен представительный набор транзакций, указанный в
  документе анализа рабочей нагрузки, в Rational Suite PerformanceStudio (сценарии vu) и Rational Robot (сценарии
  GUI).
• В тестах и плане выполнения будут реализованы как минимум три нагрузки, включая следующие:
  • Перегрузка: 750 пользователей (15 % руководство, 50 % отдел продаж, 35 % отдел маркетинга)
  • Повышенная нагрузка: 350 пользователей (10 % руководство, 60 % отдел продаж, 30 % отдел маркетинга)
  • Расчетная нагрузка: 150 пользователей (2 % руководство, 75 % отдел продаж, 23 % отдел маркетинга)
• В тестовых сценариях для выполнения всех транзакций предусмотрены соответствующие таймеры, которые измеряют
  время ответа, например, общее время транзакции (согласно указанному в документе анализа рабочей нагрузки) и
  времена основных этапов транзакции или процесса.
• Продолжительность рабочей нагрузки, создаваемой тестовыми сценариями, составляет один час (если не оговорено
  противное в документе анализа рабочей нагрузки).
• Проверка выполнения и оценка результатов для каждого прогона теста (с указанной нагрузкой) будет выполнена
  следующим способом:
  • Выполнение теста будет отслеживаться по гистограммам состояний (для проверки правильности обеспечения
    требуемой нагрузки в ходе теста)
  • Выполнение сценария теста — были ли все тестовые сценарии выполнены полностью и успешно?
  • Запись и оценка времени ответа будет представлена в следующих отчетах:
    • Процентные соотношения производительности
    • Время ответа

Критерии завершения

Критерии завершения формулируются для двух целей:

• определить, соответствует ли качество продукта поставленным требованиям
• определить, была ли успешно выполнена программа тестирования

Формулировка критериев завершения должна включать следующие элементы:

• измеряемые функция, поведение или условие
• способ измерения
• критерии или степень соответствия измерению

Пример 1

• Все запланированные тестовые наборы были выполнены
• Все выявленные изъяны были устранены в той степени, в какой это было необходимо
• Все запланированные тестовые наборы были выполнены повторно, при этом все выявленные изъяны были устранены в той
  степени, в какой это было необходимо, и никаких новых изъянов выявлено не было

Пример 2

• Все приоритетные тестовые наборы были выполнены.
• Все выявленные изъяны были устранены в той степени, в какой это было необходимо.
• Все изъяны серьезности 1 или 2 были устранены (со статусом устранен или отложен).
• Все приоритетные тестовые наборы были выполнены повторно, при этом все выявленные изъяны были устранены в той
  степени, в какой это было необходимо, и никаких новых изъянов выявлено не было.

Пример 3

• Все запланированные тестовые наборы были выполнены.
• Все выявленные изъяны были устранены в той степени, в какой это было необходимо.
• Все изъяны серьезности 1 или 2 были устранены (со статусом подтвержден или отложен).
• Все приоритетные тестовые наборы были выполнены повторно, при этом все выявленные изъяны были устранены в той
  степени, в какой это было необходимо, и никаких новых изъянов выявлено не было.

Особые рекомендации

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

• ресурсы персонала (например, доступность или потребность в дополнительных ресурсах для поддержки или участия в
  тесте)
• ограничения, например, доступность или ограничения оборудования, или потребность в специальном оборудовании
• особые требования, например, расписание тестов или доступ к системам

Примеры:

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

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

1. Мастер Тест
   План
   (Master Plan or Master Test Plan)

2. Тест План (Test Plan), назовем егодетальный тест план)

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

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

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

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

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

• Ведущий тестировщик

• Тест менеджер (менеджер по качеству)

• Руководитель разработки

• Менеджер Проекта

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

Вывод

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

Тестовый случай (Test Case)

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

Под тест кейсом понимается структура
вида:

Action >
Expected Result
> Test Result

Пример:

Action	Expected Result	Test Result (passed/failed/blocked)
Open page «login»	Login page is opened	Passed

Виды Тестовых Случаев

Тест кейсы разделяются по ожидаемому
результату на позитивныеинегативные:

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

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

Структура Тестовых Случаев (Test Case Structure)

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

Каждый тест кейс должен иметь 3 части:

PreConditions	Список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
Test Case Description	Список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям
PostConditions	Список действий, переводящих систему в первоначальное состояние (состояние до проведения теста — initial state)

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

Пример тест
кейса:

do A1, verify B1

do A2, verify B2

do A3, verify B3

В приведенном примере конечная проверка
— В3. Это значит, что именно она является
ключевой. Значит, A1 и А2 — это действия
приводящие систему в тестопригодное
состояние. А В1 и В2 — условия того, что
система находится в состоянии пригодном
для тестирования. Таким образом имеем:

Action	Expected Result	Test Result (passed/failed/blocked)
PreConditions
do A1	verify B1
do A2	verify B2
Test Case Description
do A3	verify B3
PostConditions

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

Теперь ответим на вопрос: «Почему
данное разбиение удобно использовать?»

Ответ: конечная проверка одна, т.е. в
случае если тест провален (test failed)
будет сразу ясно из-за чего. Т.к. если
провальными окажутся проверки В1 и/или
В2, то тест кейс будет заблокирован (test
blocked), из-за того, что функцию не возможно
привести в тестопригодное состояние
(состояние пригодное для проведения
тестирования), но это не значит, что
тестируемая функция не работает.

Action	Expected Result	Test Result (passed/failed/blocked)
PreConditions
do A1	verify B1	passed
do A2	verify B2	failed
Test Case Description:
do A3	verify B3	blocked
PostConditions

1. No category

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

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

Из чего состоит Тест План

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

Компоненты, которые должны тестироваться

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

Раздел «Характеристики и свойства, которые не должны тестироваться»

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

В раздел «План проведения испытаний»

вы можете включить такие темы:

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

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

Если тест-план требует утверждения или согласования с определенными организациями/лицами, то сделать это нужно своевременно. Нарушать сроки тестирования нельзя, проект испытания должен проводиться по установленному плану и выполненная работа должна быть сдана заказчику строго в срок.