Техники Тест-Дизайна: Полное Руководство для Собеседований QA

Освойте все техники тест-дизайна с практическими примерами. От классов эквивалентности до переходов состояний - всё для успешного собеседования

🎯 Зачем эта статья?

Почти на каждом QA собеседовании вы услышите:

“Какие техники тест-дизайна вы знаете? Приведите пример.”

Многие кандидаты могут назвать техники, но затрудняются с реальными примерами. Эта статья научит вас:

• ✅ Всем основным техникам тест-дизайна
• ✅ Реальным примерам для каждой
• ✅ Когда какую технику использовать
• ✅ Типичным вопросам собеседования с ответами
• ✅ Практическим упражнениям

К концу статьи вы уверенно ответите на любой вопрос о тест-дизайне на собеседовании.

📋 Содержание

1. Что такое тест-дизайн?
2. Классы эквивалентности
3. Анализ граничных значений
4. Таблица решений
5. Тестирование переходов состояний
6. Попарное тестирование
7. Предугадывание ошибок
8. Тестирование сценариев использования
9. Исследовательское тестирование
10. Вопросы и ответы для собеседований
11. Практические упражнения

🎨 Что такое тест-дизайн?

Проблема

Представьте тестирование простой формы логина:

• Имя пользователя (1-50 символов)
• Пароль (8-20 символов)
• Чекбокс “Запомнить меня”

Сколько тест-кейсов вам нужно?

Если тестировать ВСЕ возможные комбинации:

• Имя пользователя: миллиарды комбинаций
• Пароль: ещё больше
• Чекбокс: 2 состояния

Результат: Бесконечные тесты, невозможно выполнить!

Решение: Техники тест-дизайна

Техники тест-дизайна помогают:

• ✅ Сократить тест-кейсы до управляемого количества
• ✅ Максимизировать тестовое покрытие
• ✅ Находить баги эффективно
• ✅ Экономить время и ресурсы

Black-Box vs White-Box

Black-Box тестирование (фокус этой статьи):

• Тестирование без знания внутреннего кода
• На основе требований и спецификаций
• Техники: Классы эквивалентности, Граничные значения и т.д.

White-Box тестирование:

• Тестирование со знанием кода
• На основе структуры кода
• Техники: Покрытие операторов, Покрытие ветвей и т.д.

📦 Классы Эквивалентности (Equivalence Partitioning)

Что это?

Разделение входных данных на группы (классы), где все значения в группе должны вести себя одинаково.

Ключевая идея: Если одно значение в классе работает, все значения в этом классе должны работать.

Реальный пример: Валидация возраста

Требование: Пользователь должен быть от 18 до 65 лет для регистрации.

Без EP: Тестируем возраст 1, 2, 3, 4… 100 = 100 тест-кейсов

С EP: Делим на классы:

Результат: Нужно только 4 тест-кейса!

Тест-кейсы

Тест-кейс 1: Возраст = 10
  Ввод: age = 10
  Ожидание: Ошибка "Вам должно быть минимум 18 лет"
  Класс: Невалидный (слишком молод)

Тест-кейс 2: Возраст = 30
  Ввод: age = 30
  Ожидание: Регистрация успешна
  Класс: Валидный

Тест-кейс 3: Возраст = 70
  Ввод: age = 70
  Ожидание: Ошибка "Максимальный возраст 65"
  Класс: Невалидный (слишком стар)

Тест-кейс 4: Возраст = -5
  Ввод: age = -5
  Ожидание: Ошибка "Некорректный возраст"
  Класс: Невалидный (отрицательный)

Ещё один пример: Валидация email

Требование: Нужен корректный формат email

Классы:

Когда использовать EP?

• ✅ Поля ввода с диапазонами
• ✅ Выпадающие списки
• ✅ Любой ввод с валидными/невалидными категориями
• ✅ Когда нужно сократить тест-кейсы

🎯 Анализ Граничных Значений (Boundary Value Analysis)

Что это?

Тестирование на краях (границах) классов эквивалентности. Баги любят прятаться на границах!

Ключевая идея: Тестируем минимум, максимум и значения сразу внутри/снаружи границы.

Зона багов

       Невалидный |     Валидный    |   Невалидный
    ←-------------|-----------------|-------------→
                 18                65
                  ↑                ↑
              ГРАНИЦА          ГРАНИЦА
              
    Большинство багов ЗДЕСЬ на границах!

Реальный пример: Валидация возраста (продолжение)

Требование: Пользователь должен быть 18-65 лет

Тестовые значения BVA:

Тест-кейсы

Тест-кейс 1: Возраст = 17 (граница - 1)
  Ввод: age = 17
  Ожидание: Ошибка "Вам должно быть минимум 18"
  
Тест-кейс 2: Возраст = 18 (нижняя граница)
  Ввод: age = 18
  Ожидание: Успех
  
Тест-кейс 3: Возраст = 19 (граница + 1)
  Ввод: age = 19
  Ожидание: Успех
  
Тест-кейс 4: Возраст = 64 (граница - 1)
  Ввод: age = 64
  Ожидание: Успех
  
Тест-кейс 5: Возраст = 65 (верхняя граница)
  Ввод: age = 65
  Ожидание: Успех
  
Тест-кейс 6: Возраст = 66 (граница + 1)
  Ввод: age = 66
  Ожидание: Ошибка "Максимальный возраст 65"

Ещё один пример: Длина пароля

Требование: Пароль должен быть 8-20 символов

Тестовые значения BVA:

EP + BVA вместе

Лучшая практика: Всегда комбинируйте EP и BVA!

Шаг 1: Определяем классы (EP)
  - Невалидный: < 8 символов
  - Валидный: 8-20 символов
  - Невалидный: > 20 символов

Шаг 2: Тестируем границы (BVA)
  - 7 символов (граница - 1)
  - 8 символов (нижняя граница)
  - 9 символов (граница + 1)
  - 19 символов (граница - 1)
  - 20 символов (верхняя граница)
  - 21 символ (граница + 1)

Шаг 3: Тестируем одно значение из каждого класса (EP)
  - 5 символов (невалидный класс)
  - 15 символов (валидный класс)
  - 25 символов (невалидный класс)

📊 Таблица Решений (Decision Table Testing)

Что это?

Тестирование комбинаций условий и соответствующих действий. Идеально для сложной бизнес-логики!

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

Реальный пример: Калькулятор стоимости доставки

Бизнес-правила:

• Если заказ > $100 И премиум-член → Бесплатная доставка
• Если заказ > $100 И обычный член → $5 доставка
• Если заказ ≤ $100 И премиум-член → $5 доставка
• Если заказ ≤ $100 И обычный член → $10 доставка

Таблица решений:

Тест-кейсы из таблицы решений

Тест-кейс 1: Правило 1
  Условия:
    - Сумма заказа: $150 (> $100)
    - Тип членства: Премиум
  Ожидание: Бесплатная доставка ($0)

Тест-кейс 2: Правило 2
  Условия:
    - Сумма заказа: $150 (> $100)
    - Тип членства: Обычный
  Ожидание: Доставка $5

Тест-кейс 3: Правило 3
  Условия:
    - Сумма заказа: $50 (≤ $100)
    - Тип членства: Премиум
  Ожидание: Доставка $5

Тест-кейс 4: Правило 4
  Условия:
    - Сумма заказа: $50 (≤ $100)
    - Тип членства: Обычный
  Ожидание: Доставка $10

Ещё один пример: Система логина

Бизнес-правила:

• Валидный логин И валидный пароль → Успешный вход
• Валидный логин И невалидный пароль → “Неверный пароль”
• Невалидный логин И любой пароль → “Пользователь не найден”
• Пустой логин ИЛИ пустой пароль → “Заполните все поля”

Таблица решений:

Когда использовать таблицы решений?

• ✅ Множество условий влияют на результат
• ✅ Сложные бизнес-правила
• ✅ Разные комбинации дают разные результаты
• ✅ Платежные системы, скидки, права доступа

🔄 Тестирование Переходов Состояний (State Transition Testing)

Что это?

Тестирование поведения системы при переходе между различными состояниями на основе событий/действий.

Ключевая идея: Определяем состояния, события, вызывающие переходы, и действия.

Реальный пример: Статус онлайн-заказа

Состояния:

1. Корзина → 2. Ожидает оплаты → 3. Оплачен → 4. Отправлен → 5. Доставлен

Диаграмма переходов состояний:

    [Корзина]
       |
       | (Оформить заказ)
       ↓
[Ожидает оплаты]
       |
       | (Оплатить)      | (Отменить)
       ↓                 ↓
   [Оплачен]        [Отменён]
       |
       | (Отправить)
       ↓
  [Отправлен]
       |
       | (Доставить)
       ↓
  [Доставлен]

Таблица переходов состояний:

Тест-кейсы

Тест-кейс 1: Успешный путь - Полный заказ
  Состояния: Корзина → Ожидает → Оплачен → Отправлен → Доставлен
  Шаги:
    1. Добавить товар в корзину
    2. Оформить заказ → Статус: Ожидает оплаты
    3. Оплатить → Статус: Оплачен
    4. Админ отправляет → Статус: Отправлен
    5. Доставка подтверждена → Статус: Доставлен

Тест-кейс 2: Отмена заказа
  Состояния: Корзина → Ожидает → Отменён
  Шаги:
    1. Добавить товар в корзину
    2. Оформить заказ → Статус: Ожидает оплаты
    3. Отменить заказ → Статус: Отменён

Тест-кейс 3: Невалидный переход
  Текущее состояние: Доставлен
  Действие: Попытка отменить
  Ожидание: Ошибка "Нельзя отменить доставленный заказ"

Ещё один пример: Валидация PIN в банкомате

Состояния:

• Разблокирован (карта вставлена, 3 попытки)
• Заблокирован (слишком много неверных PIN)

Диаграмма состояний:

                    [Карта вставлена]
                          |
                    3 попытки осталось
                          |
     Неверный PIN         |         Верный PIN
     ←-------------[Попытка 1]-------------→ [Разблокирован]
           |              ↓
           |        2 попытки осталось
           |              |
           | Неверный PIN |         Верный PIN
           ←-------[Попытка 2]-------------→ [Разблокирован]
           |              ↓
           |        1 попытка осталась
           |              |
           | Неверный PIN |         Верный PIN
           ←-------[Попытка 3]-------------→ [Разблокирован]
                          ↓
                   [Заблокирован]
                   Карта изъята

Тест-кейсы для банкомата

Тест-кейс 1: Правильный PIN с первой попытки
  Начало: Карта вставлена, 3 попытки
  Действие: Ввести правильный PIN
  Ожидание: Счёт разблокирован

Тест-кейс 2: Правильный PIN со второй попытки
  Начало: Карта вставлена, 3 попытки
  Действие: Неверный PIN → Верный PIN
  Ожидание: Счёт разблокирован, показано предупреждение

Тест-кейс 3: Карта заблокирована после 3 неверных попыток
  Начало: Карта вставлена, 3 попытки
  Действие: Неверный PIN × 3
  Ожидание: Карта заблокирована и изъята

🔗 Попарное Тестирование (Pairwise Testing)

Что это?

Тестирование всех возможных пар входных параметров. Основано на том, что большинство багов вызвано взаимодействием двух параметров.

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

Проблема

Тестирование совместимости браузеров:

• ОС: Windows, macOS, Linux (3 варианта)
• Браузер: Chrome, Firefox, Safari, Edge (4 варианта)
• Язык: English, Spanish, French (3 варианта)

Все комбинации: 3 × 4 × 3 = 36 тест-кейсов

Решение Pairwise

Pairwise покрывает все пары меньшим количеством тестов:

Результат: Всего 9 тест-кейсов вместо 36!

Проверка покрытия

Проверим, что все пары покрыты:

Пары ОС + Браузер:

• Windows + Chrome ✅ (Тест 1)
• Windows + Firefox ✅ (Тест 2)
• Windows + Safari ✅ (Тест 3)
• macOS + Chrome ✅ (Тест 4)
• … (все покрыты)

Пары ОС + Язык:

• Windows + English ✅ (Тест 1)
• Windows + Spanish ✅ (Тест 2)
• … (все покрыты)

Инструменты для Pairwise

• PICT (Microsoft) - Бесплатный command-line инструмент
• AllPairs - Онлайн генератор
• Hexawise - Коммерческий инструмент

Когда использовать Pairwise?

• ✅ Много входных параметров
• ✅ Конфигурационное тестирование
• ✅ Тестирование совместимости
• ✅ Когда полное покрытие слишком дорого

🔮 Предугадывание Ошибок (Error Guessing)

Что это?

Использование опыта и интуиции для предугадывания, где могут прятаться баги. Не формальная техника, но очень эффективная!

Ключевая идея: Думайте как тестировщик - где ВЫ ожидаете баги?

Типичные проблемные области

1. Пустые/Null значения

- Пустая строка ""
- Null значение
- Только пробелы "   "
- Только спецсимволы "!@#$%"

2. Граничные значения (экстремальные)

- 0
- Отрицательные числа (-1)
- Очень большие числа (999999999)
- Максимальный integer (2147483647)
- Десятичная точность (0.00001)

3. Специальные символы

- Кавычки: ' " ` 
- HTML: < > & 
- SQL: ; -- ' OR 1=1
- Unicode: 中文 العربية 🎉
- Escape: \n \t \r

4. Крайние случаи дат/времени

- Високосный год (29 февраля)
- Границы месяцев (31 января + 1 день)
- Часовые пояса
- Переход на летнее время
- Проблемы 2000, 2038 годов

5. Проблемы загрузки файлов

- Пустой файл (0 байт)
- Очень большой файл (1GB+)
- Неверное расширение
- Исполняемые файлы (.exe, .bat)
- Двойные расширения (image.jpg.exe)

Пример: Тестирование функции поиска

Что бы вы тестировали?

Очевидные тесты:
- Валидный поисковый запрос → Результаты найдены
- Нет совпадений → "Ничего не найдено"

Тесты с предугадыванием ошибок:
- Пустой поиск → Как обработается?
- Только пробелы → "   " 
- Очень длинный запрос → 1000+ символов
- Специальные символы → <script>alert('xss')</script>
- SQL инъекция → ' OR '1'='1
- Unicode → 日本語 العربية
- Только цифры → 12345
- Один символ → "a"

Чек-лист предугадывания ошибок

Всегда тестируйте это:

📖 Тестирование Сценариев Использования (Use Case Testing)

Что это?

Тестирование полных пользовательских сценариев от начала до конца. Основано на реальном использовании системы.

Ключевая идея: Тестируем реалистичные пути пользователя, а не отдельные функции.

Структура Use Case

Use Case: [Название]
Актор: [Кто выполняет действие]
Предусловия: [Что должно быть истинно до начала]
Основной поток: [Пошаговый успешный путь]
Альтернативные потоки: [Вариации]
Постусловия: [Что истинно после]

Пример: Покупка в онлайн-магазине

Use Case: Оформление покупки

Актор: Зарегистрированный покупатель

Предусловия:
- Пользователь авторизован
- В корзине есть товары
- У пользователя есть платёжный метод

Основной поток (Happy Path):
1. Пользователь просматривает корзину
2. Пользователь нажимает "Оформить заказ"
3. Система показывает варианты доставки
4. Пользователь выбирает способ доставки
5. Система показывает варианты оплаты
6. Пользователь вводит платёжные данные
7. Пользователь нажимает "Оформить заказ"
8. Система обрабатывает платёж
9. Система показывает подтверждение заказа
10. Система отправляет email с подтверждением

Альтернативные потоки:
A1. Пустая корзина (на шаге 1):
    - Система показывает "Ваша корзина пуста"
    - Поток завершается

A2. Платёж отклонён (на шаге 8):
    - Система показывает "Платёж отклонён"
    - Возврат к шагу 6

A3. Нет в наличии (на шаге 7):
    - Система показывает "Товар недоступен"
    - Возврат к шагу 1

Постусловия:
- Заказ создан в системе
- Платёж обработан
- Email с подтверждением отправлен
- Остатки обновлены

Тест-кейсы из Use Case

Тест-кейс 1: Happy Path
  Предусловия: Авторизован, товары в корзине
  Шаги: Следуем основному потоку 1-10
  Ожидание: Заказ подтверждён, email получен

Тест-кейс 2: Пустая корзина
  Предусловия: Авторизован, корзина пуста
  Шаги: Нажать оформить заказ
  Ожидание: "Ваша корзина пуста"

Тест-кейс 3: Платёж отклонён
  Предусловия: Авторизован, товары в корзине
  Шаги: Использовать невалидную карту
  Ожидание: "Платёж отклонён", остаёмся на странице оплаты

Тест-кейс 4: Нет в наличии
  Предусловия: Последний товар на складе
  Шаги: Другой пользователь покупает его первым, затем оформляем заказ
  Ожидание: "Товар недоступен"

🔍 Исследовательское Тестирование (Exploratory Testing)

Что это?

Одновременное обучение, проектирование тестов и выполнение. Нет заранее определённых тест-кейсов - вы исследуете и открываете!

Ключевая идея: Используйте креативность и любопытство для поиска багов, которые пропускают скриптовые тесты.

Структура: Сессионное тестирование

Сессии с ограничением по времени:

• Длительность: 45-90 минут
• Чёткая цель (charter)
• Ведение заметок о находках
• Обсуждение после сессии

Пример Charter сессии

Charter: Исследовать функциональность сброса пароля

Области фокуса:
- Happy path сброса
- Обработка ошибок
- Соображения безопасности
- Крайние случаи

Время: 60 минут

Вопросы для ответа:
- Что происходит с невалидным email?
- Можно ли использовать ссылку сброса дважды?
- Истекает ли ссылка?
- Можно ли сбросить на тот же пароль?

Шаблон заметок сессии

Отчёт сессии
============
Тестировщик: [Имя]
Дата: [Дата]
Длительность: 60 минут
Charter: Исследовать сброс пароля

НАХОДКИ:
--------
Баг #1: Ссылка сброса не истекает
  Серьёзность: Высокая
  Шаги: Использовать ссылку недельной давности
  Ожидание: "Ссылка истекла"
  Факт: Пароль успешно изменён

Баг #2: Нет предупреждения о слабом пароле
  Серьёзность: Средняя
  Шаги: Сбросить на "123456"
  Ожидание: Предупреждение о слабом пароле
  Факт: Пароль принят без предупреждения

ВОПРОСЫ:
--------
- Есть ли лимит на запросы сброса?
- Что происходит если email не существует?

НЕПОКРЫТЫЕ ОБЛАСТИ:
-------------------
- Множественные запросы сброса
- Мобильное адаптивное тестирование

Эвристики исследовательского тестирования

Эвристика SFDPOT:

❓ Вопросы и Ответы для Собеседований

Вопрос 1: “Что такое классы эквивалентности?”

Хороший ответ:

“Классы эквивалентности - это техника тест-дизайна, где мы разделяем входные данные на группы, которые должны вести себя одинаково. Вместо тестирования каждого возможного значения, мы тестируем одно значение из каждого класса. Например, тестируя поле возраста с требованием 18-65 лет: мы создаём классы для ‘слишком молодых’ (0-17), ‘валидных’ (18-65) и ‘слишком старых’ (66+). Нам нужно всего 3 теста вместо тестирования каждого возраста.”

Вопрос 2: “Чем BVA отличается от EP?”

Хороший ответ:

“В то время как EP делит входные данные на классы и тестирует одно значение из каждого, BVA специально фокусируется на границах между классами. Баги часто прячутся на границах - точный минимум, максимум и значения прямо до/после. Для требования возраста 18-65, BVA тестировал бы: 17, 18, 19, 64, 65, 66 - точные граничные значения.”

Вопрос 3: “Когда бы вы использовали таблицу решений?”

Хороший ответ:

“Таблицу решений лучше всего использовать когда есть множество условий, создающих разные результаты. Например, калькулятор стоимости доставки, где стоимость зависит от суммы заказа И типа членства. Я бы создал таблицу со всеми комбинациями условий и ожидаемыми результатами. Это гарантирует, что мы не пропустим ни одной комбинации и делает тест-кейсы очень понятными.”

Вопрос 4: “Приведите пример тестирования переходов состояний”

Хороший ответ:

“Отличный пример - валидация PIN в банкомате. Состояния: ‘Активен’ с 3 попытками, потом 2 попытки, потом 1 попытка, наконец ‘Заблокирован’. События - ‘верный PIN’ или ‘неверный PIN’. Я бы тестировал: верный с первой попытки, верный после одного неверного, верный после двух неверных, и три неверных PIN ведущих к блокировке. Также я бы проверил, что нельзя перейти из Заблокирован обратно в Активен без замены карты.”

Вопрос 5: “В чём разница между black-box и white-box тестированием?”

Хороший ответ:

“Black-box тестирование означает, что я тестирую систему без знания внутреннего кода - фокусируюсь на входах и выходах на основе требований. Техники включают EP, BVA, таблицы решений. White-box тестирование означает, что я вижу код и проектирую тесты на основе структуры кода - тестирую все ветви, операторы, пути. Как QA, я в основном использую black-box техники, но понимание обоих помогает общаться с разработчиками.”

Вопрос 6: “Как вы решаете, какую технику использовать?”

Хороший ответ:

“Я выбираю на основе тестируемой функции:

• Простые поля ввода → EP + BVA
• Сложные бизнес-правила → Таблицы решений
• Workflow/процессы → Переходы состояний
• Много конфигурационных опций → Pairwise
• Новые функции которые изучаю → Исследовательское

Часто я комбинирую несколько техник. Для формы логина я бы использовал EP для валидных/невалидных входов, BVA для границ длины пароля, и предугадывание ошибок для спецсимволов и SQL инъекций.”

📝 Практические Упражнения

Упражнение 1: Форма регистрации

Требования:

• Имя пользователя: 3-20 символов, только буквы и цифры
• Пароль: 8-16 символов, должен содержать хотя бы одну цифру
• Возраст: 13-120 лет
• Email: валидный формат email

Ваша задача:

1. Создать классы эквивалентности для каждого поля
2. Определить граничные значения
3. Написать минимум 10 тест-кейсов

Упражнение 2: Система скидок

Бизнес-правила:

• Заказы > $200 И лояльный клиент → скидка 20%
• Заказы > $200 И не участник → скидка 10%
• Заказы $100-200 И лояльный клиент → скидка 10%
• Заказы $100-200 И не участник → скидка 5%
• Заказы < $100 → Без скидки

Ваша задача:

1. Создать таблицу решений
2. Написать тест-кейсы для каждого правила

Упражнение 3: Состояния видео-стриминга

Требования: Видеоплеер имеет состояния: Остановлен, Воспроизводится, Пауза, Буферизация

Действия:

• Play, Pause, Stop, Seek

Ваша задача:

1. Нарисовать диаграмму переходов состояний
2. Создать таблицу переходов
3. Написать тест-кейсы для валидных и невалидных переходов

[Остановлен] --Play--> [Воспроизводится]
[Воспроизводится] --Pause--> [Пауза]
[Воспроизводится] --Stop--> [Остановлен]
[Воспроизводится] --НужнаБуферизация--> [Буферизация]
[Пауза] --Play--> [Воспроизводится]
[Пауза] --Stop--> [Остановлен]
[Буферизация] --БуферизацияЗавершена--> [Воспроизводится]

🎯 Ключевые выводы

Краткий справочник по техникам

Советы для собеседований

1. Всегда приводите примеры - Не просто определяйте, демонстрируйте
2. Объясняйте ход мыслей - Проходите через ваш подход
3. Комбинируйте техники - Показывайте, что знаете когда что использовать
4. Будьте практичны - Связывайте с реальными сценариями
5. Задавайте вопросы - Уточняйте требования перед проектированием тестов

Ресурсы для практики

• Software Testing Help - Бесплатные туториалы
• Ministry of Testing - Сообщество и ресурсы
• ISTQB Foundation - Подготовка к сертификации
• Test Automation University - Бесплатные курсы

📍 Что дальше?

Теперь, когда вы понимаете техники тест-дизайна, продолжайте ваш QA путь:

• Статья 1: Основы подготовки к QA собеседованию
• Статья 2: Продвинутые темы и практика
• Статья 3: DSA для QA инженеров
• Статья 4: Фреймворки автоматизации тестирования
• Статья 5: CI/CD для QA инженеров

Была ли статья полезна? 👏

Вопросы? Пишите в комментариях!

Автор: AAnnayev — Senior SDET

Tags: #QA #Testing #TestDesign #Interview #ManualTesting #Techniques