Тест план и тестовая модель - что это?

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

В стандарте IEEE 829 перечислены пункты, из которых должен состоять тест-план: 

1) Test plan identifier (идентификатор); 

2) Introduction (описание/цель) - Предельно краткое описание цели разработки приложения (частично это напоминает бизнес-требования); 

3) Features to be tested (Области, подвергаемые тестированию) - Перечень функций и/или нефункциональных особенностей приложения, которые будут подвергнуты тестированию. В некоторых случаях здесь также приводится приоритет соответствующей области.

4) Features not to be tested (Области, не подвергаемые тестированию) - Перечень функций и/или нефункциональных особенностей приложения, которые не будут подвергнуты тестированию. Причины исключения той или иной области из списка тестируемых могут быть самыми различными — от предельно низкой их важности для заказчика до нехватки времени или иных ресурсов. Этот перечень составляется, чтобы у проектной команды и иных заинтересованных лиц было чёткое единое понимание, что тестирование таких-то особенностей приложения не запланировано — такой подход позволяет исключить появление ложных ожиданий и неприятных сюрпризов; 

5) Approach (стратегия и подходы)- Описание процесса тестирования с точки зрения применяемых методов, подходов, видов тестирования, технологий, инструментальных средств и т.д.; 

6) Item pass/fail criteria - Этот раздел включает такие подразделы, как приёмочные критерии, критерии качества — любые объективные показатели качества, которым разрабатываемый продукт должен соответствовать с точки зрения заказчика или пользователя, чтобы считаться готовым к эксплуатации; 

7) Suspension criteria and resumption requirements (критерии входа и выхода, приостановки и возобновления) – Критерии входа - перечень условий, при выполнении которых команда приступает к тестированию. Наличие этого критерия страхует команду от бессмысленной траты усилий в условиях, когда тестирование не принесёт ожидаемой пользы.

 Критерии приостановки тестирования (suspension criteria) — перечень условий, при выполнении которых тестирование приостанавливается. Наличие этого критерия также страхует команду от бессмысленной траты усилий в условиях, когда тестирование не принесёт ожидаемой пользы.

Критерии возобновления тестирования (resumption criteria) — перечень условий, при выполнении которых тестирование возобновляется (как правило, после приостановки). 

Критерии выхода (exit criteria) — перечень условий, при выполнении которых тестирование завершается. Наличие этого критерия страхует команду как от преждевременного прекращения тестирования, так и от продолжения тестирования в условиях, когда оно уже перестаёт приносить ощутимый эффект; 

8) Test deliverables (результаты тестирования); 

9) Testing tasks (задачи тестирования); 

10) Responsibilities (ответственность) - Перечень необходимых ролей (например, «ведущий тестировщик», «эксперт по оптимизации производительности») и область ответственности специалистов, выполняющих эти роли; 

11) Staffing and training needs (необходимые кадры и их обучение); 

12) Schedule - Фактически это календарь, в котором указано, что и к какому моменту должно быть сделано. Особое внимание уделяется «ключевым точкам», к моменту наступления которых должен быть получен определенный результат; 

13) Risks and contingencies (риски и непредвиденные случаи) - Перечень рисков, которые с высокой вероятностью могут возникнуть в процессе работы над проектом. По каждому риску даётся оценка представляемой им угрозы и приводятся варианты выхода из ситуации; 

14) Approvals (утверждение тест - плана). 

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

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

Ответственным за создание тест-плана, как правило, является ведущий тестировщик.

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

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

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

На просторах интернета очень мало конкретной информации о таком понятии как тестовая модель. Достаточно подробно и понятным языком описывает Дмитрий Тищенко в своем блоге (http://www.a1qa.ru/blog/test-policy-upravlenie-testovoy-modelyu/).

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