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

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

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

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

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

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

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

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

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

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

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

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

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

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

Любой тестовый сценарий имеет определенный формат и контент. Типичный  формат одинаков повсюду (см. 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.