Вы наверняка видели такие вакансии: «QA Automation Engineer — 70–120 тыс. долларов, удалённо, Selenium/Playwright». Вы открываете учебник, пишете первую строку driver.get("https://example.com") и чувствуете, что дело пошло. Три месяца спустя вы всё ещё копируете код со Stack Overflow, ваши тесты ломаются через день, а собеседования заканчиваются фразой «мы вам перезвоним». Проблема не в ваших усилиях — а в мифах, которые вы усвоили о том, что такое автоматизация на самом деле. Давайте развенчаем пять самых дорогостоящих.
Миф 1: «Автоматизация — это просто написание скриптов, которые нажимают кнопки»
Что люди думают: QA Automation Engineer записывает действия пользователя, оборачивает их в цикл и запускает. Работа — это синтаксис.
Что на самом деле: Автоматизация — это программная инженерия, применённая к тестированию. Вы создаёте продукт — тестовый фреймворк, — который другие люди будут поддерживать, расширять и которому будут доверять. Это означает контроль версий, код-ревью, паттерны проектирования и CI/CD-пайплайны. На нажатие кнопок приходится, может быть, 10% работы.
Возьмём конкретную задачу: проверить, что форма входа отклоняет неверные учётные данные. Новичок пишет:
from selenium import webdriver
from selenium.webdriver.common.by import By
driver = webdriver.Chrome()
driver.get("https://app.example.com/login")
driver.find_element(By.ID, "username").send_keys("user")
driver.find_element(By.ID, "password").send_keys("wrong")
driver.find_element(By.ID, "submit").click()
assert "Invalid" in driver.page_source
Этот тест проходит один раз. Затем команда меняет ID кнопки, добавляет спиннер загрузки или запускает тест параллельно с тремя другими — и он падает. Практик пишет тот же тест с Page Object, явными ожиданиями и фабрикой тестовых данных:
class LoginPage:
def __init__(self, driver):
self.driver = driver
self.username = (By.ID, "username")
self.password = (By.ID, "password")
self.submit = (By.CSS_SELECTOR, "button[type='submit']")
def login(self, user, pwd):
self.driver.find_element(*self.username).send_keys(user)
self.driver.find_element(*self.password).send_keys(pwd)
self.driver.find_element(*self.submit).click()
Теперь селектор находится в одном месте. Когда UI меняется, вы исправляете одну строку, а не пятьдесят тестов. Вот разница между скриптом и фреймворком.
Миф 2: «Selenium устарел; просто используйте Playwright»
Что люди думают: Playwright новее, значит, Selenium мёртв. Учить Selenium — пустая трата времени.
Что на самом деле: Оба — инструменты, и выбор зависит от контекста. Selenium по-прежнему доминирует в корпоративных средах с устаревшими браузерами, инфраструктурой гридов и большими существующими наборами тестов. Playwright выигрывает в скорости, автоожиданиях и встроенной параллельности — но он поддерживает только Chromium, Firefox и WebKit. Если ваша компания тестирует на IE11 (да, некоторые всё ещё это делают), Playwright не поможет.
Менеджеру по найму всё равно, какой инструмент вы заучили. Ему важно, понимаете ли вы, почему тест нестабилен и как это исправить. Этот навык переносится между инструментами. Изучив сначала Selenium, вы освоите явные ожидания, DOM и кросс-браузерные причуды; после этого Playwright покажется облегчением, а не загадкой.
Миф 3: «API-тесты необязательны, если у вас есть UI-тесты»
Что люди думают: Если UI работает, значит, и бэкенд работает. API-тесты — это дополнительный бонус.
Что на самом деле: UI-тесты медленные, хрупкие и дорогие. Один сквозной UI-тест может занимать 30–60 секунд; API-тест той же логики — миллисекунды. Что важнее, UI-тесты не позволяют изолировать источник сбоя — ошибка во фронтенде, в API или в базе данных?
Рассмотрим процесс оформления заказа. UI-тест кликает по пяти страницам, ждёт спиннеры и проверяет подтверждение заказа. Если он падает, вы отлаживаете его целый час. API-тест отправляет POST /orders с полезной нагрузкой и проверяет ответ за 200 мс. Когда позже падает UI-тест, вы уже знаете, что API в порядке — ошибка во фронтенде.
Пирамида всё ещё работает: много юнит-тестов, солидный слой API-тестов и тонкий слой UI-тестов для критических путей. Пропуская API-тесты, вы платите за нестабильность.
Миф 4: «CI/CD — это чья-то чужая работа»
Что люди думают: Вы пишете тесты; DevOps подключает их к пайплайну.
Что на самом деле: Тест, который не запускается на каждый коммит, — это тест, который гниёт. От инженеров по автоматизации ожидают ответственности за интеграцию в пайплайн — как минимум за стадию тестирования. Это значит, что нужно уметь запускать тесты в headless-режиме, распараллеливать их и публиковать отчёты. Подробнее — в статье «QA-инженер».
Вот минимальный workflow GitHub Actions, который запускает тесты Playwright при пуше:
name: Playwright Tests
on: [push]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20
- run: npm ci
- run: npx playwright install --with-deps
- run: npx playwright test
Без этого ваши тесты живут на вашем ноутбуке и умирают там же. С этим каждый пул-реквест получает сигнал пройден/не пройден — и вы становитесь человеком, который делает релизы безопаснее.
Миф 5: «Нагрузочное тестирование — это отдельная специализация»
Что люди думают: Нагрузочное тестирование — для инженеров по производительности с JMeter и выделенной средой.
Что на самом деле: Базовое нагрузочное тестирование входит в инструментарий инженера по автоматизации. Не нужно с первого дня моделировать 10 000 одновременных пользователей, но вы должны уметь запускать дымовой нагрузочный тест с k6 или JMeter, чтобы ловить регрессии.
Простой скрипт k6:
import http from 'k6/http';
import { check } from 'k6';
export let options = { vus: 10, duration: '30s' };
export default function () {
let res = http.get('https://api.example.com/health');
check(res, { 'status is 200': (r) => r.status === 200 });
}
Запустите это после деплоя, и вы узнаете, если API вдруг стал отвечать за 2 секунды вместо 200 мс. Это не глубокое проектирование производительности — это базовая гигиена, и её всё чаще ожидают от QA Automation Engineer.
Где люди на самом деле ошибаются (и сколько это стоит)
У всех мифов выше одна корневая причина: отношение к автоматизации как к набору инструментов, а не как к системе. Цена измерима. Новичок, который пропускает Page Objects, тратит примерно 30–40% времени на исправление сломанных селекторов. Тот, кто игнорирует API-тесты, ждёт обратной связи минутами вместо секунд. Тот, кто никогда не касается CI/CD, выпускает код, который работает локально и падает в продакшене.
Решение — не очередной учебник. Это осознанная практика на реалистичном проекте — с код-ревью. Именно здесь самообучение упирается в стену: вы можете написать тест, но не можете определить, хорош ли он. Нужен кто-то, кто укажет, что ваше ожидание неявное, селектор хрупкий или тестовые данные протекают между запусками.
Структурированные курсы закрывают этот пробел. Хороший курс проведёт вас через создание фреймворка с нуля — Page Object, фабрика тестовых данных, параллельное выполнение, интеграция с CI — и даст обратную связь по вашим решениям. Курс QA Automation Engineer на asibiont.com делает именно это: текстовые уроки, адаптированные к вашему уровню, охватывающие Selenium, Playwright, Cypress, API-тестирование с REST Assured и Postman, Appium, CI/CD и нагрузочное тестирование с k6 и JMeter. Финальный проект — это полный пайплайн, а не игрушечный скрипт.
Но курс — лишь один путь. Самообучение работает, если у вас есть дисциплина и наставник; буткемпы работают, если вам нужны дедлайны. Компромисс — время против обратной связи: самообучение дёшево, но медленно исправляет ошибки; курсы стоят денег, но сжимают кривую обучения.
Кому подходит этот путь — а кому нет
Автоматизация подходит людям, которым нравится отладка, которые терпимы к неопределённости и мыслят системно. Она не подходит тем, кто хочет чисто творческую роль или ненавидит читать логи. Если вы когда-нибудь тратили час на поиск бага и чувствовали удовлетворение, когда находили его, вы, скорее всего, преуспеете. Если это звучит как пытка, рассмотрите ручное тестирование или продакт-менеджмент.
Эта область не исчезнет. По мере того как ИИ генерирует всё больше кода, потребность в надёжных автоматических проверках растёт. Но планка повышается: знать Selenium недостаточно; нужно проектировать тестовые стратегии, интегрироваться с пайплайнами и интерпретировать результаты. Начните с одного инструмента, одного API-теста, одной CI-задачи — затем расширяйтесь. Мифы выше — главная причина, по которой новички застревают; избегайте их, и вы будете впереди большинства соискателей.
Если вы хотите структурированный путь, который заставит вас построить настоящий фреймворк и получить по нему обратную связь, курс QA Automation Engineer — практичная отправная точка: подробности и запись на странице курса.