- Суть
- О правильном названии
- Быстрый пример
- Характеристики
- Типы тест-свитов
- Когда их создают
- Шаблон тестового набора
- Чем отличаются тест-план, тестовый сценарий, тест-кейс и тестовый набор
- Как объединять тест-кейсы в тестовый набор
- Важность в энтерпрайзе
- Лучшие практики
- Что такое тест-сет
Суть
Тестовый набор — контейнер для выполнения тест-кейсов, сгруппированных по функциональности.
В тест-план может входить много тестовых наборов (свитов), которые в свою очередь состоят из тест-кейсов.
Тест-кейсы выполняются вместе (последовательно); они группируются в наборы по функциональности (предназначению), в порядке, изложенном в тест-плане.
Тестовый набор (далее также «тест-свит») может иметь статусы Активный, В процессе, и Завершен.
Итак, тестовый набор (свит) это коллекция тест-кейсов, направленных на проверку функциональности приложения, или какой-то ее части. В наборе также содержится информация о цели каждого тест-кейса, и конфигурация выполнения.
О правильном названии
Примечание: в русскоязычном QA-сообществе сложилась практика написания и произношения «тест-сьют», и это, в общем, некорректное название. Однако: чтобы наши материалы могли увидеть и прочитать больше людей, стремящихся в QA, мы должны ориентироваться на поисковые запросы; и дело в том, что «тест-сьют» в Рунете ищут гораздо чаще, чем «тест-свит». Но, реагируя на замечания наших веселых читателей в обсуждении в Телеграм-канале, решили исправить определение. Пусть будет «тест-свит», если угодно («свит как сладкий», а не «сьют как костюм», да).
Еще о правильном названии test suite на русском, например, здесь (спойлер: все не так уж однозначно).
Быстрый пример
Например, тестирование функции покупки в онлайн-магазине будет состоять примерно из таких тест-кейсов:
- Логин
- Выбор товара и добавление в корзину
- Проверка правильности данных
- Покупка
- Выход из системы
Большие подробные тест-свиты формируют при дымовом и системном тестировании.
Характеристики тестового набора
- Создается на основе тест-плана
- Также набор описывает цели тест-кейсов
- В тестовый набор входят параметры тестируемого приложения, настройки окружения, и подобные вспомогательные файлы и настройки
- Тестовые наборы могут быть как функциональной, так и нефункциональной направленности
- Тестовые наборы ускоряют и облегчают процесс тестирования
- Тест-кейсы в свите выполняются последовательно, и выполнение следующего зависит от предыдущего
- Могут автоматизироваться, например в Selenium
Типы
По предназначению можно выделить:
- Абстрактный тест-свит, создаваемый при так называемом тестировании на основе моделей. Состоит из группы абстрактных тест-кейсов, созданных на основе высокоуровневой модели приложения. QA-команда не может применять такие тест-свиты непосредственно (как обычные), поскольку они недостаточно подробно описывают приложение и тестовое окружение, и не могут запускаться/выполняться автоматизированно.
- Выполняемый тест-свит, то есть обычный. Разрабатывается на основе абстрактного и может выполняться (и соответственно автоматизироваться). Работает на «низком уровне», то есть на привычном для junior-тестировщика уровне, и активно взаимодействует с приложением.
Часто применяемые тестовые наборы
Тестирование верификации билда. Тестовый набор базовой проверки основной функциональности. Когда есть готовый билд.
Регрессионные тесты. Набор регрессионного тестирования функциональности.
Дымовые тесты. Набор тест-кейсов базовой проверки функциональности в экспресс-режиме, обычно после модификации кода.
Функциональные. Набор, верифицирующий обычно часть функциональности, ее отдельные аспекты.
Сквозные интеграционные, набор сквозной проверки интеграции подсистем в приложении.
Шаблон тестового набора
Шаблон стандартного тест-набора.
Саммари. Чаще довольно детализированное описание «о чем этот набор».
Дизайн. Описание дизайна.
Результаты формального ревью. Следующая секция посвящена формальному ревью, результатам обсуждения QA-командой, (что поможет привести свои будущие QA-активности в соответствие с общепринятыми правилами).
Пред- и пост-условия. Условия «входа и выхода» данного набора, то есть что должно быть сделано перед его выполнением, и после.
Ожидаемые результаты. Критерии успешности набора. После его выполнения полученные результаты сравниваются с ожидаемыми.
Анализ рисков. Идентификация всех возможных рисков, влияющих на результаты, и как их будут избегать/обходить.
Тест-кейсы. Секция непосредственно тест-кейсов, и их тестовых окружений.
Документы и репорты, а также скриншоты, записи выполнения и другие релевантные данные.
Чем отличаются тест-план, тестовый сценарий, тест-кейс, и тестовый набор
| Тест-план | Тестовый сценарий | Тест-кейс | Тестовый набор |
|---|---|---|---|
| Описание масштаба, цели, и подхода к тестированию в тестовых наборах | Описание проверки функциональности | Важный (опорный) документ, составляющая часть тестового набора | Набор тест-кейсов, объединенных по функциональности |
| Три типа: главный (мастер-план), план по типу тестов, и план по уровню тестов | Все описывается с точки зрения пользователя, может быть разным | Двух типов: формальный тест-кейс и неформальный | Два типа: абстрактный и выполняемый |
| Создается из use-кейсов, описания продукта, и требований к продукту (SRS) | Создается на основе use-кейсов, для повышения тестового покрытия и проверки пользовательских путей | Создается на основе требований и сценария тестирования | Создается по группам функциональности из нескольких тест-кейсов |
| По стандартному шаблону, описывающему процессы | Описывает операции QA-команды | Описывает проверку набора требований по проверке функциональности | Описывает цели тест-кейсов |
Как объединять тест-кейсы в тестовый набор
Как уже говорилось выше, удобнее всего объединять на основе функциональности. Можно также создавать под-наборы в рамках болшого набора.
Более гибкий подход: древовидная структура тест-свита, без ограничений на количество кейсов-«ветвей».
Чтобы структурировать тест-кейсы как логические компоненты в тест-свите, удобнее рассматривать их с точки зрения программирования, как модули, компоненты или наборы функций.
Чаще всего формируют стандартные «дымовые» и регрессионные тестовые наборы. При необходимости добавляя/удаляя оттуда тест-кейсы.
Важность в энтерпрайзе
Важно соблюдать баланс между скоростью и качеством. Этот баланс зависит от типа приложения, заказчика, и сроков. Наиболее распространенные приложения, использующие тестовые наборы, это корпоративные, и веб-приложения.
Тестирование веб- и enterprise. Веб-сервисы очень динамичные, в них часто меняются масштаб и требования. В зависимости от метрик и пользовательского фидбэка добавляются и удаляются функции. Веб-архитектура поэтому должна быть гибкой, должно регулярно проводиться сквозное тестирование, чтобы обеспечить максимальную гибкость продукта. Сквозное тестирование веб-приложения тестовым набором будет надежнее, если направлено на неизменные элементы модулей, а не на DOM-элементы.
В целом в enterprise (и десктопе) — водопадные модели, большие объемы разработки, крупные изменения бывают редко но регулярно, стабильная и надежная архитектура, соответственно тестовые наборы ориентированы на 100%-ное соблюдение требований.
Быстрые тесты. Быстрое продвижение с тестированием имеет большое влияние на продуктивность разработчиков, поэтому быстрота выполнения и легкость разбора тестов важна в веб- и энтерпрайзе. Важно поддерживать «короткую петлю фидбэка» от тестирования, это упрощает жизнь, позволяет быстро продвигаться с разработкой и экономить компании время.
Сквозные тесты. «Всеобъемлющие» e2e-наборы дают уверенность в коде в целом; результаты будут близки к реальным пользовательским сценариям сразу же как появится билд.
Лучшие практики создания тестовых наборов
Хороший тестовый набор не требует много времени на выполнение. Он сразу показывает, что приложение работает как надо, то есть требования соблюдены. Найден баг, отправлен фидбэк, разработчики находят в чем дело и фиксят. Общие признаки хорошего тестового набора:
Быстрый. Если в наборе много интеграционных тестов и мало модульных, он, очевидно, будет долго выполняться. Быстрый тест-свит даст быстрый фидбэк, разработка пойдет эффективнее.
Полный. Если свит покрывает 100% кодовой базы или чуть меньше, он найдет все дефекты, созданные после изменения функции; полнота дает уверенность.
Надежность. Надежный тест-свит это надежный стабильный фидбэк независимо от изменений вне области тестирования; ненадежный, с моргающими тестами = нет фидбэка по недавним изменениям кода.
Изолированность. В идеальном изолированном наборе тесты выполняются без зависимости от других тестов и не влияя на другие тесты; разумеется, большинство наборов такими быть не могут; несколько улучшить ситуацию помогает очистка тестовых данных после выполнения теста и перед запуском следующего.
Легкость в обслуживании. Хороший тест-свит организован удобно, в него легко удалять и добавлять тест-кейсы и модифицировать их. Чтобы свиты были легки в обслуживании, нужно придерживаться лучших практик и методологий программирования.
Удобочитаемый. Набор легко читать, он подходит для создания документации. Описания должны четко объяснять — что тестируется, и должны быть ориентированы на разработчиков в том числе.
Выбрать ЯП и фреймворки. Современное сложное приложение чаще пишется на нескольких ЯПах, каждый из которых имеет свои плюсы и минусы. Нужно учитывать уровень опыта команд и скиллы разработчиков. Если например разработчики посоветовались и решили, что Python будет основным языком проекта, то у QA-автоматизаторов нет выбора. Язык тестового фреймворка чаще всего совпадает с языком разработки. Позитив от одного ЯП для всех команд в том, что разработчики могут выступать бесплатными менторами для QA, когда у тех возникнут проблемы.
***
Что такое тест-сет?
В некоторых QA-инструментах так принято называть небольшой набор (скорее группу) тестов, выделенных для какой-то более-менее узкой задачи, или проверки функции, или регрессы. Например:
- Часть системных функций (чаще всего касающихся критически важных частей GUI), или скажем запросов в БД
- Те же регрессионные тесты
- Санити-тесты
- Группа тестов, которая должна выполняться определенным тестировщиком в день или в неделю (нормативные)
***
