Manual → automation: как перейти и не сломаться
Самый частый совет тем, кто хочет из ручного тестирования в автоматизацию: «выучи Python и Selenium». И это самый бесполезный совет. Синтаксис языка — не то, обо что спотыкается переход: циклы и функции люди осваивают за пару недель. Ломается всё в другом месте.
За годы я видел десятки таких переходов — свой в том числе — и провалы у всех похожие.
Обо что реально ломается переход
Автоматизируют всё подряд. Раз научился писать тесты — кажется, надо покрыть автотестами весь регресс. Через полгода — двести хрупких тестов, которым никто не верит, и красный прогон, который лечат кнопкой retry. Автоматизация — не «переписать ручные кейсы в код», а осознанный выбор: что стоит автоматизировать (стабильное, повторяемое, дорогое в ручном прогоне), а что нет.
Думают, что автоматизация — это «писать тесты». На деле написать тест — меньшая часть. Основная работа — поддерживать: чинить флак, разбирать красный CI, обновлять локаторы, держать инфраструктуру. Тест пишется один раз, а живёт годами. Кто приходит «писать тесты», а не «жить с тестами», выгорает на поддержке.
Бросают ручное мышление. Самое обидное. Человек так рвётся стать «автоматизатором», что стыдится ручного прошлого и обесценивает его. А это ровно его преимущество — об этом ниже.
Маршрут, который работает
Язык — да, нужен. Но не «40 часов теории перед первым тестом». Бери минимум и сразу на реальных задачах: переменные, функции, списки/словари, классы по мере надобности. Остальное подтянется на практике.
Начинай не с UI, а с API-тестов. Контринтуитивно — кажется, что автоматизация про клики в браузере. Но API-тесты стабильнее (нет вёрстки, которая едет), дают быстрый фидбек, учат структуре запросов и ответов и не тонут во флаке ожиданий. Освоил API — половина автоматизации в кармане, и без боли с локаторами.
Потом UI — сразу с архитектурой, а не «всё в одном тесте» (про это был вчерашний пост про Page Object). Локаторы в одном месте, setup через API, тест читается как сценарий.
Git, командная строка, CI — не опционально. Автотест, который не запускается в CI, — это хобби. Научись читать пайплайн и разбирать, почему прогон красный.
Читай код своей команды раньше, чем пишешь с нуля. Живой фреймворк проекта научит быстрее любого курса.
Почему manual-прошлое — преимущество, а не балласт
Главное, что стоит услышать. Человек из ручного тестирования приходит в автоматизацию с тем, чего часто нет у пришедших из разработки.
Ты знаешь, ЧТО автоматизировать. Какие сценарии критичны, где реальные риски, что отвалится и будет больно, а что косметика. «Что тестировать» — отдельный навык, и он ценнее умения писать код. Код, покрывающий не то, — просто дорогой способ получить ложную зелёнку.
Ты — оракул. Понимаешь, что баг, а что ожидаемое поведение. Автотест сам по себе не знает, «правильно» ли на экране; это знаешь ты и зашиваешь в проверку.
Ты умеешь описывать шаги воспроизведения — а это почти готовый сценарий теста. Хороший баг-репорт и хороший автотест устроены одинаково: предусловие, действие, ожидание.
Исследовательское тестирование никуда не девается. Автотесты не находят новых багов — они стерегут уже известное. Новое находит человек руками и головой. Поэтому «полностью уйти в автоматизацию и забыть ручное» — ошибка: ты выбрасываешь то, что находит настоящие проблемы.
Антипаттерны перехода
- «Перепишем весь регресс в автотесты за квартал» — утопия, на выходе красный сьют, которому не верят.
- Автоматизировать нестабильную, часто меняющуюся фичу — тесты устаревают быстрее, чем пишутся.
- Гнаться за числом тестов или «100% покрытием» как метрикой успеха. Метрика — пойманные баги и доверие к прогону, не количество.
- Бросить ручное тестирование совсем.
Коротко — что забрать с собой
- Язык — минимум и сразу на задачах, не 40 часов теории вперёд.
- Начинай с API-тестов; UI — потом и сразу с архитектурой.
- Git / CLI / CI обязательны: тест не в CI — это хобби.
- Автоматизируй стабильное и повторяемое, не «всё подряд».
- Основная работа — поддержка, а не написание. Готовься жить с тестами.
- Manual-мышление (что тестировать, оракул, репро-шаги, исследование) — твоё преимущество, не выбрасывай.
Почитать: Martin Fowler — The Practical Test Pyramid · Playwright — API testing · Automation in Testing (R. Bradshaw)