Что такое тест-дизайн?
Тест-дизайн — это часть процесса тестирования программного обеспечения, на которой разрабатываются и создаются тестовые сценарии (тест-кейсы) в соответствии с заранее установленными критериями качества и целями тестирования. Грамотный тест-дизайн помогает находить ошибки до того, как продукт попадёт к пользователю.
Откуда пошёл тест-дизайн?
Идеи тест-дизайна появились вместе с развитием программирования и тестирования ПО в 1960–1970-х годах. Тогда стало понятно, что простого «потыкать» программу недостаточно — нужны системные подходы, чтобы не пропускать ошибки. Многие техники тест-дизайна были описаны в классических книгах, например, в работах Глена Майерса и Бориса Бейзера.
Подписывайтесь на мой канал в Телеграмм, чтобы ничего не пропустить.
Ну или на канал в VK, если хотите видеть новые статьи у себя в ленте.
Кто отвечает за тест-дизайн?
- Тест-аналитик — решает, «ЧТО тестировать?» (какие требования, функции, сценарии).
- Тест-дизайнер — решает, «КАК тестировать?» (какие техники и подходы использовать, какие тесты нужны).
Основные техники тест-дизайна с простыми примерами
1. Эквивалентное разбиение (Equivalence Partitioning)
Суть: Делим все возможные входные данные на группы (классы эквивалентности), где каждый элемент группы считается одинаково важным для тестирования.
Пример:
Поле «возраст» принимает значения от 1 до 100.
- Класс 1: значения меньше 1 (например, 0, -5) — должны быть отклонены.
- Класс 2: значения от 1 до 100 (например, 25, 50, 99) — должны приниматься.
- Класс 3: значения больше 100 (например, 101, 150) — должны быть отклонены.
Тестируем по одному значению из каждого класса.
2. Анализ граничных значений (Boundary Value Analysis)
Суть: Проверяем значения на границах допустимых диапазонов, так как именно там часто возникают ошибки.
Пример:
Для поля «возраст» (1–100) тестируем:
- 0 (меньше минимума)
- 1 (минимум)
- 100 (максимум)
- 101 (больше максимума)
- 2 и 99 (значения рядом с границами)
3. Попарное тестирование (Pairwise Testing)
Суть: Тестируем все возможные пары значений параметров, чтобы уменьшить количество тестов, но сохранить хорошее покрытие.
Пример:
Есть 2 цвета (красный, синий), 2 размера (маленький, большой), 2 формы (круглая, квадратная).
Все комбинации — 2×2×2 = 8 тестов.
Попарное тестирование позволяет покрыть все пары всего 4 тестами, например:
- красный, маленький, круглая
- красный, большой, квадратная
- синий, маленький, квадратная
- синий, большой, круглая
Такой подход позволяет существенно сократить количество тестов, но обычно позволяет найти 95-99% (если на собеседовании то лучше говорить "большую часть" (вместо процентов)) возможных дефектов.
4. Таблицы принятия решений (Decision Table Testing)
Суть: Используем таблицы, чтобы систематизировать кейсы и наглядно определить какие комбинации условий приводят к каким действиям.
Пример:
Интернет-магазин:
- Клиент зарегистрирован: да/нет
- Товар в наличии: да/нет
- Действие: разрешить покупку/отказать
Тут не стоит придираться к пункту, что если товар есть в наличии, но пользователь не зарегистрирован - Отказать в покупке. Кейс представлен исключительно для примера.
Очевидно, что большинство интернет магазинов "продаст" товар и незарегистрированному покупателю.
5. Сценарное тестирование (Scenario Testing)
Суть: Разрабатываем реальные сценарии использования системы, чтобы проверить, как она работает в «жизни».
Пример:
- Новый пользователь регистрируется
- Добавляет товар в корзину
- Оформляет заказ
- Оплачивает покупку
Проверяем, что все шаги проходят без ошибок.
6. Тестирование состояний и переходов (State Transition Testing)
Суть: Проверяем, как система ведёт себя при переходах из одного состояния в другое.
Пример:
Система управления заказами:
- Состояния: «новый заказ» → «обработка» → «доставка» → «завершено»
Тестируем переходы между состояниями, например, можно ли перейти из «обработка» сразу в «завершено» (не должно быть возможно).
7. Использование чек-листов (Checklists)
Суть: Создаём списки проверок для ключевых функций и проверяем выполнение каждой из них.
Пример:
Чек-лист для интернет-магазина:
- Проверить добавление товара в корзину
- Проверить оформление заказа
- Проверить оплату
- Проверить получение письма с подтверждением
8. Исчерпывающее тестирование (Exhaustive Testing)
Суть: Проверяем все возможные комбинации входных данных и состояний системы.
Пример:
Поле принимает значения от 0 до 9.
Исчерпывающее тестирование — это 10 тестов: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9.
На практике применяется редко, только для очень простых случаев.
9. Предугадывание ошибки (Error Guessing)
Суть: Используем опыт тестировщика, чтобы предугадать, где могут быть ошибки.
Пример:
В прошлом были проблемы с обработкой специальных символов.
Тестировщик вводит в поле имя пользователя: "Иванов@!" — ожидает ошибку или некорректную обработку.
10. Причины и следствия (Cause-Effect Graphing)
Суть: Строим граф, который связывает возможные причины (входные условия) с их следствиями (выходными результатами).
Пример:
В интернет-магазине:
- Причина: клиент добавил товар в корзину
- Следствие: товар отображается в корзине
Граф показывает, что если выполнено условие, то обязательно должен быть результат.
Эти техники помогают структурированно и эффективно покрыть различные аспекты тестируемого программного обеспечения, обеспечивая более высокое качество и надежность продукта.
Вывод:
Тест-дизайн — это не просто набор тестов, а системный подход, который помогает находить ошибки быстро и эффективно. Использование разных техник позволяет покрыть разные типы ошибок и сделать продукт качественнее.
Так же будет интересно:
Вопросы по теории тестирования Джуну
Если Вам интересно, что еще можно найти на канале QA Helper, прочитайте статью: Вместо оглавления. Что вы найдете на канале QA Helper - справочник тестировщика?