Тест-план (test plan) - документ, который описывает цели тестирования, средства и график их достижения: что тестируется, как, кем, какими ресурсами и к какому сроку. ISO/IEC/IEEE 29119-3 определяет его как подробное описание целей тестирования, которые нужно достичь, и средств и графика их достижения. Тестовая стратегия (test strategy) в том же стандарте - часть тест-плана, которая описывает подход к тестированию для определённого проекта, уровня тестирования или вида тестирования.
Структуру обоих документов задаёт стандарт ISO/IEC/IEEE 29119-3, Software testing, Part 3: Test documentation. Его текущая редакция вышла в октябре 2021 года и заменила первую редакцию 2013 года. До серии 29119 документацию тестирования описывал стандарт IEEE 829, впервые опубликованный в 1983 году. Силлабус ISTQB Foundation Level (версия 4.0.1) использует ту же структуру в сокращённом виде.
Кратко
| Параметр | Значение |
|---|---|
| Тип | Документы управления тестированием |
| Действующий стандарт | ISO/IEC/IEEE 29119-3:2021, разделы 6 и 7 |
| Предыдущий стандарт | IEEE 829-2008, заменён серией ISO/IEC/IEEE 29119 |
| Уровень организации | Политика тестирования, организационные практики тестирования |
| Уровень проекта | Тест-план, в который входит тестовая стратегия |
| Отчёты на основе плана | Отчёт о состоянии тестирования, отчёт о завершении тестирования |
| Разработчик стандарта | ISO/IEC JTC 1/SC 7 совместно с IEEE Computer Society |
Какую задачу решает тест-план
Тестирование ограничено временем, людьми и окружениями и никогда не бывает полным: возможных проверок больше, чем можно выполнить. Кто-то решает, что тестируется, а что нет, какие риски принимаются и когда тестирование заканчивается. Без записанного плана эти решения принимаются неявно, разными людьми в разное время, и потом их никто не может проверить.
Тест-план фиксирует эти решения до начала тестирования и делает их видимыми для заинтересованных сторон: руководителя проекта, разработчиков, аналитиков, заказчиков. У него три назначения:
- согласование: заинтересованные стороны видят объём, риски, ресурсы и график и могут возразить до того, как работа сделана;
- контроль: ход тестирования сравнивается с планом, и отклонения видны;
- завершение: критерии выхода в плане определяют, когда тестирование уровня или релиза закончено.
История
| Дата | Событие |
|---|---|
| 18 февраля 1983 | IEEE 829-1983, Standard for Software Test Documentation: первый стандартный набор документов тестирования, в том числе тест-план |
| 16 декабря 1998 | IEEE 829-1998, пересмотр стандарта |
| 18 июля 2008 | IEEE 829-2008, Standard for Software and System Test Documentation: главный тест-план (master test plan) отделён от планов уровней тестирования (level test plans) |
| Сентябрь 2013 | Опубликованы ISO/IEC/IEEE 29119-1, -2 и -3; IEEE 829-2008 заменён |
| Октябрь 2021 | Вторая редакция ISO/IEC/IEEE 29119-3: понятие условий тестирования заменено моделями тестирования, организационный документ называется организационными практиками тестирования |
Уровни документации тестирования
ISO/IEC/IEEE 29119-3 группирует документы тестирования по уровню процесса тестирования, который их создаёт. Тест-план - основной документ среднего уровня.
Organizational level
| Test policy
| Organizational test practices
|
+-- Test management level (project, test level, test type)
| Test plan (includes the test strategy)
| Test status report
| Test completion report
|
+-- Dynamic test level
Test model specification, test case specification,
test procedure specification, test data and environment requirements,
readiness reports, test results, test execution log, test incident reportПолитика тестирования (test policy), в формулировке глоссария ISTQB, - документ верхнего уровня, который описывает принципы, подход и основные цели организации в отношении тестирования. Она действует для всех проектов и меняется редко.
Организационные практики тестирования (organizational test practices) описывают, как в организации в целом проводится тестирование: какие уровни и виды тестирования используются, какие техники, какие документы, какие критерии завершения. В редакции стандарта 2013 года этот документ назывался организационной тестовой стратегией (organizational test strategy).
Тест-план применяет политику и практики к определённому проекту, уровню тестирования или виду тестирования.
Главный тест-план и планы уровней
У проекта может быть один тест-план или несколько. IEEE 829-2008 ввёл деление на главный тест-план (master test plan), который охватывает планирование и управление тестированием на нескольких уровнях, и планы уровней тестирования (level test plans), каждый из которых описывает объём, подход, ресурсы и график одного уровня: компонентного, интеграционного, системного или приёмочного тестирования. ISO/IEC/IEEE 29119-3 сохраняет эту возможность: его тест-план можно написать для всего проекта, для одного уровня тестирования или для одного вида тестирования, например тестирования производительности.
Деление следует за распределением ответственности. Главный тест-план содержит то, что общее для всех уровней: риски проекта, заинтересованные стороны, общий график, порядок уровней и критерии перехода от одного к следующему. План уровня содержит то, что относится к уровню: объекты тестирования, техники, окружения, критерии входа и выхода уровня. Один план охватывает все уровни, когда их планирует и тестирует одна команда по одному графику. Отдельные планы уровней пишут, когда уровни тестируют разные команды, по разным графикам или с разными критериями выхода.
Состав тест-плана
ISO/IEC/IEEE 29119-3 (раздел 7.2) делит тест-план на части, перечисленные ниже. Стандарт определяет два вида соответствия: полное и адаптированное. Адаптированное соответствие позволяет приспособить документы и их содержание к условиям организации и проекта.
| Часть | Что в ней |
|---|---|
| Контекст тестирования | Проект и объекты тестирования, объём тестирования (что входит и что нет), базис тестирования |
| Допущения и ограничения | Условия, принятые как данность, и рамки проекта: сроки, бюджет, нормативные требования |
| Заинтересованные стороны | Кто заинтересован в тестировании, их роли и ответственность |
| Коммуникация | Как и как часто передаётся информация о тестировании, какие отчёты и шаблоны используются |
| Реестр рисков | Продуктовые и проектные риски, которые влияют на тестирование, с их уровнями |
| Тестовая стратегия | Подход к тестированию: см. ниже |
| Активности тестирования и оценки | Какие активности выполняются и какие трудозатраты им нужны |
| Персонал | Роли, люди, потребность в найме и обучении |
| График | Даты и вехи активностей тестирования |
Как у всех документов стандарта, у тест-плана есть и общая информация: идентификатор, выпускающая организация, кто утверждает документ, история изменений, статус, введение, ссылки и глоссарий.
Силлабус ISTQB Foundation Level (раздел 5.1.1) перечисляет типичное содержание тест-плана почти теми же словами: контекст тестирования, допущения и ограничения, заинтересованные стороны, коммуникация, реестр рисков, тестовый подход, бюджет и график.
Тестовая стратегия в составе тест-плана
Тестовая стратегия - часть плана, которая говорит, как проводится тестирование. Силлабус ISTQB называет соответствующую часть плана тестовым подходом (test approach) и перечисляет её типичное содержание:
- уровни и виды тестирования;
- техники тестирования;
- результаты тестирования (test deliverables): какие документы и отчёты создаются;
- критерии входа и критерии выхода;
- независимость тестирования: кто тестирует чью работу;
- метрики, которые собираются;
- требования к тестовым данным и тестовому окружению;
- отклонения от организационной политики и стратегии тестирования.
Каждый элемент выбирается по рискам проекта. Компонент с высоким продуктовым риском получает больше уровней тестирования, более строгие техники и более жёсткие критерии выхода, чем компонент с низким риском.
У термина «тестовая стратегия» два значения. В ISO/IEC/IEEE 29119-3 это часть тест-плана проекта. В обиходе, а также в прежних версиях стандарта и глоссария ISTQB, так называют и документ уровня организации, который действует для многих проектов. Редакция 29119-3 2021 года называет такой документ организационными практиками тестирования. Глоссарий ISTQB определяет тестовый подход как реализацию тестовой стратегии для определённого проекта.
Критерии входа и выхода
Критерии входа (entry criteria) - предусловия для начала активности тестирования. Критерии выхода (exit criteria) определяют, чего нужно достичь, чтобы активность считалась завершённой. Силлабус ISTQB (раздел 5.1.3) рекомендует задавать и те, и другие для каждого уровня тестирования и приводит типичные примеры:
| Вид критерия | Примеры |
|---|---|
| Вход: доступность ресурсов | Люди, инструменты, окружения, тестовые данные, бюджет, время |
| Вход: доступность тестовых артефактов | Базис тестирования, проверяемые требования, юзер стори, тест-кейсы |
| Вход: начальное качество объекта тестирования | Smoke-тесты пройдены |
| Выход: показатели полноты | Достигнутый уровень покрытия, число неустранённых дефектов, плотность дефектов, число непройденных тест-кейсов |
| Выход: завершённость | Запланированные тесты выполнены, статическое тестирование проведено, все найденные дефекты зарегистрированы, регрессионные тесты автоматизированы |
Критерий записывают так, чтобы его можно было проверить по данным. «Тестирования достаточно» проверить нельзя. «Все тест-кейсы с высоким приоритетом выполнены, покрытие требований релиза не ниже 95 процентов, открытых дефектов критической серьёзности нет» - можно проверить по результатам тестовых прогонов и списку дефектов.
Силлабус ISTQB отмечает также, что исчерпание времени или бюджета можно считать допустимым критерием выхода, если заинтересованные стороны рассмотрели и приняли риск выпуска без дальнейшего тестирования. В гибкой разработке критерии выхода часто выражают как Definition of Done (критерии готовности), а критерии входа для юзер стори - как Definition of Ready.
Тест-план и тестовые прогоны
Тест-план выполняется через тестовые прогоны. У плана релиза обычно несколько прогонов: по одному на окружение, на уровень тестирования, последовательные прогоны после исправлений. В системе управления тестированием план может быть сущностью, которая объединяет эти прогоны и суммирует их результаты.
Test plan "Release 2.4"
| Exit criteria: all High test cases executed, no open Critical defects
|
+-- Run "System test, Chrome" 200 test cases
+-- Run "System test, Safari" 200 test cases
+-- Run "Acceptance test" 45 test cases
+-- Run "Regression, build 2.4.1" 320 test casesВо время тестирования результаты прогонов сравнивают с планом. Отчёт о состоянии тестирования (test status report), который ISO/IEC/IEEE 29119-3 описывает в разделе 7.3, содержит состояние тестирования, отчётный период, ход работ относительно тест-плана, факторы, которые мешают продвижению, показатели, новые и изменившиеся риски и тестирование, запланированное на следующий период. Отчёт о завершении тестирования (test completion report, раздел 7.4) подводит итог выполненного тестирования, отклонений от плана, оценки по критериям завершения, остаточных рисков и извлечённых уроков.
Сам план в ходе проекта меняется. Когда меняются объём, риски или график, план пересматривают, и история изменений документа показывает, что и когда решено. Устройство прогона и его итоги описаны в статье Тестовый прогон.
Тест-план в итеративной разработке
Силлабус ISTQB описывает планирование тестирования как активность, которая есть в любой модели разработки. Различаются её масштаб и частота. В последовательных моделях тест-план обычно один документ, написанный до начала тестирования. В итеративных моделях план пересматривают в каждой итерации: план релиза задаёт общий подход, план итерации - объём тестирования на следующую итерацию.
ISO/IEC/IEEE 29119-3 прямо предназначен для всех моделей жизненного цикла разработки. В его приложениях есть примеры каждого документа для гибкого проекта и для традиционного. План в гибкой команде может быть коротким, например одна страница с объёмом, рисками, уровнями тестирования и Definition of Done.
Тест-план, тестовая стратегия и политика тестирования
Три документа часто путают, потому что они различаются уровнем, а не предметом.
| Политика тестирования | Организационные практики тестирования | Тест-план с тестовой стратегией | |
|---|---|---|---|
| Уровень | Организация | Организация | Проект, уровень или вид тестирования |
| Вопрос | Зачем организация тестирует и чего ждёт от тестирования | Как в целом проводится тестирование в организации | Что тестируется в этом проекте, как, кем и к какому сроку |
| Типичный объём | Одна-две страницы | Несколько страниц | От одной страницы до большого документа |
| Изменения | Редко | При изменении практик организации | В ходе проекта, при каждом изменении объёма или графика |
| Пример утверждения | «Для всех продуктов, которыми пользуются клиенты, тестирование независимо от разработки» | «Системное тестирование использует приоритизацию по рискам и завершается, когда выполнены все тест-кейсы высокого риска» | «Системное тестирование релиза 2.4 охватывает оформление заказа и оплату, проводится в Chrome и Safari, заканчивается 20 ноября» |
Тест-план ссылается на документы уровня организации и фиксирует отклонения от них. Если уровня организации нет, что часто бывает в небольших компаниях, тест-план сам содержит весь подход.
Термины
| Термин | Значение |
|---|---|
| Тест-план (test plan) | Подробное описание целей тестирования, которые нужно достичь, и средств и графика их достижения |
| Тестовая стратегия (test strategy) | Часть тест-плана, которая описывает подход к тестированию для определённого проекта, уровня или вида тестирования |
| Тестовый подход (test approach) | Реализация тестовой стратегии для определённого проекта |
| Политика тестирования (test policy) | Документ верхнего уровня, который описывает принципы, подход и основные цели организации в отношении тестирования |
| Организационные практики тестирования (organizational test practices) | Описание того, как проводится тестирование в организации в целом; в редакции ISO/IEC/IEEE 29119-3 2013 года называлось организационной тестовой стратегией |
| Критерии входа (entry criteria) | Предусловия для начала активности тестирования |
| Критерии выхода (exit criteria) | Условия, которые нужно выполнить, чтобы активность тестирования считалась завершённой |
| Реестр рисков (risk register) | Список продуктовых и проектных рисков с их уровнями |
| Отчёт о состоянии тестирования (test status report) | Отчёт о ходе тестирования относительно тест-плана за отчётный период |
| Definition of Done | Критерии выхода юзер стори или итерации в гибкой разработке |
Источники
- ISO/IEC/IEEE 29119-3:2021, Software testing, Part 3: Test documentation(откроется в новой вкладке) (на английском)
- ISO/IEC/IEEE 29119-3:2021, ознакомительный фрагмент стандарта с содержанием и определениями, iTeh Standards(откроется в новой вкладке) (на английском)
- IEEE 829-2008, Standard for Software and System Test Documentation(откроется в новой вкладке) (на английском)
- IEEE 829-1983, Standard for Software Test Documentation(откроется в новой вкладке) (на английском)
- ISTQB Certified Tester Foundation Level Syllabus v4.0.1, ISTQB, 2024(откроется в новой вкладке) (на английском)
- Глоссарий ISTQB(откроется в новой вкладке) (на английском)