Тест-дизайн: от требований к тестам

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

Для этого и нужен тест-дизайн — процесс определения тестовых условий, данных и сценариев на основе требований, логики работы системы и возможных рисков.
Проще говоря, тест-дизайн отвечает на вопрос: «Что именно проверить, чтобы получить максимум информации о качестве продукта за разумное количество тестов?»

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

Например, поле «Количество товаров» принимает значения от 1 до 10. Получаем три класса: значения меньше 1, значения от 1 до 10 и значения больше 10.
Вместо проверки каждого числа можно взять 0, 5 и 11. Так мы проверим каждое принципиально отличающееся поведение системы, не перебирая все варианты.

Эта техника особенно полезна для полей с ограничениями: возраст, сумма платежа, количество символов, размер файла, количество товаров и другие диапазоны.

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

Если пароль должен содержать от 8 до 20 символов, имеет смысл проверить не только значение внутри диапазона, но и значения непосредственно около границ: 7, 8, 9, 19, 20 и 21 символ.
Так можно обнаружить ошибки вроде неправильного сравнения < вместо <= или некорректной обработки минимального и максимального значения.

Классы эквивалентности и граничные значения хорошо работают вместе: первая техника сокращает количество проверок, вторая помогает не пропустить ошибки на границах.

Если поведение системы зависит сразу от нескольких условий, удобно использовать таблицы решений.

Например, интернет-магазин дает бесплатную доставку, если сумма заказа больше 5000 рублей или у пользователя есть специальный статус.

Здесь нужно проверить комбинации условий:

Таблицы решений особенно полезны для скидок, бонусов, прав доступа, тарифов, способов оплаты и других бизнес-правил.
Кроме тестирования, они помогают обнаружить проблемы непосредственно в требованиях. Если для какой-то комбинации непонятно, какой должен быть результат, значит, требование требует уточнения.

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

Например, заказ может находиться в состояниях «создан», «оплачен», «отправлен», «доставлен» или «отменен». Нужно проверить, что допустимые переходы работают:

Создан → Оплачен → Отправлен → Доставлен

и что недопустимые переходы запрещены, например:

Доставлен → Оплачен

Такая техника особенно актуальна для заказов, платежей, подписок, заявок и аккаунтов.

Когда параметров много, количество комбинаций может стать огромным. Например, приложение нужно проверить на разных операционных системах, браузерах, устройствах, языках и способах оплаты.

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

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

Error guessing — техника, основанная на опыте тестировщика и знании типичных ошибок.
Например, для формы загрузки файла можно дополнительно проверить:

• Файл нулевого размера;
• Слишком большой файл;
• Неподдерживаемый формат;
• Поврежденный файл;
• Очень длинное имя файла.

Для кнопки оплаты — двойное нажатие, обновление страницы во время оплаты, потерю соединения и повторную отправку запроса.
У этой техники нет фиксированного алгоритма. Тестировщик предполагает, где система может повести себя неправильно, и добавляет соответствующие проверки.

Тест-дизайн должен учитывать не только правильное использование системы.

• Позитивные тесты проверяют ожидаемый сценарий: пользователь вводит корректные данные и получает корректный результат.
• Негативные тесты проверяют обработку некорректных данных и действий: пустые поля, неверный формат, недопустимые значения, отсутствие прав, повторную отправку запроса и другие ошибочные ситуации.

Например, если форма принимает email, недостаточно проверить user@example.com. Нужно проверить пустое значение, отсутствие @, некорректный домен и другие предусмотренные требованиями варианты.
При этом негативный сценарий не обязательно должен приводить к ошибке приложения. Наоборот, хорошая система должна корректно обработать некорректный ввод и сообщить пользователю, что именно нужно исправить.

Техники тест-дизайна не нужно применять механически. Выбор зависит от того, что именно мы тестируем.

• Если есть диапазоны — используем классы эквивалентности и граничные значения.
• Если результат зависит от нескольких условий — таблицу решений.
• Если объект имеет жизненный цикл — переходы состояний.
• Если комбинаций параметров слишком много — попарное тестирование.
• Если нужно проверить типичные слабые места — предугадывание ошибок.

На практике техники часто комбинируются. Например, для поля с ограничением по длине можно одновременно применить классы эквивалентности, граничные значения и error guessing.

Важно не путать тест-дизайн с написанием тест-кейсов.

• Тест-кейс описывает конкретную проверку: предусловия, шаги, данные и ожидаемый результат.
• Тест-дизайн определяет, какие именно проверки нужно создать и почему.

Например, для поля «Возраст от 18 до 60 лет» тест-дизайн может определить классы эквивалентности и границы: 17, 18, 19, 59, 60, 61. Уже после этого из выбранных проверок создаются конкретные тест-кейсы.
Поэтому тест-дизайн начинается с анализа требований, а не с открытия шаблона тест-кейса.

Тест-дизайн нужен не для того, чтобы написать как можно больше тестов. Его цель — получить хорошее покрытие при разумном количестве проверок.

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

Именно поэтому знание техник тест-дизайна помогает перейти от «проверить всё» к более профессиональному подходу: понять систему, определить риски и выбрать проверки, которые действительно имеют смысл.


Хотите узнать больше? Изучите другие статьи из раздела:

• Основы и старт в IT