Автоматизация тестирования: что это, где применяется и как освоить

Главное, что стоит понять до первой строки кода: автотест не ищет ошибки, а подтверждает, что знакомый сценарий работает как вчера. Новую ошибку по-прежнему находит человек, а скрипт берёт на себя то, что человек устаёт проверять в десятый раз. Поэтому навык начинается не с выбора инструмента, а с вопроса, какая именно проверка повторяется достаточно часто, чтобы её стоило записать.

Кому пригодится навык и где без него можно обойтись

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

Разработчику навык знаком по модульным тестам, но граница проходит дальше: полезно уметь проверить не только функцию, но и то, как её результат доходит до API и интерфейса. Тест, который воспроизводит исправленную ошибку, остаётся в репозитории и не даёт ей вернуться.

DevOps-инженер редко пишет сами проверки, зато отвечает за то, чтобы они запускались на каждом изменении, в чистом окружении и с понятным отчётом. Ему нужно понимать, почему тест падает на сервере сборки и проходит у автора, и какие проверки блокируют выкладку, а какие только предупреждают.

Аналитику автотест нужен, когда он сам отвечает за результат: выгрузку, расчёт в отчёте, витрину данных. Короткий скрипт на pytest, который после каждого обновления сверяет итоговые суммы с эталонным файлом, заменяет ежемесячную ручную сверку.

Обойтись без автоматизации разумно там, где интерфейс ещё меняется каждую неделю, проверка нужна один раз или результат оценивает глаз: удобство, внешний вид, понятность текста. Код, который придётся переписывать после каждого редизайна, обходится дороже ручной проверки.

Учебный пример: регресс оформления заказа

Ситуация учебная. Тестировщица небольшого интернет-магазина перед каждым выпуском вручную оформляет заказ с промокодом: входит под тестовым пользователем, кладёт товар в корзину, вводит код, проверяет пересчёт суммы и доходит до страницы оплаты. Выпуски идут дважды в неделю, и однажды сломанный промокод дошёл до покупателей, потому что именно этот шаг в спешке пропустили.

Она решает автоматизировать проверку в два слоя. Сначала расчёт скидки: тест на pytest отправляет запрос к API корзины с тремя промокодами — действующим, просроченным и чужим — и сверяет итоговую сумму. Такой тест выполняется за секунды и не зависит от вёрстки. Затем один сквозной сценарий через браузер на Selenium: вход, корзина, ввод кода, появление новой суммы на экране. Здесь проверяется то, чего не видно через API, — что интерфейс действительно показывает пересчитанную цену.

Оба теста попадают в репозиторий, а разработчик добавляет их запуск в CI. Результат не в том, что тестировщица перестала проверять заказы руками, а в том, что сломанный промокод теперь остановит сборку до выкладки, даже если в этот день проверять вручную некому.

Почему старые инструкции про chromedriver больше не нужны

На первом же браузерном тесте многие новички спотыкаются на драйвере. Во множестве учебных материалов, написанных несколько лет назад, первый шаг выглядит так: узнать точную версию Chrome, скачать chromedriver той же версии, прописать путь к нему в коде или в переменной PATH. Через месяц браузер обновляется сам, версии расходятся, и тест падает с ошибкой о несовместимости, хотя в коде ничего не менялось.

Этот шаг давно можно пропустить. Согласно документации Selenium Manager, начиная с Selenium 4.6 в каждый выпуск библиотеки встроен инструмент, который сам определяет версию установленного браузера, находит подходящий драйвер, скачивает его и кеширует в папке ~/.cache/selenium. Он включается, только если драйвер не указан вручную, поэтому старый путь в коде или в PATH продолжит работать — и продолжит ломаться при обновлениях. Там же сказано, что с Selenium 4.11 инструмент умеет скачать и сам браузер, если его нет в системе: для Chrome берётся сборка Chrome for Testing, а с версий 4.12 и 4.14 так же поддерживаются Firefox и Edge.

Практический вывод для того, кто учится: если инструкция начинается со скачивания chromedriver, она устарела. Современный минимальный тест на Selenium — это webdriver.Chrome() без путей и ручных загрузок. Для сервера сборки есть оговорка из той же документации: без доступа в интернет скачивание не сработает, для таких окружений предусмотрен офлайн-режим и настройка прокси, а версии драйвера и браузера лучше закрепить заранее. Playwright решает задачу похожим образом: браузеры для него устанавливаются одной командой playwright install и привязаны к версии библиотеки.

В каком порядке осваивать навык

Порядок шагов важен потому, что каждый следующий опирается на предыдущий. Без понимания, что проверять, код превращается в запись случайных кликов; без языка нельзя разобраться в падении; без Git и CI тесты остаются на одном ноутбуке и не защищают команду. Для человека, который применяет навык в своей основной работе, разумна такая последовательность:

1. Основы тест-дизайна: ожидаемый результат, граничные значения, позитивные и негативные сценарии. Если вы тестировщик, этот шаг у вас уже есть.
2. Один язык до уровня функций, классов, работы со списками и словарями. Python удобен для аналитиков и тестировщиков, JavaScript — для фронтенд-разработчиков.
3. Тестовый фреймворк: pytest или Jest, утверждения, параметризация, фикстуры для подготовки данных.
4. Проверки API: HTTP-методы, коды ответов, JSON, библиотека requests или встроенные средства Playwright.
5. Браузерные тесты на Selenium или Playwright: локаторы, ожидание элементов, шаблон Page Object.
6. Git и запуск тестов в CI — GitHub Actions или GitLab CI — с отчётом, который видит вся команда.

Первые три шага можно пройти бесплатно: написать функцию расчёта скидки и тесты к ней, а потом перейти к API и браузеру.

Упражнения и частые ошибки

Хорошее первое упражнение — автоматизировать сценарий, который вы уже знаете руками: вход в учебное приложение, поиск, заполнение формы. Сравнивайте не только «прошёл — не прошёл», но и то, упадёт ли тест, если вы намеренно сломаете ожидаемый результат. Тест, который не может упасть, ничего не проверяет.

Типичные ошибки новичков похожи друг на друга. В тест записывают все шаги подряд вместо одной проверяемой мысли, и при падении непонятно, что сломалось. Используют жёсткие паузы вместо ожидания условия. Берут хрупкие локаторы вроде длинного XPath от корня страницы, который ломается при любой правке вёрстки. Проверяют через браузер то, что быстрее проверить через API. Оставляют тестовые данные после прогона, и второй запуск ведёт себя иначе.

Проверить результат можно простым вопросом: поймёт ли коллега по отчёту, что именно сломалось, не открывая код? Если да, тест готов к общему репозиторию.

Тем, кто уже тестирует руками и хочет системно перейти к коду, подходит курс Нетологии «Автоматизация тестирования на Python/Java»: по обзору программа длится девять месяцев, рассчитана на людей с базой ручного тестирования и не повторяет её с нуля, а в практике — Git, SQL, Selenium и Selenide, pytest, Docker, GitHub Actions, тесты API и интерфейса.

Что проверить в программе обучения

Для того, кто не собирается становиться штатным автоматизатором, программа не обязательно должна быть длинной. Важнее, чтобы в ней были упражнения на вашем языке, проверка кода наставником и хотя бы один проект, где тесты запускаются в CI, а не только локально.

Если основной язык в вашей команде — Java, посмотрите короткий курс Skillbox «Автоматизированное тестирование на Java». По обзору он длится около двух месяцев и адресован тестировщикам с опытом ручной проверки: основы Java и ООП, Selenium IDE и WebDriver, CSS- и XPath-локаторы, JUnit, Maven, Git и Jenkins, два проекта в портфолио. Перед покупкой обзор предлагает убедиться, что вы уже знаете тест-дизайн, клиент-серверную архитектуру и основы HTML.

Уточните у школы, на какой версии Selenium построены задания. Если в материалах ещё учат вручную скачивать драйвер, остальная программа тоже может отставать от актуальных инструментов.

Как навык влияет на доход

Для тестировщика автоматизация — главный переход в более высокую зарплатную группу. «Хабр Карьера» в отчёте о зарплатах тестировщиков за первое полугодие 2026 года приводит фактические зарплаты по анкетам своего калькулятора по всей России: общая медиана специалистов по ручному тестированию — 133 тысячи рублей в месяц, по автоматизации тестирования — 230 тысяч. Это сравнение двух специализаций со всеми уровнями опыта вместе, а не надбавка за один навык: разница складывается из программирования, CI и ответственности за тестовый код.

Для разработчика, DevOps-инженера и аналитика навык редко становится отдельной строкой в зарплате. Он входит в требования вакансии или расширяет круг задач, которые можно взять на себя: покрыть тестами свой сервис, настроить проверки в конвейере, поручить скрипту сверку отчёта. Сравнивая цифры из разных источников, смотрите медиану, уровень, регион и то, указана ли сумма до вычета налога или на руки.

Тем, кто хочет освоить Python и тестирование вместе в гибком темпе, подойдёт онлайн-курс Eduson Academy «Автотестировщик на Python»: по обзору в нём основы Python и ООП, pytest с параметризацией и фикстурами, Selenium, Playwright и отчёты Allure, тесты API, CI в Jenkins и GitLab CI и дипломный проект с проверкой кода. Опыт программирования для старта желателен, но не обязателен.

С какими профессиями связан навык

Автоматизация тестирования — основа профессии инженера по автоматизации тестирования, о которой на сайте есть отдельная статья. Здесь навык рассмотрен как инструмент для тех, у кого основная работа другая. Он пересекается с тестированием ПО, разработкой на Python и JavaScript и DevOps-практиками.

Сравнить школы, где учат и ручному тестированию, и автоматизации на разных языках, поможет рейтинг онлайн-школ по тестированию и QA. Прежде чем выбирать, напишите один тест на pytest для функции из своей работы и запустите его через GitHub Actions: если вам интересно разбираться, почему он упал, навык стоит развивать дальше.