Расскажи про свой опыт работы с техниками тест-дизайна

Опыт работы с техниками тест-дизайна

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

Equivalence Partitioning (EP)

Это разделение input значений на группы эквивалентных данных.

Принцип:

• Если тест прошёл для одного значения в группе, значит пройдёт для всех
• Если тест не прошёл, значит не пройдёт для всех в группе

Практический пример: Число для скидки может быть: отрицательное, 0, от 1 до 100, больше 100.

Groupы:
- Invalid: < 0 (представитель: -10)
- Invalid: > 100 (представитель: 150)
- Valid: 0-100 (представитель: 50)

Мой опыт:

• Экономит огромное количество времени
• Вместо тестирования 100 значений, тестирую 3-4
• На проекте с формой регистрации использовал EP для проверки длины пароля

Результат: Вместо 50 тестов я писал 5, но они были намного эффективнее.

Boundary Value Analysis (BVA)

Тестирование значений на границах (edges) диапазонов.

Принцип:

• Баги часто скрываются на границах
• Если функция работает на границе, она должна работать и внутри

Практический пример: Возраст должен быть от 18 до 65 лет:

Тестирую:
- 17 (ниже нижней границы)
- 18 (нижняя граница)
- 19 (выше нижней границы)
- 64 (ниже верхней границы)
- 65 (верхняя граница)
- 66 (выше верхней границы)

Мой опыт:

• Нашёл много багов именно на границах
• На одном проекте баг был в том, что возраст 65 отклонялся (off-by-one ошибка)
• Очень эффективна для числовых значений

Результат: Нашёл критичные баги, которые пропустили разработчики.

Decision Table Testing

Тестирование на основе таблицы решений (decision matrices).

Когда применять:

• Логика зависит от нескольких условий
• Нужно покрыть все комбинации

Практический пример: При оформлении заказа скидка зависит от:

• Статуса пользователя (новый, постоянный, VIP)
• Сумма заказа (меньше 100, 100-500, больше 500)

Таблица:
| Статус | Сумма | Скидка |
|--------|-------|--------|
| Новый | <100 | 0% |
| Новый | 100-500 | 5% |
| Новый | >500 | 10% |
| Постоянный | <100 | 5% |
| Постоянный | 100-500 | 10% |
| Постоянный | >500 | 15% |
| VIP | * | 20% |

Мой опыт:

• Очень полезна для систем с бизнес-логикой
• На проекте с e-commerce использовал decision table для тестирования скидок
• Помогла найти bug когда скидка не применялась для определённой комбинации

State Transition Testing

Тестирование переходов между состояниями.

Когда применять:

• Объект может находиться в разных состояниях
• Переходы между состояниями имеют правила

Практический пример: Заказ может быть в состояниях:

Новый -> Оплачен -> Доставляется -> Доставлен -> Завершён
       -> Отклонён -> Возврат

Тестирую:

• Все валидные переходы работают
• Невалидные переходы блокируются (например, переход из "Доставлен" в "Новый" невозможен)

Мой опыт:

• На проектах с workflow (заказы, заявки, одобрения) это обязательно
• Нашёл баг когда пользователь мог переместить заказ из "Доставлена" обратно в "Оплачен"
• Тестирую как через UI, так и через API

Pairwise Testing (All Pairs)

Тестирование всех пар взаимодействующих параметров.

Принцип:

• Если есть N параметров с M значениями, можно использовать математику чтобы покрыть все пары
• Вместо N^M комбинаций, нужно M^2 тестов

Практический пример: Приложение работает на:

• iOS (10 версий)
• Android (10 версий)
• 5 разных устройств

Все комбинации: 10 x 10 x 5 = 500 Pairwise: примерно 50 тестов

Мой опыт:

• Очень эффективна для параметрического тестирования
• На мобильных проектах используется для комбинаций OS версий и устройств
• Инструмент pairwise generator помогает создать матрицу

Exploratory Testing

Вольное тестирование без предварительно написанных сценариев.

Принцип:

• Тестирую основываясь на знании приложения и интуиции
• Результаты одного теста влияют на следующий

Практический пример:

1. Открываю приложение
2. Вижу что loading медленный — начинаю тестировать performance
3. Замечаю что при медленной сети ошибка не обрабатывается — тестирую offline scenarios
4. Каждый результат диктует следующий шаг

Мой опыт:

• Находит самые неожиданные баги
• Очень хороша для нового приложения когда requirements не ясны
• Требует опыта и интуиции
• На проектах я выделяю 20% времени на exploratory testing

Use Case Testing

Тестирование на основе user scenarios (use cases).

Принцип:

• Тестирую реальные сценарии использования
• Не тестирую изолированные функции

Практический пример: Вместо тестирования каждой кнопки отдельно, тестирую:

Use Case: Пользователь хочет купить товар
1. Поиск товара
2. Просмотр детали
3. Добавление в корзину
4. Оформление заказа
5. Оплата
6. Получение подтверждения

Мой опыт:

• Это то, как реально используют приложение
• Находит интеграционные баги
• На каждом проекте пишу основные use case-ы и их тестирую

Error Guessing

Предположение ошибок на основе опыта и знаний.

Принцип:

• Опытный QA может предугадать где вероятнее всего баги
• Основывается на паттернах из прошлого опыта

Примеры:

• Баги часто на границах
• Баги часто в обработке ошибок
• Баги часто в асинхронном коде
• Баги часто в очень новых или очень старых браузерах

Мой опыт:

• Со временем вырабатывается интуиция
• "Это выглядит подозрительно" и обычно там баг
• Комбинирую с другими техниками для лучшего результата

Как я применяю техники в реальной работе

Для простых функций:

• Equivalence Partitioning + Boundary Value Analysis
• Быстро, эффективно

Для функций с логикой:

• Decision Table Testing
• Убежусь что все комбинации работают

Для workflow-ов:

• State Transition Testing
• Проверю все переходы

Для кросс-платформенных приложений:

• Pairwise Testing
• Покрою максимум комбинаций с минимум тестов

Для новых приложений:

• Exploratory Testing
• Найду неожиданные баги

Для реальных сценариев:

• Use Case Testing
• Буду тестировать как настоящий пользователь

Вывод

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