Какими техниками тест-дизайна пользовался

# Техники тест-дизайна в моей практике

Тест-дизайн — это искусство выбрать минимальное количество тестов, которые максимально покроют функционал. За 10+ лет я использовал различные техники в зависимости от задачи.

1. Boundary Value Analysis (BVA)

Суть: Тестируем граничные значения input-ов.

Почему: Большинство багов находятся на границах. Например, в условии if(age > 18) баги часто при age = 18, 19, -1.

Пример — функция calcAge(birthYear):

Текущий год = 2025
- Минимум: birthYear = 1925 (100 лет)
- Граница мин: birthYear = 1924 (101 год)
- Максимум: birthYear = 2025 (0 лет) — невалидно
- Граница макс: birthYear = 2024 (1 год)

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

2. Equivalence Partitioning (EP)

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

Почему: Если value=5 и value=50 обрабатываются одинаково, зачем тестировать оба? Достаточно одного.

Пример — система скидок:

Партиция 1: 0 < price < 100 → скидка 0%
Партиция 2: 100 <= price < 500 → скидка 5%
Партиция 3: 500 <= price < 1000 → скидка 10%
Партиция 4: price >= 1000 → скидка 15%
Партиция 5: price < 0 → ошибка

Тестируем: price = 50, 150, 600, 1500, -10. Не нужно тестировать все значения!

3. Decision Table Testing (также Decision Coverage)

Суть: Когда есть несколько условий, создаём таблицу всех комбинаций и тестируем каждую.

Пример — правила одобрения кредита:

| Age | Income | Credit Score | Previous Loans | Decision  |
|----|--------|---------------|----------------|----------|
| Y  | Y      | Y             | N              | Approve  |
| Y  | Y      | Y             | Y (many)       | Decline  |
| Y  | Y      | N             | Y              | Decline  |
| Y  | N      | Y             | N              | Decline  |
| N  | Y      | Y             | N              | Decline  |

Вместо того, чтобы случайно комбинировать, тестируем все 2^4 = 16 комбинаций (или подмножество важных).

Когда использую: При работе с бизнес-логикой, rules engines, approval systems.

4. Pairwise Testing

Суть: Если у нас 5+ параметров, полный перебор (5! комбинаций) — очень дорого. Pairwise гарантирует, что каждая пара параметров протестирована.

Пример:

Параметры: Browser (3 значения) × OS (3) × Device (3) × Network (3) = 81 комбинация
Pairwise: ~9-12 комбинаций, где каждая пара browser+OS, browser+Device и т.д. есть.

Инструмент: PICT (Microsoft), AllPairs

5. State Transition Testing

Суть: Тестируем переходы между состояниями системы.

Пример — жизненный цикл заказа:

Ордер:
Pending → Processing → Shipped → Delivered → Closed
Pending → Processing → Cancelled ✓
Pending → Delivered ✗ (невалидный переход)
Pending → Pending → Processing (повторный переход)

Когда использую: FSM (Finite State Machines), workflow-ы, game state management.

6. Use Case Testing

Суть: Тестируем основные user journeys на основе use case-ов.

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

Main flow:
1. Пользователь ищет товар
2. Добавляет в корзину
3. Переходит в checkout
4. Вводит адрес доставки
5. Выбирает способ оплаты
6. Подтверждает заказ

Alternate flows:
- Товар out of stock → предложить похожий
- Адрес невалиден → ошибка
- Платёж отклонён → retry
- Пользователь уходит → recover cart

7. Error Guessing

Суть: На основе опыта угадываем, где могут быть баги.

Примеры моих предположений:

• SQL Injection при работе с user input
• Race conditions при параллельных операциях
• Off-by-one errors в loops
• Null pointer exceptions
• Timezone issues при работе с датами
• Integer overflow
• Empty string vs null

Это не техника в чистом виде, это skill, который приходит с опытом.

8. Mutation Testing

Суть: Автоматически вносим мутации в код (меняем > на >=) и проверяем, что тесты их ловят.

Инструменты: Stryker (JavaScript), mutmut (Python)

Пример:

# Оригинальный код
if age >= 18:
    allow_purchase()

# Мутация 1: меняем >= на >
if age > 18:
    allow_purchase()

# Мутация 2: удаляем условие
allow_purchase()

# Тесты должны упасть на обеих мутациях

9. Exploratory Testing

Суть: Неструктурированное тестирование с проверкой граничных случаев "на лету".

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

Мой процесс:

1. Читаю требования
2. Делаю mind map возможных путей
3. Тестирую happy path
4. Добавляю variations (invalid input, edge cases)
5. Пробую сломать (что если я быстро кликну дважды, откроет ли modal twice?)

10. Risk-Based Testing

Суть: Приоритизируем тесты на основе вероятности бага и его impact-а.

Матрица риска:

| Область        | Вероятность | Impact | Priority |
|---|---|---|---|
| Payment        | High        | High   | Critical |
| Login          | Medium      | High   | High     |
| Settings       | Low         | Low    | Low      |
| Dark mode      | Low         | Low    | Lowest   |

Когда использую: Когда времени не хватает и нужно выбрать, что тестировать в первую очередь.

Мой реальный workflow

Обычно я комбинирую несколько техник для конкретной задачи:

Для авторизации:

1. Use case testing (основные сценарии входа/выхода)
2. BVA (пусто, max length пароля, special chars)
3. Error guessing (SQL injection, XSS в username)
4. State transition (logged out → logging in → logged in)

Для формы оплаты:

1. Equivalence partitioning (валидные карты, невалидные)
2. BVA (пусто, очень длинные номера)
3. Decision table (различные комбинации валид expiry + CVV)
4. Error guessing (race condition при повторном клике)

Для complex бизнес-логики:

1. Decision table testing (все комбинации условий)
2. State transition (разные статусы заказа)
3. Boundary analysis (лимиты на скидки, налоги)
4. Risk-based (сначала критичные пути)

Основной принцип: выбираю минимум тестов с максимальным coverage. Нет смысла тестировать все 10000 значений, если я могу репрезентативно покрыть функционал с 50-ю.