Риски проектирования тестов для ручного и автоматизированного тестирования
Растущий интерес к автоматизации тестирования сдерживается опасениями по поводу рисков. Один из таких рисков — несоответствующий тест-дизайн, который невозможно использовать в качестве основы для разработки и выполнения автоматизированных тестовых скриптов.
С другой стороны, этот риск несоответствующего тест-дизайна является проблемой для тестирования в целом (вне рамок автоматизации тестирования). Качественный тест-дизайн может существенно упростить и ускорить процесс работы следующих специалистов:
- Тестировщика (выполнение тестов вручную)
- Инженера по автоматизации тестирования (разработка и выполнение скриптов)
- Руководителя группы тестирования (анализ результатов ручного и автоматизированного тестирования)
Тест-дизайн и требования
Вспомним основы тест-дизайна.
Тестирование всегда проводится на основе требований.
Требования должны быть:
- Полными
- Непротиворечивыми
- Однозначными
- Отслеживаемыми
- Тестируемыми
- и т. д.
Для проверки всех требований необходимо как можно раньше начать проектирование тестов.
Требования обычно претерпевают изменения в процессе выполнения проекта. Эти изменения должны быть отражены в тест-дизайне и автоматизированных тестовых скриптах.
Тестирование на основе данных основано на отделении шагов тестирования от тестовых данных, что обеспечивает:
- Увеличение объема тестовых данных (типичная активность автоматизации тестирования) без обновления тестового сценария
- Уменьшение времени выполнения тестов за счет направленного выбора данных с использованием классов эквивалентности, граничных значений, попарного тестирования и т.д.
Что такое тестовый сценарий?
Любой тестовый сценарий имеет определенный формат и контент. Типичный формат одинаков повсюду (см. Luxoft, RUP, Macroscope) и включает:
1) Номер шага
2) Действие
3) Ожидаемый результат
Дьявол кроется в деталях :(
Главный вопрос: Соответствует ли контекст формату?
Рассмотрим типичный тестовый сценарий (Рис. 1).
Рис. 1. Типичный тестовый сценарий
Глядя на этот тестовый сценарий возникают следующие вопросы:
- Что значат слова “few”, “any” и “for example”?
- Как можно проверить цену?
- Как можно проверить, что недоступность кнопки на шаге 5 - это не дефект?
- Сколько раз необходимо повторять шаги 2-7 и как найти данные для этих повторений?
Обратите внимание, что эти вопросы возникают в рамках как ручного, так и автоматизированного тестирования.
Каким мы хотим видеть обновленный тестовый сценарий?
Мы можем модифицировать структуру тестового сценария следующим образом:
- Номер шага (без изменений)
- Действие (без изменений)
- Входные данные (все, что пользователь может ввести /выбрать/нажать и т.д.)
- Ожидаемый результат (все проверки при выполнении действия)
Так мы получаем улучшенный тестовый сценарий (Рис. 2):
Рис. 2. Улучшенный тестовый сценарий
Повторы и текстовые пояснения
Некоторые из указанных выше проблем уже решены, но мы идем дальше.
Необходимо избавиться от следующего:
- Конструкций типа “Repeat steps from … to …”, которые могут вызвать недоумение при ручном тестировании и усложнить скрипт автоматизированного тестирования, а также затруднить их обновления (не забывайте об изменении требований);
- Таких слов, как “corresponding”, “any”, “appropriate” и т.д. – см. Рисунок 3.
Рис. 3. Пример использования слова “corresponding” в тестовом сценарии
Почувствуйте разницу между действиями и ожидаемыми результатами
Далее необходимо разделить смесь действий и ожидаемых результатов (Рис. 4).
Рис. 4. Смесь действий и ожидаемых результатов
Правила следующие:
- Все действия (например, шаг 12) заносятся в столбец “Действие”.
- Все ожидаемые результаты (например, шаги 13 и 14) заносятся в столбец “Ожидаемый результат”.
Это позволяет сократить число шагов тестового сценария.
“Le Mieux Est L’ennemi du Bien” или «Лучшее — враг хорошего»
Следующий шаг — избавиться от «универсальных» сценариев, в которых UI зависит от тестовых данных (Рис. 5):
Рис. 5. Зависимость UI от тестовых данных
На Рисунке 6 показан еще один пример универсальных сценариев:
Рис. 6. Еще один пример универсальных сценариев
На шаге 5 тестового сценария имеется «универсальная» команда “Execute action”, которая выполняется как “Move 1 element …” ("Переместить 1 элемент...") для набора данных GU-01 и как “Move all elements …” ("Переместить все элементы...") для набора данных GU-02.
Однако это означает смесь шагов тестового сценария и тестовых данных, что приводит к усложнению действий ручного тестирования и усложнению кода автоматизированных скриптов.
В этом случае лучше разработать несколько больше тестовых сценариев, которые будут проще для понимания, автоматизации и поддержки.
Какой тестовый сценарий рекомендуется для тестирования на основе данных?
Формат тестового сценария:
- Номер шага
- Действие
- Входные данные (все, что пользователь может ввести /выбрать/нажать и т.д.)
- Ожидаемый результат (все проверки при выполнении действия)
Содержание тестового сценария:
- Нет явно указанных циклов – вместо этого используем несколько наборов данных
- Нет общих слов – вместо этого используем явно указанные значения – данные или ссылки
Набор данных:
- Роли, ценности
- Ссылки на хранилище данных (запросы)
Подготовка данных:
- Предварительные условия (содержимое базы данных)
- Выполнение SQL-запросов
- Специальные тестовые сценарии
Как понять, что мы на правильном пути?
Критерии:
- Существует разумный баланс между сложностью шагов тестового сценария и сложностью тестовых данных
- Иногда полезно разработать два или три похожих тестовых сценария, сократив объем данных
Преимущества
- Для ручного тестирования – увеличение надежности выполнения тестов
- Для автоматизированного тестирования – улучшение понимания, эффективности и результатов автоматизированного тестирования
Глубже погрузиться в тему тест-дизайна вы можете на наших практических онлайн-курсах