AQA на Python: как войти в автоматизированное тестирование в 2026
Человек открывает HH или LinkedIn, вбивает «AQA Python джун» и через пять минут чешет в затылке. Одна вакансия требует Selenium, pytest и Page Object. Вторая — Playwright, Postman и опыт с Docker. Третья почти не отличается от описания бэкенд-разработчика: «спроектировать API, знание PostgreSQL, асинхронность, очереди». А четвёртая — внезапно — про ручное тестирование с парой строк «приветствуется автоматизация».
Это не баг рынка, это его реальность. Под одним и тем же заголовком «AQA Python» компании понимают разные вещи. И прежде чем выбирать курс или собирать резюме, имеет смысл разобраться, какая именно работа вам подходит — и под какие именно вакансии вы потом будете откликаться.
Ниже — карта направления. Чем AQA отличается от ручного тестировщика и от Python-разработчика. Что реально просят на джуниорских вакансиях в 2026 году. Какие зарплаты ждать на старте и через два-три года. Какие карьерные ветки открываются после AQA. И с чего начинать учёбу, чтобы не утонуть в десятке инструментов.
Если ищете цельный маршрут от нуля до джуниора — основы Python, pytest, Selenium, API-тестирование, базы данных, плюс блок про трудоустройство — это программа «Автоматизатор тестирования на Python» на Хекслете.
Три лица тестирования: ручной QA, AQA, SDET
Самая частая путаница на старте — люди не различают эти три роли и думают, что между ними плавный переход. Перехода нет. Это три разные профессии, у которых разные задачи, разный код и разная зарплатная вилка.
Роль | Что делает | Сколько кода | Что важно |
|---|---|---|---|
Ручной QA / инженер по тестированию | Пишет сценарии, прогоняет регресс руками, исследует продукт, оформляет баги | Мало или нет. Иногда SQL и команды в терминале | Мышление тестировщика, внимание к деталям, умение задавать вопросы продукту |
AQA / автоматизатор на Python | Пишет автотесты на pytest, проектирует сценарии, разбирает падения в CI, иногда тестирует руками | Много. Pytest, фикстуры, Page Object, HTTP-клиенты, иногда Docker | Мышление тестировщика плюс инженерная дисциплина |
SDET / Senior Test Engineer | Проектирует тестовые фреймворки, ускоряет работу всей команды, отвечает за инфраструктуру тестов | На уровне разработки. Архитектура, инфра, нагрузка | Опыт разработки плюс понимание процессов QA |
Джуниорские вакансии «AQA Python» в 95% случаев — это вторая строка с примесью первой. Работодатель ждёт человека, который умеет думать как тестировщик и при этом писать код. Не разработчика «с уклоном в тесты». Не оператора кнопки «прогнать сценарий».
SDET — это не точка входа. Это позиция миддла-сеньора, в которую часто приходят либо опытные AQA через 3–4 года, либо разработчики, которым понравилось проектировать тестовую инфраструктуру.
Чем AQA НЕ занимается
Сразу снимем популярные ожидания, с которыми люди приходят в профессию — и потом разочаровываются.
Это НЕ «половина зарплаты за половину разработки». Ответственность за качество релиза по напряжению не ниже, чем у разработчика. Просто другая. Когда падает прод, разработчик чинит — а AQA объясняет, почему его автотесты не поймали проблему заранее.
Это НЕ записать клики в рекордере и нажать «сохранить». Такие тесты разваливаются за месяц. Современный AQA пишет код, который потом сам же читает и поддерживает.
Это НЕ роль приоритизации. Вы не решаете за продукт-менеджера, какие баги важнее. Вы их находите, описываете риски и эскалируете решение тем, у кого есть полномочия.
Если вам не заходит логика «попробовать сломать продукт всеми возможными способами и аккуратно описать воспроизведение» — возможно, вам ближе чистая разработка или продуктовая аналитика, а не QA.
Как выглядит рабочий день автоматизатора
Чтобы не было иллюзий, разложу типичный день AQA-джуниора в продуктовой компании. Не «идеальный по учебнику», а такой, какой бывает в реальности.
Время | Что происходит |
|---|---|
10:00–10:30 | Дейли со своей командой. Обсуждаете, что вошло в релиз, какие риски, что автоматизируем в первую очередь |
10:30–11:30 | Разбор ночных падений в CI. Половина — реальные баги продукта, половина — флэйки, тесты которые лежат сами по себе |
11:30–13:00 | Пишете новый автотест на функциональность, которую вчера выкатили в стейджинг. Pytest, фикстуры, проверки |
13:00–14:00 | Обед или код-ревью у коллеги — читаете чужие тесты как спецификацию поведения |
14:00–15:00 | Воспроизводите баг, который зарепортил саппорт. Иногда быстрее руками, чем через автотест |
15:00–17:00 | Дописываете тесты, чините упавший локатор в UI-тесте, обсуждаете с разработчиком, почему API вернул не тот код |
17:00–18:00 | Документация. Как запустить, какие переменные окружения нужны, что отмечено как smoke |
Главное, что бросается в глаза в реальной работе AQA — много общения. С разработчиками, с продуктом, с поддержкой. «Тихий код в углу» — это не AQA. Если вы шли в тестирование за тем, чтобы поменьше говорить с людьми — присмотритесь к чистой разработке, там этого действительно меньше.
AQA на Python vs Python-разработчик: где проходит граница
Один из самых частых вопросов от новичков: «А может, мне сразу в Python-разработку, раз я всё равно учу Python?» Имеет смысл, если вы уже понимаете разницу. Если нет — она ниже.
Критерий | AQA на Python | Python-разработчик (бэкенд) |
|---|---|---|
Главный результат работы | Уверенность команды в релизе, стабильный регресс | Новая функциональность в продакшене |
Какой код пишете | Тесты, фикстуры, утилиты, тестовые библиотеки | Сервисы, доменная логика, API |
Архитектурные задачи | Тестовая модель, слои абстракций UI/API | Микросервисы, базы данных, очереди |
Работа с HTTP | Проверка статусов, контрактов, негативные сценарии | Проектирование API, авторизация, нагрузка |
Что читают на ревью | Тесты как спецификацию поведения | Продакшен-код |
Кто страдает при падении в проде | «Почему не поймали раньше?» | «Почему сломали?» |
Переход AQA → разработчик возможен и довольно распространён — но это смена фокуса, и обычно нужно догнать доменную часть разработки. «Я уже умею pytest» — не аргумент. Pytest умеют все разработчики, кому довелось писать тесты.
Стек джуниора AQA на Python в 2026
Что реально просят на вакансиях. Разделил на три категории, по убыванию обязательности.
Критично — без этого не возьмут
Область | Минимальный уровень |
|---|---|
Python | Синтаксис, функции, модули, исключения, виртуальное окружение, ООП на уровне понимания классов |
pytest | Тесты, фикстуры, параметризация, маркеры, conftest, scope фикстур |
HTTP | Методы, заголовки, JSON, коды ответов, аутентификация |
Git | Ветки, pull request, осмысленные коммиты, базовое разрешение конфликтов |
Английский | Уровень pre-intermediate. Читать документацию, понимать тикеты |
Очень желательно — будут спрашивать на собеседовании
Область | Что нужно знать |
|---|---|
Selenium или Playwright | Локаторы, явные ожидания, Page Object, изоляция тестов |
SQL | SELECT, JOIN, WHERE, базовые агрегации. Проверка состояния БД после действий |
CI/CD | Запуск тестов на push в GitHub Actions или GitLab CI, артефакты, скриншоты при падении |
requests или httpx | Отправка запросов, проверка ответа, работа с сессиями |
Docker (базово) | Запустить контейнер, прочитать docker-compose.yml, понять зачем это в тестах |
Бонус — выделяет среди других кандидатов
Область | Где пригодится |
|---|---|
Allure или другой отчётный движок | В компаниях, где результаты тестов показывают менеджерам |
Performance-тестирование (Locust, JMeter) | Когда у команды нет отдельного перфоманс-инженера |
Mock-серверы (WireMock, mockoon) | Когда продукт зависит от внешних сервисов |
Опыт работы с Kubernetes | В крупных компаниях с микросервисами |
Базовая ИИ-грамотность | Cursor, Copilot и AI-агенты в 2026-м уже не редкость в QA-командах |
Главный лайфхак при чтении вакансий: смотрите не на список технологий, а на описание задач. Если в задачах «тестировать API и UI, поддерживать регресс, разбираться с флэйками» — это нормальная вакансия для AQA. Если «проектировать тестовую инфраструктуру для всех команд» — это уже не джун, даже если в заголовке написано «джуниор».
Пирамида тестов и где автоматизация реально окупается
Классическая пирамида тестов выглядит так: внизу много дешёвых юнит-тестов, в середине — интеграционные и API, наверху — узкий слой UI/E2E. На практике джуну AQA полезно понимать, где его время и нервы окупаются лучше всего.
Слой | Кто чаще пишет | Окупаемость для AQA |
|---|---|---|
Юнит-тесты | Разработчик | AQA читает, иногда дополняет. Писать в одиночку — редкость |
API-тесты, интеграция | AQA — основной автор | Высокая. Быстрые, стабильные, ловят большинство проблем |
UI / E2E | AQA | Средняя. Дорогие, флэйковые, но без них не покрыть пользовательские сценарии |
Нагрузочные | Performance-инженер или AQA | Точечная. Только если задача актуальна для проекта |
Практический вывод. Джуниор, который умеет писать стабильные API-тесты и понимает, когда они полезнее UI-тестов — обычно нанимается быстрее, чем тот, кто знает Selenium наизусть, но не понимает, зачем вообще тестировать API.
Сколько платят: зарплатная карта 2026
Данные собирал по агрегаторам и опросам сообществ в первом квартале 2026 года. Диапазоны — на руки, до налогов. В крупных городах верх вилки, в регионах нижняя половина.
Уровень | Опыт | Москва / Питер | Регионы | Зарубежные компании (удалёнка) |
|---|---|---|---|---|
Junior | 0–1 год | 80–140 тыс. ₽ | 50–90 тыс. ₽ | от $1500 |
Middle | 1–3 года | 140–240 тыс. ₽ | 100–160 тыс. ₽ | $2500–4500 |
Senior | 3–5 лет | 240–380 тыс. ₽ | 180–280 тыс. ₽ | $4500–7000 |
SDET / Lead | 5+ лет | 320–500 тыс. ₽ | 250–380 тыс. ₽ | $6000–10000 |
Важные оговорки. Цифры по зарубежным компаниям — для российских разработчиков на удалёнке через специальные схемы трудоустройства, не для релоцировавшихся. Внутри одной грейдовой категории разрыв в 1.5–2 раза — нормальная история, зависит от компании. Финтех платит больше геймдева. Продуктовые компании платят больше аутсорса.
Самое заметное за последние два года: рынок AQA постепенно повторяет траекторию разработчиков. Джунов берут с трудом и за разумные деньги, на сеньоров охотятся и предлагают вилки, которые ещё в 2023-м казались нереальными.
План учёбы: с чего начать, чтобы не утонуть
Самая частая ошибка — учить пять инструментов параллельно, потому что «всё пригодится». Не пригодится. Нужно идти по порядку.
Этап | Что осваиваете | Сколько времени |
|---|---|---|
1. Python | До уверенного чтения чужого кода. Не «пишу свой фреймворк», а «понимаю, что делает эта фикстура» | 2–3 месяца |
2. pytest | Один стиль тестов, который вы повторяете с начала до конца. Фикстуры, параметризация, conftest | 3–4 недели |
3. HTTP и API-тесты | requests или httpx, проверка JSON-схем, негативные сценарии, аутентификация | 3–4 недели |
4. SQL и базы | Связать действие API с состоянием в таблице. Не «оптимизация запросов», а «найти запись после INSERT» | 2 недели |
5. Selenium / Playwright | Когда базовый Python уже не вызывает паники | 4–5 недель |
6. CI/CD | Прикрутить запуск тестов к репозиторию на GitHub Actions или GitLab CI | 1–2 недели |
7. Портфолио и подготовка к собеседованиям | Сделать 1–2 хороших публичных репозитория, прорешать типовые вопросы | 3–4 недели |
Итого реалистичный срок до первого оффера — около 6–8 месяцев, если заниматься 15–25 часов в неделю. Меньше 10 часов — растянется на год. Меньше 5 часов — рискуете не дойти вообще.
Эта последовательность близка к траектории «Автоматизатор тестирования на Python» на Хекслете: основы языка → pytest → API → базы → UI → трудоустройство.
Антипаттерны новичка в AQA
За пять лет наблюдений за людьми, заходящими в профессию, накопилась короткая инвентаризация типичных провалов.
Учить пять фреймворков параллельно. Pytest, unittest, behave, robot framework — потому что «вдруг где-то пригодится». В итоге плохо знаешь все пять. Лучше: один инструмент до автоматизма, остальные — после первого оффера, если потребуются.
Игнорировать ручное мышление. Автоматизация без модели рисков превращается в генератор хрупких тестов. Если вы не понимаете, ЧТО тестируете и ЗАЧЕМ — никакой код этого не починит.
Копировать код со Stack Overflow без понимания. Особенно опасно с асинхронностью и ожиданиями в UI-тестах. Внешне работает, потом разваливается в самый неподходящий момент.
Не гонять тесты локально перед коммитом. Полагаетесь на CI — съедаете время всей команды. Плюс пайплайны в крупных компаниях часто платные за минуту запуска.
Путать AQA с безопасностью или performance. Это смежные специализации с другими навыками и другими карьерными траекториями. Не пытайтесь делать всё сразу на старте.
Что положить в портфолио
Главный принцип: репозиторий должен быть запускаемым. Скриншоты курсов и сертификаты — не портфолио.
Элемент | Что показать |
|---|---|
Учебный сервис под тест | Можно учебный (например, открытый Petstore API), с docker-compose или README «как поднять локально» |
Структура папок | tests/api, tests/ui, общие фикстуры в conftest.py. Аккуратно, без свалки |
README | Как запустить, какие переменные окружения нужны, что считается smoke, как смотреть отчёты |
Примеры тестов | API-тест с позитивным и негативным сценарием. UI-тест с Page Object. Параметризованный тест |
Один пример баг-репорта | В Issues репозитория. Показывает зрелость работы с дефектами |
CI-конфиг | GitHub Actions, который запускает тесты на каждый push |
Чего быть НЕ должно: закоммиченных .env с паролями, видеофайлов на сотни мегабайт в истории git, секретов в коде, скопированных кусков из чужих репозиториев без атрибуции.
Собеседование AQA: что спрашивают
Типовая структура собеседования для джуна — три блока, иногда с разрывом по дням.
Блок 1: тестовое мышление
В чём разница между регрессионным тестированием и смоук-тестами?
Что такое приоритет дефекта, чем отличается от severity?
Как оформить хороший баг-репорт? Что обязательно должно быть?
Как протестировать функциональность авторизации?
Что делать с тестом, который то падает, то проходит?
Блок 2: Python и код
Напишите тест на функцию, которая делит два числа. Какие граничные значения проверите?
Объясните, зачем фикстура со scope='session'
Чем отличается параметризация от множества разных тестов?
Как сделать так, чтобы тесты не зависели друг от друга?
Что не так с этим кодом? (даётся кусок с нестабильным локатором или магической задержкой)
Блок 3: API и системные знания
Какие HTTP-методы знаете, чем они отличаются?
Что значит «идемпотентный запрос»?
Как протестировать, что API правильно работает с пагинацией?
Что делать, если ответ API правильный по статусу, но неправильный по содержимому?
Чем GET с параметрами отличается от POST с телом?
Красные флаги, после которых обычно не зовут на следующий этап: «я только записывал сценарии в рекордере», «тесты падают — значит тесты плохие, а не продукт» (иногда падает и то, и другое, нужно различать), «никогда не запускал тесты руками».
Куда расти из AQA: карьерные ветки
«AQA — это тупиковая ветка» — миф, который повторяют те, кто не разобрался. На самом деле из AQA открывается несколько траекторий, и каждая требует разных навыков.
Куда | Что нужно подтянуть | Сколько занимает |
|---|---|---|
Senior AQA → Lead QA | Управление командой, процессы, выстраивание стратегии тестирования | 2–3 года из миддла |
SDET / Test Architect | Архитектура фреймворков, инфраструктура, перфоманс | 3–4 года, нужен сильный код |
Backend-разработчик | Доменная разработка, паттерны проектирования, более глубокий Python | 1–2 года догонки |
DevOps / Platform Engineer | Kubernetes, инфраструктура как код, мониторинг | 1.5–2 года, если уже работали с CI |
Security Engineer | Веб-безопасность, инструменты пентеста, OWASP | 2 года, нужна отдельная сертификация |
Engineering Manager | Меньше кода, больше управления людьми и процессами | 3+ года любой инженерной работы |
Самые частые ветки на практике — Senior AQA и переход в разработку. Реже, но тоже стабильно — в DevOps, потому что навыки работы с CI и инфраструктурой тестов в AQA уже близки к DevOps-задачам.
Ручное тестирование сначала или сразу автоматизация?
Один из главных стратегических выборов на старте. Простого ответа нет — зависит от вашего города и от вакансий, на которые вы реально будете откликаться.
Когда логичнее идти в ручное QA сначала | Когда логичнее сразу в автоматизацию |
|---|---|
В вашем городе вакансий «QA без кода» в 3–5 раз больше, чем AQA | Цель — продуктовые компании или удалёнка на крупные команды |
Хотите быстрее начать получать зарплату (ручному QA нужно ~3 месяца до оффера, AQA — 6–8) | Уже умеете программировать на каком-то языке |
Программирование тяжело даётся, но мышление тестировщика — естественно | Программирование даётся легко, а механическая работа быстро надоедает |
Хотите потом плавно перейти в автоматизацию, добавляя Python в фоновом режиме | Готовы вложить 6+ месяцев в учёбу перед первой работой |
Если первый вариант ближе — посмотрите профессию «Инженер по ручному тестированию». Если второй — сразу «Автоматизатор тестирования на Python».
FAQ
Selenium или Playwright — что учить первым?
Для первой работы Selenium встречается чаще, особенно в крупных и легаси-системах. Playwright популярен в новых продуктовых командах. Если выбирать одно — берите Selenium: переход на Playwright потом займёт две недели, потому что концепции (явные ожидания, локаторы, Page Object) общие. Обратный переход обычно тоже несложный.
Обязательно ли знать Java для QA?
Нет, если вы идёте в автоматизацию на Python. Это разные рынки и разные стеки. Java-автоматизаторы тоже востребованы, но это отдельная профессия с другими инструментами (TestNG, JUnit, REST Assured). На вакансии «AQA Python» с Java не возьмут — и наоборот.
Возьмут ли в AQA вообще без опыта в IT?
Возьмут, но конкуренция высокая. Готовое портфолио с публичными тестами на GitHub и стажировка снимают большую часть вопросов на собеседовании. Без портфолио — почти невозможно: работодателю нужно проверить, что вы реально умеете писать код, а не только смотрели вебинары.
Сколько Python нужно знать?
Достаточно, чтобы уверенно писать и рефакторить тесты, читать чужой код фреймворка, понимать traceback и не пугаться при виде декораторов и контекстных менеджеров. ООП на базовом уровне нужно — фикстуры и Page Object без этого не освоить. Алгоритмы и структуры данных глубоко знать не обязательно, в отличие от разработчиков.
AQA-вакансии в 2026-м растут или сокращаются?
Растут, но не равномерно. Спрос на джунов остался примерно на уровне 2024 года — попасть сложно из-за конкуренции. Спрос на миддлов и сеньоров вырос ощутимо. Появилась новая категория задач — тестирование AI-функциональности в продуктах, и компании пока не очень понимают, как её закрывать. Это потенциальная ниша для тех, кто умеет работать с ML и LLM в дополнение к классическому QA.
Стоит ли учить ИИ-инструменты для AQA?
Да, это уже стало частью базовой грамотности. Cursor или Copilot помогают писать тесты быстрее — но только если вы понимаете, что они вам сгенерировали. На собеседованиях в 2026-м могут спросить, как вы используете ИИ в работе и какие у этого ограничения. Кратко эта тема разобрана в обзоре лучших ИИ для кодинга.
Можно ли совмещать учёбу AQA с текущей работой не в IT?
Можно, и большинство людей именно так и делает. Реалистичный график — 15–20 часов в неделю в течение 6–8 месяцев. Это вечерами по 2 часа в будни плюс по 4–5 часов в выходные. Меньше — растягивается на год, что тоже нормально, если не горит. Главное — не пропадать на месяцы: без регулярности всё забывается.
Чем закрывает программа Хекслета по AQA?
Связной траекторией от основ языка до выхода на рынок: Python, pytest, Selenium, API, базы данных и отдельный модуль про трудоустройство. Программа «Автоматизатор тестирования на Python» заточена под практику, есть гарантированная стажировка и сопровождение в поиске работы. Конкретный состав модулей и условия смотрите на странице программы — они актуализируются чаще, чем эта статья.