Процесс тестирования. Часть 2: Анализ тестирования и тест дизайн
Благодаря плану и стратегии тестирования, мы можем легко понять, какие компоненты нам надо тестировать и какие виды\методы\техники нам нужно применить. Но при этом, часто тестировщик сталкивается с проблемами непонимания того, насколько глубоко нужно тестировать конкретное требование. Помимо этого, не очень понятно как эффективнее всего будет проверить то или иное условие. При хорошем процессе тестирования, на все эти вопросы отвечают процессы анализа тестирования и тест дизайна.
Если вы не знакомы с фундаментальным процессом тестирования, то рекомендуем начать с первой части:
Фундаментальный процесс тестирования. Часть 1: Планирование и контроль тестирования
Анализ тестирования и тест дизайн
Анализ тестирования (Test analysis) — это активность, которая определяет, что должно быть протестировано.
Проектирование тестов (тест дизайн, Test design) — это активность, которая определяет, как должно быть протестировано то, что было определено в рамках анализа тестирования.
Вроде всё просто 🙂
Очень часто эти 2 процесса выполняются одновременно. Но сегодня мы разберём детально, что именно должно происходить на каждом из этапов.
Для этих двух активностей необходим анализ базиса тестирования.
Базис тестирования (Test basis) — документ, на основании которого определяются требования к
компоненту или системе. То есть документация, на которой базируются тестовые сценарии.
Базис тестирования может быть представлен в следующем виде: Спецификаций (Specifications), Концепции (Vision), Варианта использования (Use-case), Истории использования (User story), Макет (Mockup), Прототип (Prototype) и тд.
Разберём немного подробнее этап анализа тестирования
Анализ тестирования
Представим, что мы тестируем интернет-магазин. Исходя из требований (базиса тестирования) мы понимаем, что именно нам нужно протестировать. Например, нам надо проверить, что пользователь может зарегистрироваться, войти в приложение, найти там товар, добавить его в корзину, после чего оплатить и получить.
Дальше, в рамках анализа тестирования, нам нужно определить следующие вещи:
- Уровни тестирования — на сколько глубоко нам нужно протестировать каждое требование (Компонентное, интеграционное и системное тестирование);
- Уровень детализации и качества наших требований;
- Связи между требованиями;
- Сложность нашего приложения;
- Продуктовые и проектные риски;
- Жизненный цикл разработки ПО и его длительность;
- Инструменты по управлению тестированием (Test management system);
- Опыт и постоянность команды;
- Доступность для консультации других участников проекта.
Исходя из вышеописанных моментов, мы можем принять решение о том, на сколько глубоко нам надо тестировать конкретное требование и какой вид документации лучше всего применить.
Например, если проект представляет собой сложную систему, с высокими рисками и нестабильной командой — то необходимо будет выбрать наиболее подробный вид документации, скажем тест-кейс. Из-за высоких рисков и сложности тесты необходимо будет проектировать на всех уровнях и максимально детально. Благодаря максимально проработанным тестам новым членам команды будет намного проще войти в проект нежели при использовании менее детальной документации.
Главный принцип для выбора документации — это окупаемость этой самой документации.
Я думаю логика понята. Чем сложнее, рискованней, дольше и стабильней наш проект, тем глубже и детальнее нужно прорабатывать тесты.
Для простого проекта, с невысокими рисками и продолжительность, с не совсем стабильными требованиями и стабильной командой можно использовать высокоуровневую тестовую документацию, например чек-листы (Checklists). В противном случае мы рискуем потратить большую часть времени на тест дизайн и поддержку документации, а не на выполнение тестов.
Иногда для проверки разных требований может применяться тестовая документация разных уровней.
Например, для сложного и рискового функционала — детальные тест кейсы, а для простого и нерискового — либо чек-лист, либо очень высокоуровневые тест-кейсы.
Зачем делать анализ тестирования?
Можно выделить 2 больших достоинства анализа тестирования:
- Создание ясности и гибкости в других активностях тестирования благодаря определению точных целей тестов. Мы знаем что именно и на сколько глубоко нужно тестировать.
- Предотвращение дефектов: именно на этапе анализа тестирования проводится верификация и статическое тестирование.
После определения того, что мы будем делать, можно приступить к этапу создания тестов.
Проектирование тестов (тест дизайн, Test design)
Как было написано выше:
Проектирование тестов (тест дизайн, Test design) — это активность, которая определяет, как именно должно быть протестировано то, что было определено в рамках анализа тестирования.
То есть, это процесс перевода анализа тестирования в конкретные тесты (тест-кейсы, чек-листы, сценарии и тд)
Процесс тест дизайна включает в себя следующие активности:
- Определить техники тест дизайна
- Создать и приоритизировать тесты, которые покроют все необходимые условия определённые в анализе тестирования
- Начать готовить тестовое окружение для выполнения тестов
Как правило, разработка тестов начинается с наиболее высокого уровня документации, постепенно снижаясь в уровне детализации тестов.
Из анализа тестирования у нас должно быть известно, что нам надо проверить, на каком уровне тестирования и какую документацию мы будем использовать.
Типовой пример с тест-кейсами:
- Разбить приложение на модули и подмодули (если это не было сделано на этапе анализа тестирования)
- На каждый модуль\подмодуль написать чек-лист в порядке важности
- Начать детально прорабатывать условия выполнения (шаги), входные данные, ожидаемые результаты и все остальные атрибуты тест-кейса, попутно задавая вопросы и проясняя непонятные моменты
- Получить ревью от коллег тестировщиков\разработчиков\заказчиков, чтобы убедиться в том, что мы ничего не забыли.
В случае использования менее детализированной документации, можно пропустить шаг 3.
О чем ещё стоит подумать при проектировании тестов?
Для того чтобы эффективнее всего подобрать условия выполнения и входные данные для тестов нам помогут техники тестирования.
Техники тестирования (Test techniques, Test design techniques) — методы, используемые для создания и/или выбора входных данных и условий выполнения тестов.
По всем техникам тестирования мы пройдёмся как-нибудь в следующий раз. В рамках этой темы хотелось бы сказать, что для создания тест-кейсов подходят техники тестирования чёрного ящика (Black-box test techniques).
Так же, как и при анализе тестирования, проектирование тестов может привести к выявлению
аналогичных типов дефектов в требованиях (базисе тестирования). А выявление дефектов на ранних этапах проекта является важным потенциальным преимуществом для нашего продукта.
На сегодня у нас всё, в следующий раз разберём стадии реализации и выполнения тестов.
Stay tuned 🙂
