К основному контенту

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

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 понятия как одно и тоже. Поэтому, прежде чем выполнять задание на составление тест – плана или тестовой модели, лучше уточните, что именно они понимают под этим понятием.

Комментарии

  1. Спасибо за разбор пунктов в тест плане, с 7 ссылки только нашел вас, теперь +1 читатель блога)

    ОтветитьУдалить
  2. Добавою правда что мне не хватило разбора понятий "test items" и "environmental need", я понимаю что по переводу можно понять, но вдруг я суть какую-то упустил. Собственного по поисках пояснительной бригады пунктов тест плана я тут и оказался)...

    ОтветитьУдалить
  3. здесь хороший иллюстративный пример модели https://habr.com/ru/company/jugru/blog/506048/

    ОтветитьУдалить

Отправить комментарий

Популярные сообщения из этого блога

Дымовое, критического пути и расширенное тестирование

Из приведенной ранее классификации тестирования (в статье " С чего начинать изучение тестирования? Конечно же с методов! ") нам осталось рассмотреть «по степени важности тестируемых функций». Но, на этом теория еще не заканчивается) Итак, по степени важности тестируемых функций разделяют следующие виды: - «Дымовое» (smoke) - тестирование, которое состоит из минимального набора тестов на явные ошибки. Дымовое тестирование на начальном этапе выявляет основные критические дефекты. Исходя из того, что данные проверки практически всегда одинаковы и редко претерпевают изменениям, целесообразно будет их автоматизировать. Ежедневная сборка продукта и smoke тестирование являются передовыми практическими методами. Программу, не проходящую "дымовой тест", не имеет смысла отдавать для более глубокого тестирования. - Критического пути ( critical path test ) — основной тип тестовых испытаний, во время которого значимые элементы и функции приложения проверяются н...

Советы для молодых тестировщиков или как составлять тест - кейс =)

Тест (test) представляет собой набор операций, предназначенных для получения одного или большего числа ожидаемых результатов в некоторой программной системе. Тест-кейсы должен помочь тестировщику (даже начинающему) провести проверку продукта без ознакомления со всей документацией. В тест – кейсе желательно избегать зависимостей от других тест – кейсов. Тест кейс в основном состоит из * Основных параметров - id (номер) - уникальный идентификатор тест-кейса. Его удобно использовать для одинакового понимания, о какой проверке идет речь (например, дать ссылку в баге). - Автор – имя и фамилия тестировщика, который написал тест – кей. - Название — краткое описание сути проверки. - Предусловие – предварительные шаги. - Шаги – что нужно сделать, чтобы что-то получить. - Ожидаемый результат – тот результат, который соответствует документации или здравому смыслу =). - Фактический результат – то, что получилось в итоге действия в шаге. - Постусловия ...