Автоматизация тестирования — это не «замена ручек роботами», а…

Автоматизация тестирования — это не «замена ручек роботами», а инвестиция в скорость и повторяемость. Рука проверит 10 сценариев за час, а авто — 1000 за 5 минут, но только если они стабильны и не меняются каждый день.

Вот полный разбор для QA:

---

1. Что именно автоматизируем (пирамида)

· Модульные тесты (Unit) — пишут разработчики (JUnit, PyTest). Проверяют функции изолированно. Самый дешёвый и быстрый слой.
· API-тесты — ваш главный фокус (Postman/Newman, REST Assured, SoapUI). Проверяют логику без UI. Стабильны и быстры.
· UI-тесты — через браузер (Selenium, Playwright, Cypress). Самые дорогие и хрупкие (из-за изменения селекторов). Должны быть только на критический путь.

---

2. Типичный стек (чем пишут)

· Языки: Python (Pytest), Java (TestNG/JUnit), JavaScript/TypeScript (Jest, Mocha).
· Фреймворки: Selenium WebDriver, Playwright, Cypress, Appium (мобилки).
· API: REST Assured (Java), Requests (Python), Postman + Newman.
· Отчёты: Allure, ExtentReports.
· CI/CD: Jenkins, GitLab CI, GitHub Actions (запуск автотестов после каждого коммита).

---

3. Из чего состоит хороший автотест (структура)

По паттерну AAA (Arrange-Act-Assert):

· Arrange — подготовка: создать юзера, заполнить БД тестовыми данными.
· Act — действие: отправить запрос / кликнуть кнопку.
· Assert — проверка: статус 200, в БД появилась запись, элемент виден.

Обязательно:

· @BeforeEach / setup — очистка состояния перед каждым тестом (чтобы тесты не влияли друг на друга).
· Уникальные тестовые данные (рандомизация), чтобы не было конфликтов.

---

4. Когда запускаем (стратегия)

· Smoke-авто — на каждый PR (быстро, 5–10 мин) — упало → не сливаем в мастер.
· Регрессия — ночью или перед релизом (тысячи тестов, 1–2 часа).
· По расписанию — например, каждое утро на свежее окружение.

---

5. Главные сложности (с чем боретесь)

· Flaky-тесты — сегодня зелёный, завтра красный без изменений кода (киллер доверия). Причины: тайминги, асинхронность, состояние БД.
· Поддержка — меняется селектор → чините 50 тестов. Решение: Page Object Model (выносите локаторы в отдельные классы/файлы).
· Тестовые данные — если БД общая, тесты мешают друг другу. Решение: Docker-контейнеры с чистой БД на каждый прогон.
· Окружение — тесты падают из-за того, что сервер не поднялся, а не из-за бага.

---

6. Page Object Model (ваша архитектура)

Главный паттерн в UI-авто:

· Page — класс с локаторами и методами (LoginPage.inputLogin()).
· Test — только вызовы методов и ассерты (без findElement в тестах!).

Пример (Python + Selenium):

```python
class LoginPage:
def login(self, user, pwd):
self.enter_login(user)
self.enter_pwd(pwd)
self.click_submit()

def test_login_ok():
main_page = LoginPage(driver).login("valid", "valid")
assert main_page.get_username() == "John"
```

---

7. Когда НЕ надо автоматизировать

· Фича меняется каждую неделю (переписывать дороже).
· Нужно проверить UI-визуал (шрифты, отступы) — это делают глазами.
· Разовый тест (например, миграция данных).
· Авто тест дольше писать, чем проверять руками 1 раз.

---

8. Градация навыков в авто

· Junior AQA — пишет тесты по готовому фреймворку, правит локаторы.
· Middle — настраивает фреймворк с нуля, пишет хелперы, интегрирует с CI.
· Senior — строит тестовую инфраструктуру (Docker + виртуализация), внедряет BDD (Cucumber), учит команду.

---

9. Главная метрика

Не % покрытия кода, а время выполнения регрессии (было 2 дня ручками → стало 20 минут авто).