- Что это
- Артефакты vs деливераблы vs документация
- Зачем нужны
- Типы артефактов
- Стратегия тестирования
- Тест-план
- Тестовый сценарий
- Тест-кейс
- Матрица трассировки требований
- Отчет о тестировании
- Прочие типы
Быстрое определение
Тестовые артефакты, или артефакты тестирования — набор документов и дополнительных материалов, задействованных в жизненном цикле тестирования. Тестовые артефакты предоставляются заказчикам/клиентам, всей QA-команде, ее лидам, стейкхолдерам, и участникам других команд в компании.
Нюансы терминологии
Почему «артефакты»?
Потому что эти материалы являются как бы «побочными продуктами», создаваемыми при тестировании.
В чем отличие понятий «тестовые артефакты» и «тестовая документация»?
Обычно под этим подразумевают одно и то же, и в 90% случаев так и есть; но на самом деле понятие «тестовых артефактов» шире чем «документация», поскольку включает не только, собственно, тестовые документы, но и:
- Модели
- Дизайны
- Макеты
- Рисунки
- Графики
- Логи
- Метрики
- Репорты
- Схемы действий пользователей (user journeys)
- Какие-то дополнительные файлы
- Базы данных, и т.п.
И даже код автотестов может считаться тестовым артефактом (по книге «The Practical Testing Book»).
Отдельно о тестовой документации — здесь.
Что такое test deliverables?
ISTQB определяет test deliverables как «любые продукты тестирования, предоставляемые членам команды и другим заинтересованным сторонам».
Проще говоря, Test Deliverables — это текущие результаты, документы, и сопутствующие материалы тестирования в наглядной форме. Иногда еще называются «тестовой поставкой». В 90% случаев под «test deliverables» понимают то же, что «артефакты».
Зачем нужны
Итак, тестовые артефакты — это документация и дополнительные материалы, которые «облегчают взаимопонимание в команде, убирают пробелы в коммуникации, повышают прозрачность» в команде. Они создаются и обслуживаются по тем же принципам, что все артефакты программирования, поскольку имеют «программируемый и воспроизводимый» формат. Создатели этих документов, опытные тестировщики, применяют сложные инструментальные средства и продуманные техники, и проходят тренинги повышения квалификации — как делают и и разработчики, чтобы создавать хорошие приложения.
Артефакты должны быть в правильной форме, содержать проверенные, точные, детализированные данные — и тогда будет легко отследить в них изменения, и точки «когда что-то пошло не так», или быстро ввести в курс дела новых людей в QA-команде.
Типы артефактов
Наиболее распространенные тестовые артефакты:
Стратегия тестирования
Документ, который создается на уровне менеджмента; обычно его готовит проджект-менеджер или тест-менеджер (координатор проекта). В стратегии описываются общие методы и подходы на протяжении STLC-цикла, будущие результаты, и задействованные ресурсы.
Указываются цели, средства, применяемые техники, детали по инфраструктуре, и тайминг этапов тестирования (активностей). Могут также указываться риски и негативные факторы, возникающие в процессе, и решения по их устранению; уточняются челленджи и подходы для успешного завершения цикла.
Стратегия строится на основе и с учетом бизнес-требований, поэтому имеет специфический формат Business Requirement Specification Format. Стратегия тестирования — это ответы на вопросы:
- Какова главная цель тестирования?
- Какие общие указания нужны для его успешного завершения?
- Какие требования предусмотрены, в частности, функциональные требования;
- Общее описание тестовых сценариев, ресурсов, и т.п.
- Зоны ответственности участников QA-команды и проджект-менеджера
- Какие уровни тестирования предусмотрены?
- Какие артефакты (документы, deliverables) будут созданы в процессе?
- Какие риски могут возникнуть в проекте
- И какие предусмотрены способы их устранить
Тест-план
Детализированный документ, описывающий цели, область тестирования (Testing Scope), результаты и документы, риски, и тестовые этапы (активности). Создание тест-плана служит залогом системности подходов. Это необходимый перечень задач и «майлстоунов», по которому будут оценивать продвижение проекта.
Тест-план касается задач, выполняемых только QA-командой. Вопросы, на которые нужно ответить в тест-плане:
- Какова основная цель тестовых активностей (этапов)?
- Какая предусмотрена область тестирования (Scope)?
- Какие подходы и методы будут применяться?
- Какие ресурсы будут привлечены?
- Какие критерии завершения этапов тестирования («критерии выхода»)?
- Как команда будет решать челленджи и управлять рисками?
Подробно о тест-планах и как их делать
Тестовый сценарий
Документ, описывающий функциональность приложения. Чаще всего бывает связан с юз-кейсом, его задача — проверить, что Е2Е-тестирование функции прошло успешно.
В общем случае, тестовый сценарий — это ситуация, возникающая в приложении: или например одно из условий в форме; поэтому может еще называться тестовым условием или «тестовой возможностью». В одном сценарии может быть один или много тест-кейсов. Тестовый сценарий — это о требованиях детально.
Тест-кейс
Подробный документ, описывающий кейсы («случаи/сюжеты/ситуации»). В тест-кейсе содержатся: название кейса; условие при котором он возникает (condition); шаги (этапы); и ожидаемые результаты.
Тест-кейсы позволяют идентифицировать и отслеживать проблемы с требованиями, или проблемы в дизайне/архитектуре приложения.
Проще говоря, тест-кейс — это набор условий или переменных, при которых тестировщик видит, что система удовлетворяет (или нет) требованиям, то есть будет работать правильно.
Правильный тест-кейс должен иметь:
- ID, идентификатор, то есть свой уникальный номер
- Название, позволяющее легко его найти/вспомнить
- По возможности полное описание ситуации
- Четкие понятные этапы действий
- Ожидаемые результаты
Руководство по написанию тест-кейса
Матрица отслеживания требований
Или матрица трассировки. Таблица связей между требованиями и тест-кейсами. Документ, связывающий другие важные тестовые артефакты, что позволяет в любое время проверить их, отследить изменения и уточнить. Улучшает видимость процессов тестирования.
Итак, это таблицы отслеживания связей клиентских требований с тест-кейсами, и идентификации дефектов. Могут быть двух типов — прямая и обратная. Компоненты матрицы:
- ID, идентификатор-номер требования
- Тип требования
- Описание требования
- Статус тест-дизайна (выполнен ли)
Чаще всего в матрицу включаются системные и модульные тест-кейсы.
Отчет о тестировании
Описание тестовых активностей (действий). Детальная информация о статусе тест-кейсов, тест-сьютов, и тестовых сценариев. Нужен чтобы формально представить результаты тестирования, и быстро их оценить. Могут быть как индивидуальными, так и от всей QA-команды. Стандартно генерируются каждый день, и после завершения какого-то этапа/цикла тестирования.
Прочие типы артефактов
Также к тестовым артефактам относятся:
- Требования
- Чеклисты
- Юзер-сторис (пользовательские истории)
- Метрики тестирования
- А также такие вещи как тестовый оракул (Test oracle) и базис тестирования (Test basis).
