> For the complete documentation index, see [llms.txt](https://vladislaveremeev.gitbook.io/qa_bible/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://vladislaveremeev.gitbook.io/qa_bible/avtomatizaciya-testirovaniya/osnovy/chto-nuzhno-avtomatizirovat.md).

# Что автоматизировать

Автоматизация требует инвестиций: времени на написание, поддержку и обновление тестов. Правильный вопрос — не «всё ли можно автоматизировать?», а «что даёт наибольшую отдачу?». Неправильно выбранные цели приводят к дорогому, хрупкому суиту, который команда перестаёт доверять.

## Что следует автоматизировать

### Высокоприоритетные кандидаты

* **Регрессионное тестирование критической функциональности** — авторизация, оплата, ключевые бизнес-процессы. Эти тесты нужны при каждом изменении кода
* **Часто повторяющиеся проверки** — smoke и sanity тесты, запускаемые на каждый PR или деплой
* **Data-driven сценарии** — одна логика с большим количеством входных данных (формы, валидация, граничные значения)
* **Backend-процессы** — запись в базу, сохранение логов, обработка очередей: то, что сложно визуализировать вручную
* **CRUD-операции** — создание, чтение, обновление, удаление данных через API
* **Тестирование производительности** — нагрузочные сценарии, которые невозможно выполнить вручную в нужном масштабе
* **Cross-browser и cross-platform** — проверка совместимости на нескольких конфигурациях параллельно

### Современные области для автоматизации

* **Accessibility (a11y)** — проверки доступности через axe-core или Playwright accessibility snapshot; требования Web Content Accessibility Guidelines (WCAG) применимы автоматически
* **API contract testing** — контрактное тестирование с Pact предотвращает несовместимость сервисов без E2E тестов
* **Visual regression** — автоматическое сравнение скриншотов для design systems и компонентных библиотек
* **PWA (Progressive Web Apps)** — Service Worker, offline-режим, push-уведомления требуют специфических тестов

## Что не стоит автоматизировать

* **Одноразовые проверки** — если тест нужен один раз, ручная проверка быстрее
* **Визуальный и UX-дизайн** (субъективные оценки) — насколько интерфейс «красив» или «удобен», автоматизация не скажет
* **Исследовательское тестирование** — творческий поиск непредвиденных сценариев требует человеческого мышления
* **Нестабильный функционал** — тесты для постоянно меняющегося UI придётся переписывать чаще, чем они будут приносить пользу
* **Не воспроизводимые окружения** — если среду нельзя воспроизвести стабильно, тест будет flaky

## Критерии выбора

Полезный инструмент оценки — матрица: **частота запуска × стоимость ручного прогона × риск пропустить баг**. Чем выше все три параметра — тем выше приоритет автоматизации.

Практическое правило: если тест нужно запускать чаще двух раз в неделю — автоматизируй.

## Источники

* [Какие места в проекте нужно автоматизировать в первую очередь?](https://software-testing.org/automation-testing/kakie-mesta-v-proekte-nuzhno-avtomatizirovat-v-pervuyu-ochered.html)
* [Playwright: Accessibility testing](https://playwright.dev/docs/accessibility-testing)
* [Pact — contract testing](https://docs.pact.io)

### Дополнительные материалы

* [Автоматизировать или нет: спорные кейсы](https://habr.com/ru/post/653721/) — разбор неочевидных ситуаций
* [Не автоматизируйте test cases](https://habr.com/ru/post/652499/) — почему тест-кейсы плохая основа для автоматизации
* [Решаем, что и когда автоматизировать](https://testengineer.ru/reshaem-chto-i-kogda-avtomatizirovat/) — практический подход к приоритизации