> 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/luchshie-praktiki-avtomatizacii.md).

# Лучшие практики

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

## 7 характеристик хорошо написанного теста

* **Полностью автоматизирован**: тест не требует ручного вмешательства ни на каком этапе
* **Повторяем**: тест не ломается, если приложение не изменилось. Все данные — уникальны на каждый прогон
* **Заканчивается валидацией**: последнее действие теста — проверка, а не побочный эффект
* **Стабилен в CI/CD**: тест, который регулярно ломается без изменений в коде, — это хуже, чем его отсутствие
* **Легко читать**: любой член команды понимает, что тест проверяет, за 30 секунд
* **Требует минимальной поддержки**: правильно абстрагирован (Page Object, Fixture), не ломается при каждом UI-изменении
* **Работает параллельно**: не зависит от глобального состояния и порядка запуска

## Десять заповедей автоматизации

### 1. Не автоматизируй только «по тест-кейсам»

Тест-кейсы написаны для людей. Автоматизированный тест — это программа. Прямая конвертация manual → auto без переосмысления приводит к медленным, хрупким сценариям. Автоматизируй то, что компьютер делает лучше человека.

### 2. Обращайся с разработкой автоматизации как с разработкой ПО

Дизайн, code review, версионирование в Git, исправление багов в тестовом коде — всё это обязательно. Тест-суит без поддержки умирает за несколько месяцев.

### 3. Следуй стандартам и идиомам языка

Каждый язык и фреймворк имеют устоявшиеся паттерны. Для Playwright — async/await + Page Objects. Для pytest — fixtures + parametrize. Следование им снижает порог входа для новых членов команды.

### 4. Планируй поддержку и обслуживание

В тестовом коде будут баги. Приложение меняется — тесты нужно обновлять. Выделяй время на поддержку так же, как на написание новых тестов.

### 5. Не делай тесты зависимыми друг от друга

Тест, зависящий от результата другого теста, нельзя запустить изолированно, нельзя параллелизировать. Каждый тест — полностью самодостаточная единица.

### 6. Внедряй грамотное логирование и отчёты

Когда тест упал в CI, у тебя должно быть достаточно информации для диагностики без перезапуска: скриншоты, видео, трейс, логи сети. Playwright HTML Report и Allure — стандартные решения.

### 7. Влияй на тестируемость продукта

Разработчики не всегда знают, что нужно для тестирования. QA должен запрашивать `data-testid` атрибуты, стабильные локаторы, API для управления состоянием в тестах (test API).

### 8. Не попадайся в ловушку невозвратных затрат

Если выбранный подход не работает — лучше начать заново, чем вкладывать ещё больше ресурсов в неправильное направление. Эмоциональная привязанность к написанному коду — враг качества.

### 9. Опасайся чрезмерной сложности

Инструмент или фреймворк сложнее задачи — плохой выбор. Если набор тестов требует полдня онбординга — что-то пошло не так.

### 10. Не делай тестовые данные зависимыми от временных условий

Дата «январь» в тесте, написанном в январе, сломается в феврале. Генерируй данные динамически относительно текущей даты/времени.

## Нельзя

* **Автоматизировать все ручные тесты**: ручные тесты и автоматизированные — разные инструменты с разными целями
* **Делать автоматизацию задачей одного человека**: когда он уйдёт, никто не разберётся в суите
* **Автоматизировать ради автоматизации**: каждый тест должен давать конкретную ценность
* **Думать только в категориях «прошёл/упал»**: выясняй ПОЧЕМУ тест упал
* **Забывать тестировать собственные тесты**: перед release убедись, что тест действительно падает при баге

## Нужно

* **Дробить тесты на независимые сценарии**: короткие, конкретные тест-кейсы легче диагностировать
* **Доносить результаты до всей команды**: разные роли нуждаются в разном уровне детализации
* **Начинать с простого и наращивать**: не проектируй идеальный фреймворк с нуля — начни с малого, расширяй по необходимости
* **Регулярно обновлять тест-набор**: изменился код — обновились тесты. Без исключений

## Источники

* [7 характеристик хороших тестов](https://habr.com/ru/post/599507/)
* [Еще десять заповедей автоматизации](https://software-testing.ru/library/testing/testing-automation/3492-ten-more-commandments-of-automation)
* [Как можно и нельзя автоматизировать](https://software-testing.ru/library/testing/testing-automation/2940-starting-up-test-automation)

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

* [Паттерны проектирования в автоматизации тестирования](https://habr.com/ru/company/jugru/blog/338836/) — Page Object, Builder, Factory с примерами
* [21 распространённая ошибка в автоматизированном тестировании](https://habr.com/ru/post/662211/)
* [Чистая архитектура в автотестах](https://www.youtube.com/watch?v=ZIg-yFJx2A8)
* [Пожалуй, лучшая архитектура для UI тестов](https://habr.com/ru/company/protei/blog/523802/)
* [SOLID и другие принципы ООП в контексте автоматизации](https://www.youtube.com/watch?v=xG6NOxiOLhU)