Автоматизировать стоит регулярные, повторяющиеся и критичные тесты, где автоматизация экономит время и снижает риски.
Главные кандидаты:
Не стоит автоматизировать: нестабильные, редко используемые или сильно визуальные проверки (например, сложные UI-анимации).
Автоматизация нужна, чтобы:
ускорить регресс,
снизить влияние человеческого фактора,
обеспечить постоянный контроль качества (через CI/CD).
Но автоматизировать “всё подряд” нельзя — важно выбирать то, что стабильно и окупается по времени.
Повторяемость — выполняются часто (регресс, smoke).
Стабильность — поведение функционала редко меняется.
Предсказуемость результата — “ожидаемое” состояние можно формализовать.
Критичность — ошибки влияют на бизнес.
Затраты оправданы — время написания автотеста < время ручных проверок за 2–3 релиза.
| Тип проверки | Автоматизировать? | Почему |
|---|---|---|
| Логин / логаут | ✅ | Критично и повторяется |
| Перевод между счетами | ✅ | Основной бизнес-процесс |
| Просмотр истории операций | ✅ | Часто проверяется |
| Изменение аватара профиля | ❌ | Второстепенно |
| Проверка адаптивной вёрстки | ❌ | Лучше вручную |
Автотесты запускаются при каждом билде (через CI/CD).
Отчёты сохраняются (Allure, TestOps, Jenkins).
Ручное тестирование фокусируется на новых и сложных сценариях.
Пример пайплайна:
1. Build → Unit tests 2. Deploy → API автотесты 3. Smoke UI → Selenium / Playwright 4. Load tests → k6 / JMeter
В QA-команде банка:
Автоматизированы 60% регресс-тестов (API + UI).
Smoke-ран через Jenkins при каждом коммите.
Время регресса сократилось с 5 дней до 2 дней.
QA вручную тестируют только новые сценарии.
Автоматизировать стоит регулярные, стабильные, критичные сценарии, которые часто повторяются и дают максимальную экономию времени.
Основной фокус: регресс, smoke, API, критичные бизнес-потоки.
Остальное — по принципу “окупаемости и стабильности”.
Чтобы пожаловаться или сообщить об ошибке, войдите в аккаунт или зарегистрируйтесь.