Как определить, какие тесты выполнять вручную?

Стратегия отбора тестов для ручного выполнения

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

Критерии для отбора ручных тестов

1. Тесты с низкой рентабельностью автоматизации

• Разовые или редко выполняемые проверки (например, тестирование миграции данных раз в квартал)
• Сценарии с нестабильными или отсутствующими элементами в автоматизации (капчи, сторонние виджеты)
• Проверки, требующие сложной настройки окружения, которая не поддается стабильной автоматизации

# Пример: тест с капчей НЕ подходит для автоматизации
def test_login_with_captcha():
    # Автоматическое распознавание капчи ненадежно и часто нарушает TOS
    # Такой тест остаётся ручным
    pass

2. Исследовательское и ad-hoc тестирование

• Первичное исследование нового функционала до формализации требований
• Тестирование на основании интуиции и опыта тестировщика
• Проверка в условиях неполных или противоречивых требований

3. Визуальные и юзабилити-проверки

• Верстка и отображение UI на различных разрешениях и устройствах
• Соответствие дизайн-макетам и гайдлайнам
• Проверка цветов, шрифтов, отступов (Pixel-perfect testing)
• Удобство интерфейса и логика пользовательского потока

4. Тестирование, требующее физического взаимодействия

• Работа с периферийными устройствами (сканеры, принтеры, платежные терминалы)
• Мобильное тестирование с жестами (мультитач, свайпы, вращение)
• Тестирование аппаратных зависимостей (датчики, GPS, камера)

Практическая методика принятия решений

Я использую матрицу приоритизации по двум осям:

1. Частота выполнения (часто/редко)
2. Сложность автоматизации (легко/сложно)

Частота выполнения
    ↑
Часто | Автоматизируем | Автоматизируем с осторожностью
Редко | Ручные/полуавто | Ручные тесты
    ----------------------→ Сложность автоматизации

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

Тестирование интеграций со сторонними сервисами:

• Платежные системы в разных сценариях (успех/отказ/возврат)
• СМС и email-рассылки с проверкой реальных сообщений
• Сторонние API с квотами или лимитами

Кросс-браузерное и кроссплатформенное тестирование:

// Автоматизация может проверить функциональность,
// но только ручное тестирование оценит:
// - Плавность анимаций в Safari
// - Рендеринг кастомных шрифтов в Firefox
// - Поведение dropdown на мобильных устройствах

Тестирование в условиях нестабильного окружения:

• Работа при потере сети и восстановлении соединения
• Поведение при низкой производительности устройства
• Тестирование с разной локализацией (RTL-языки, длинные тексты)

Процесс регулярного пересмотра ручных тестов

1. Ежеквартальный аудит ручных тест-кейсов
2. Анализ частоты падения автоматизированных тестов в определенных областях
3. Оценка изменения приоритетов и требований бизнеса
4. Учет feedback от команды разработки о стабильности компонентов

Ключевые показатели для мониторинга

• Время выполнения ручного регресса vs автоматизированного
• Стоимость обнаружения дефекта в каждом подходе
• Количество regression bugs, пропущенных автоматизацией
• Скорость реакции на критические изменения в продукте

Итоговое правило: тест остается ручным, если стоимость и время его автоматизации превышают выгоду от автоматизации в разумных пределах (обычно 3+ запуска ручного теста). Однако это решение должно регулярно пересматриваться, так как с развитием инструментов автоматизации и стабилизацией продукта, некоторые ручные тесты могут переходить в автоматизированные. Главное — сохранять баланс между скоростью feedback и надежностью проверок.