;
Александр Александров

Окей, гуру! Проектирование тестов: удобство чтения в сравнении с удобством написания

20.02.2021 283

Риски проектирования тестов для ручного и автоматизированного тестирования

Растущий интерес к автоматизации тестирования сдерживается опасениями по поводу рисков. Один из таких рисков — несоответствующий тест-дизайн, который невозможно использовать в качестве основы для разработки и выполнения автоматизированных тестовых скриптов.

С другой стороны, этот риск несоответствующего тест-дизайна является проблемой для тестирования в целом (вне рамок автоматизации тестирования). Качественный тест-дизайн может существенно упростить и ускорить процесс работы следующих специалистов:

  • Тестировщика (выполнение тестов вручную)
  • Инженера по автоматизации тестирования (разработка и выполнение скриптов)
  • Руководителя группы тестирования (анализ результатов ручного и автоматизированного тестирования)

Тест-дизайн и требования

Вспомним основы тест-дизайна.

Тестирование всегда проводится на основе требований.

Требования должны быть:

  • Полными
  • Непротиворечивыми
  • Однозначными
  • Отслеживаемыми
  • Тестируемыми
  • и т. д.

Для проверки всех требований необходимо как можно раньше начать проектирование тестов.

Требования обычно претерпевают изменения в процессе выполнения проекта. Эти изменения должны быть отражены в тест-дизайне и автоматизированных тестовых скриптах.

Тестирование на основе данных основано на отделении шагов тестирования от тестовых данных, что обеспечивает:

  • Увеличение объема тестовых данных (типичная активность автоматизации тестирования) без обновления тестового сценария
  • Уменьшение времени выполнения тестов за счет направленного выбора данных с использованием классов эквивалентности, граничных значений, попарного тестирования и т.д.

Что такое тестовый сценарий?

Любой тестовый сценарий имеет определенный формат и контент. Типичный  формат одинаков повсюду (см. Luxoft, RUP, Macroscope) и включает:

1)      Номер шага

2)      Действие

3)      Ожидаемый результат


Дьявол кроется в деталях :(

Главный вопрос: Соответствует ли контекст формату?

Рассмотрим типичный тестовый сценарий (Рис. 1).

Рис. 1. Типичный тестовый сценарий

Рис. 1. Типичный тестовый сценарий

Глядя на этот тестовый сценарий возникают следующие вопросы:

  • Что значат слова “few”, “any” и “for example”?
  • Как можно проверить цену?
  • Как можно проверить, что недоступность кнопки на шаге 5 - это не дефект?
  • Сколько раз необходимо повторять шаги 2-7 и как найти данные для этих повторений?

Обратите внимание, что эти вопросы возникают в рамках как ручного, так и автоматизированного тестирования.


Каким мы хотим видеть обновленный тестовый сценарий?

Мы можем модифицировать структуру тестового сценария следующим образом:

  • Номер шага (без изменений)
  • Действие (без изменений)
  • Входные данные (все, что пользователь может ввести /выбрать/нажать и т.д.)
  • Ожидаемый результат (все проверки при выполнении действия)

Так мы получаем улучшенный тестовый сценарий (Рис. 2):

Рис. 2. Улучшенный тестовый сценарий

Рис. 2. Улучшенный тестовый сценарий


Повторы и текстовые пояснения

Некоторые из указанных выше проблем уже решены, но мы идем дальше.

Необходимо избавиться от следующего:

  • Конструкций типа “Repeat steps from … to …”, которые могут вызвать недоумение при ручном тестировании и усложнить скрипт автоматизированного тестирования, а также затруднить их обновления (не забывайте об изменении требований);
  • Таких слов, как “corresponding”, “any”, “appropriate” и т.д. – см. Рисунок 3.
Рис. 3. Пример использования слова “corresponding” в тестовом сценарии

Рис. 3. Пример использования слова “corresponding” в тестовом сценарии


Почувствуйте разницу между действиями и ожидаемыми результатами

Далее необходимо разделить смесь действий и ожидаемых результатов (Рис. 4).

Рис. 4. Смесь действий и ожидаемых результатов

Рис. 4. Смесь действий и ожидаемых результатов

Правила следующие:

  • Все действия (например, шаг 12) заносятся в столбец “Действие”.
  • Все ожидаемые результаты (например, шаги 13 и 14) заносятся в столбец “Ожидаемый результат”.

Это позволяет сократить число шагов тестового сценария.


“Le Mieux Est L’ennemi du Bien” или «Лучшее — враг хорошего»

Следующий шаг — избавиться от «универсальных» сценариев, в которых UI зависит от тестовых данных (Рис. 5):

Рис. 5. Зависимость UI от тестовых данных

Рис. 5. Зависимость UI от тестовых данных

На Рисунке 6 показан еще один пример универсальных сценариев: 

Рис. 6. Еще один пример универсальных сценариев

Рис. 6. Еще один пример универсальных сценариев

На шаге 5 тестового сценария имеется «универсальная» команда “Execute action”, которая выполняется как “Move 1 element …” ("Переместить 1 элемент...") для набора данных GU-01 и как “Move all elements …” ("Переместить все элементы...") для набора данных GU-02.

Однако это означает смесь шагов тестового сценария и тестовых данных, что приводит к усложнению действий ручного тестирования и усложнению кода автоматизированных скриптов.

В этом случае лучше разработать несколько больше тестовых сценариев, которые будут проще для понимания, автоматизации и поддержки.


Какой тестовый сценарий рекомендуется для тестирования на основе данных?

Формат тестового сценария:

  • Номер шага
  • Действие
  • Входные данные (все, что пользователь может ввести /выбрать/нажать и т.д.)
  • Ожидаемый результат (все проверки при выполнении действия)

Содержание тестового сценария:

  • Нет явно указанных циклов – вместо этого используем несколько наборов данных
  • Нет общих слов – вместо этого используем явно указанные значения – данные или ссылки

Набор данных:

  • Роли, ценности
  • Ссылки на хранилище данных (запросы)

Подготовка данных:

  • Предварительные условия (содержимое базы данных)
  • Выполнение SQL-запросов
  • Специальные тестовые сценарии

Как понять, что мы на правильном пути?

Критерии:

  • Существует разумный баланс между сложностью шагов тестового сценария и сложностью тестовых данных
  • Иногда полезно разработать два или три похожих тестовых сценария, сократив объем данных


Преимущества

  • Для ручного тестирования – увеличение надежности выполнения тестов
  • Для автоматизированного тестирования – улучшение понимания, эффективности и результатов автоматизированного тестирования


Глубже погрузиться в тему тест-дизайна вы можете на наших практических онлайн-курсах


Расскажи друзьям:

 
Оценка и обучение ИТ-специалистов по ключевым направлениям разработки программного обеспечения. Курсы от экспертов-практиков по языкам программирования, системному и бизнес-анализу, архитектуре ПО, ручному и автоматизированному тестированию ПО, Big Data и машинному обучению, управлению проектами и Agile. Luxoft Training – первый учебный центр в России, авторизованный IIBA. Действует скидка 10% на обучение физических лиц.
Остались вопросы?
Связаться с нами
Пользователь только что записался на курс ""
Спасибо!
Форма отправлена успешно.