1. Теория тестирования
1.11. Тест-план. Определение, структура, особенности
Хорошо написанная документация — залог эффективного тестирования. Она структурирует тестирование и привносит в него определенную логику. В некотором смысле документация объединяет членов команды вокруг поставленной цели, обеспечивая четкое понимание иерархии, задач и ожидаемых результатов.
Одна из важных частей документации — тест план. Тест план (Test Plan) - это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до
необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.
Каждая методология или процесс пытаются навязать нам свои форматы оформления планов. В качестве примера, можно ознакомиться с шаблонами тест планов от RUP (Rational Unified Process) и стандартом IEEE 829:
В данной статье рассматривается план по стандарту ИСО. В соответствии со стандартом ИСО (ISO/IEC/IEEE 29119-3) можно выделить следующие составляющие тест-плана:
- Спецификация документа
- Введение
- Контекст тестирования
- Стратегия тестирования
- Роли, действия и ответственность
- Расписание
Спецификация документа
Также дальше идет история изменений документа. Можно добавить таблицу изменений со следующими столбцами:
- дата
- версия
- описание
- автор.
С помощью этой таблицы команда сможет эффективно фиксировать и отслеживать изменения в документе и процессе, который он описывает.
- Уникальный идентификатор документа
Уникальный идентификатор может содержать название документа, дату выпуска, версию и/или состояние документа (например, рассмотренный проект, исправленный или окончательный).
- Оформляющая организация
Определяет организацию, ответственную за подготовку и выпуск документа. Сюда могут также быть включены имена авторов (автора).
- Полномочия по утверждению
- Ведущий тестировщик
- Тест менеджер (менеджер по качеству)
- Руководитель разработки
- Менеджер Проекта
Каждый из перечисленных участников проекта, перед утверждением, проведет рецензию и внесет свои комментарии и предложения, которые помогут сделать ваш тест план более полным и качественным.
- История изменений
Сюда может входить список, который содержит текущую версию документа и все предшествующие документы, уникальную идентификацию каждого документа, описание изменений документа относительно предыдущего документа в списке, причины изменений, авторство и роль лица, вносящего изменения.
К причинам изменений могут относиться замечания аудита, анализ разработчиков, изменения системы. Лицом, вносящем изменения, может быть автор документа, менеджер проекта, владелец системы.
Введение
- Область применения
Здесь мы кратко обозначаем, что собираемся делать. Это пояснительная записка для клиента. В паре предложений опишите, какие услуги предоставит команда QA и зачем.
Включите все виды тестирования, которые вы согласились осуществить, но не входите в детали. На этом этапе достаточно обозначить все в общих чертах.
- Ссылки
Сюда входят нормативные ссылки и хранилища для систем программного обеспечения и информации о тестировании. Ссылки могут быть разделены на "внутренние" ссылки организации и "внешние" ссылки, которые не относятся к организации
Ссылки на документацию
элемента тестирования
могут включать в себя ссылки на:
требования, проект, руководство пользователя, руководства по работе, инструкцию по установке.
- Глоссарий
Представляет собой словарь терминов, сокращений и аббревиатур, если таковые используются в документе.
Контекст тестирования
- Проект(ы)/подпроцесс(ы) тестирования
- Элемент(ы) тестирования
Определяет элемент(ы) тестирования для тестирования по этому плану, включая их версию/пересмотр или ссылку на эту информацию. В этом разделе возможно описание назначения элемента(ов) тестирования или приводится ссылка на эту информацию.
Элементом тестирования
может быть:
Программный блок, интерфейс между единицами, подсистема или полная система. Например, система выдачи заказов.
- Область применения тестирования
Обобщает все функции элемента(ов) тестирования, подлежащие проверке. Также идентифицирует все функции элемента(ов) тестирования, которые должны быть исключены из тестирования, и предоставляет обоснования их исключения.
Функции, подлежащие проверке, могут быть определенными атрибутами программного обеспечения,
функций, интерфейсов или бизнес-процессов.
Например:
ввод информации о доставке, выбор способа оплаты, подтверждение заказа и т. д.
- Риски
Идентифицирует риски, которые охватывают тестирование по этому плану. Риски бывают проектные и продуктовые. Для каждого риска на основе его влияния и вероятности приводится уровень воздействия. Представляет рекомендации по обработке рисков.
Пример рекомендаций по обработке рисков:
Предположим, что у нас на проекте есть всего один тестовый стенд, который периодически «падает» и стопорит все тестирование. Возможные стратегии для этого риска будут выглядеть так:
- снижение – анализируем причины падения, подключаем выделенного специалиста по инфраструктуре, работаем над ошибками сборок;
- уклонение – согласовываем настройку второго стенда;
- принятие – закладываем простой в планируемые трудозатраты;
- передача ответственности – информируем заказчика о том, что ответственность за сроки работы в этих условиях возлагается на него.
Идентифицирует связанные с тестированием риски продукта и предоставляет рекомендации по обработке каждого риска.
Связанные с тестированием
риски продукта могут включать в себя дефекты функциональных или
нефункциональных аспектов, таких как производительность. Возможные риски:
- Программное обеспечение не выполняет функции, указанные в спецификации;
- Программное обеспечение не выполняет функции, ожидаемые пользователями, клиентами и/или заинтересованными сторонами;
- Системная архитектура не поддерживает нефункциональные требования;
- Вычисления выполняются неверно в каких-то ситуациях;
- Неверная реализация в коде структуры управления циклом;
- Неадекватное время отклика высоконагруженной системы;
- Отзывы пользователей о продукте показывают, что их ожидания не оправдались.
Риски проекта
Идентифицирует связанные с тестированием риски проекта и предоставляет рекомендации по обработке каждого риска.
Связанные с тестированием
риски проекта могут включать в себя риски, связанные с графиком или ресурсами. Возможные риски:
- неверная оценка трудозатрат;
- изменение требований со стороны заказчика в ходе реализации;
- требования не определены достаточно хорошо/невыполнимы;
- тестовая среда не готова вовремя;
- увольнение/перераспределение людей;
- низкая продуктивность;
- недостаток навыков, обучения персонала;
- проблемы с поставщиками;
- несогласованность плана релиза.
Стратегия тестирования
Стратегия тестирования обычно определяет некоторые или все из следующих аспектов: используемые методики тестирования, реализуемые тестовые подпроцессы, повторное тестирование и регрессионное тестирование, которые будут
использоваться, методы проектирования тестирования, соответствующие критерии завершения тестирования, тестовые данные, тестовую среду, требования к инструментам тестирования и ожидаемые результаты тестирования.- Подходы
Здесь мы описываем уровни, виды и методы тестирования, которые будем применять. В этот раздел также включаются тест-кейсы. Благодаря этому клиент может получить полную картину действий по тестированию.
-
Практические результаты
Здесь описаны все документы, которые должны быть получены в результате выполнения тестирования, или эквивалентную документальную информацию в электронной форме.
К результатам тестирования могут относиться следующие документы:
- План тестирования;
- Отчет о готовности тестовых данных;
- Отчет о готовности тестовой среды;
- Отчеты по инцидентам;
- Отчеты о ходе тестирования;
- Отчет о завершении тестирования.
- Критерии прохождения тестов
Каждый тест-кейс будет обозначен как «Pass» (пройден), «Fail» (провален) или «Blocked» в зависимости от критериев:
- Наличие и серьезность багов.
- Уровень успешно выполненных требований.
И не забудьте определить критерии начала и окончания тестирования.
Критерии начала — то, что должно быть и что нужно сделать до начала тестирования. Например, вам могут понадобиться:
- законченная справочная документация
- программный продукт в том виде, в котором его будут получать клиенты
- специальные программные утилиты, конфигурационные файлы или данные
- требования к продукту и прочая документация и т.д.
Критерии начала тестирования служат для определения готовности или неготовности к тестированию. Будет полезно составить список того, что будет использоваться в качестве входных данных, и запросить материалы, необходимые для выполнения тестов.
Критерии окончания тестирования — это то, что вы считаете необходимым для завершения процесса тестирования. Тестировщики часто стараются сделать критерии окончания тестирования условием для поставки ПО, но это не реально. Это решение принимает собственник продукта (или другое ответственное лицо).
Пример критериев окончания тестирования:
- Требуемые метрики
Определяет метрики, значения которых должны быть собраны во время выполнения тестирования.
Список возможных метрик тестирования есть здесь.
- Требования к тестовым данным
Определяет все соответствующие требования к тестовым данным для проекта или подпроцесса тестирования.
Что можно указать в требованиях к тестовым данным:
Может быть идентифицирован источник тестовых данных и решено, где располагаются определенные тестовые данные, указано должны ли данные быть замаскированы по причинам конфиденциальности и/или перечислены ответственные за тестовые данные.
- Требования к тестовой среде
Определяет необходимые и желательные свойства тестовой среды.
В тестовую среду могут входить:
Аппаратные средства, программное обеспечение, инструменты ручного и автоматизированного тестирования,
базы данных и персонал.
В инструменты тестирования могут входить
инструменты управления тестированием, инструменты выполнения теста, инструменты
тестирования производительности, инструменты тестирования безопасности,
инструменты тестирования удобства пользования и тд.
Включает в себя информацию о выборе, оценке, приобретении и поддержке каждого инструмента. Сюда также могут входить требования к тестовой среде для подготовки к тестированию, выполнению теста (включая сбор данных) и любых действий после выполнения.
- Повторное тестирование и регрессионное тестирование
Определяет условия, при которых будут выполняться повторное тестирование и регрессионное тестирование. Сюда может быть включено предполагаемое число циклов тестирования.
- Критерии остановки и требования для возобновления тестирования
Определяет критерии, используемые для приостановки и возобновления всех или части действий тестирования Плана Тестирования. Определяет, кто ответственен за приостановку и возобновление действий тестирования. Определяет действия тестирования, которые, вероятно, придется повторить при возобновлении тестирования.
Критерии остановки/возобновления описывают ситуацию, когда тестирование невозможно продолжать из-за найденных багов. Другими словами, если дела идут так плохо, что запланированные тесты нельзя провести, тестирование нужно остановить до устранения блокирующих багов.
Роли, действия и ответственность
Обеспечивает общие сведения об основном персонале (лидерах деятельности) и вторичном персонале (не лидерах, а персонале поддержки) - лицах, исполняющих связанные с тестированием роли, с их соответствующими действиям тестирования ответственностями
и полномочиями. Кроме того, определяет ответственных за предоставление элемента(ов) тестирования.
К ответственным лицам могут быть отнесены:
Менеджер проекта, менеджеры тестирования, разработчики, аналитики и исполнители тестирования, обслуживающий персонал, представители пользователя, персонал технической поддержки, администраторы данных и персонал поддержки качества.
Расписание
Тест план должен также включать дедлайны. Команде нужно как-то оценивать скорость работы. Для этого им нужно знать, сколько времени отводится на тестирование. Если есть несколько этапов тестирования, нужно расписать их порядок и сроки.