Что обычно включает тест-план?
Что проверяют
Отличаете ли вы тест-план от набора тест-кейсов и знаете ли, что такое критерии входа и выхода.
Как отвечать
Тест-план это документ о том, как будет организовано тестирование, а не список проверок. По классической структуре (IEEE 829 и его практические наследники) в нём есть:
- объект и область: что тестируем, какие версии, какие сборки;
- функции, подлежащие тестированию (features to be tested): перечень функциональности в зоне проверки, обычно со ссылками на требования и с приоритетами;
- функции, не подлежащие тестированию (features not to be tested): не менее важный раздел, потому что фиксирует осознанно принятый риск, а не забытые области;
- подход: уровни и виды тестирования, ручное и автоматизированное, инструменты;
- критерии входа (entry): при каких условиях тестирование начинается. Сборка развёрнута, дымовой набор прошёл, тестовые данные подготовлены;
- критерии выхода (exit): при каких условиях останавливаемся. Все запланированные кейсы выполнены, нет открытых дефектов уровня «блокирующий» и «критический», покрытие требований не ниже заданного, оставшиеся дефекты приняты;
- критерии приостановки и возобновления (suspension): когда тестировать бессмысленно, например упал дымовой набор или окружение недоступно;
- окружение, роли, расписание, риски и меры, отчётность.
Для отдельного прогона к этому добавляется критерий прохождения набора: сколько кейсов должно пройти и как считаются частично пройденные.
Важная оговорка: в гибких командах полноценный тест-план часто заменяют короткой тестовой стратегией и чек-листом на релиз. Хороший ответ содержит эту оговорку.
Где спотыкаются
Пересказывают содержимое тест-кейса вместо плана.
Не различают критерии входа и выхода.
Пропускают раздел о том, что не тестируется.
Формулируют критерий выхода как «все тесты прошли», без учёта известных дефектов и покрытия.