Необходимо обозначить, что помимо аналитики и тестирования спецификации к проекту на первом этапе также создаются высокоуровневые документы по тестированию продукта. К ним можно отнести тест-план и тест-стратегию. Начнем с первого.
Тест план (Test Plan) — это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.
Данный документ обычно создаётся тестировщиком, либо руководителем команды тестирования.
Такой артефакт (документ) позволяет:
- Обозначить сроки тестирования;
- Обозначить ресурсы тестирования (временные, человеческие, технологические);
- Определить тестовое покрытие и метрики тестирования;
- Обозначить роли участников команды и их ответственности.
Согласно международному стандарту IEEE 829, тест-план должен содержать следующие разделы (ниже приведены не все разделы из стандарта):
1. Введение. Описание, что из себя представляет документ, для чего он предназначен;
2. Функции, которые будут протестированы;
3. Функции, которые не будут протестированы;
4. Тестовые единицы - более детальное описание тестируемых функций. Тут указывается объем тестирования функции и при необходимости проводится декомпозиция функции;
5. Тестовые подходы и тестовые техники, которые будут использоваться при тестировании;
6. Критерии тестирования (например, критерии начала/завершения и приостановки тестирования);
7. Ресурсы. Описываются человеческие, временные и технологические ресурсы;
8. Расписание — календарь с описанием основных этапов тестирования и обозначение контрольных точек, может использоваться диаграмма Ганта;
9. Роли участников проекта и их ответственности;
10. Оценка рисков — описание основных рисков, которые могут возникнуть в процессе выполнения тестирования;
11. Документация — описание документации, которая будет использоваться в процессе выполнения тестирования (баг-репорты, чек-листы, тест-кейсы);
12. Метрики — числовые характеристики показателей качества, они позволяют оценить прогресс тестирования;
13. Согласования — указываются лица, ответственные за принятие результатов тестирования, а также принимающие решение о переходе на следующий этап разработки или начале новой итерации.
Наличие тест-плана, а также его содержание зависят от особенностей проекта и компании. Зачастую тест-план содержит не все перечисленные разделы, а только ту информацию, которая используется в работе и необходима команде, либо заказчику.
Также имеется вариативность и в количестве таких тест-планов. Команда может иметь один основной тест-план на весь проект (мастер тест-план). Может иметь мастер тест-план плюс тест-планы для каждых крупных модулей/функциональностей приложения. Также могут быть локальные тест-планы (например, тест-план на спринт или тест-план на неделю/месяц).
Тем самым главное понять, что необходимый минимум это наличие мастер тест-плана. Дальнейшая его декомпозиция и уточнение хоть и необязательно, но явно упрощает дальнейший процесс тестирования. К примеру, без локальных тест-планов совершенно будет непонятно:
- Кто будет тестировать определенную функциональность в рамках спринта?
- Что необходимо протестировать в рамках спринта и в каком объеме?
- Какие критерии успешности для текущего MVP?
И так далее.
Рекомендую изучить последовательность составления тест-плана, которая отлично изложена в данной статье:
В качестве готовых примеров тест-планов я бы посоветовал данные варианты, так как в русскоязычном интернете ничего путного в открытом доступе не нашёл:
