Дорожная карта QA-инженера: от ручных тестов к автоматизации
Дорожная карта QA-инженера на 2026 год: от ручного тестирования к автоматизации — навыки, зарплаты на «Хабр Карьере», инструменты, сроки и план обучения.
Дорожная карта QA-инженера когда-то означала одно: научиться щёлкать по приложению и заводить баг-репорты. В 2026 году значение другое. По данным World Quality Report 2024–25, средний уровень автоматизации тестирования в мире достиг 44%, а 68% компаний уже используют генеративный ИИ в обеспечении качества (Capgemini, 2024). Ручное тестирование не исчезает, но роль смещается к тем, кто умеет проверять систему систематически, а затем повторять эти проверки кодом.
Хорошая новость в том, что тестирование остаётся самым доступным входом в IT и в России. По данным «Хабр Карьеры», медианная зарплата в тестировании составляет около 179 800 рублей в месяц, а спрос на инженеров по тестированию держится на уровне «растущего». Диплома программиста для старта не требуется, а навыки выстраиваются в понятную последовательность — сначала тест-дизайн, затем SQL и API, затем автоматизация. Ваша дорожная карта QA-инженера начинается с сильных сторон, а не с чистого листа.
В этом руководстве — чем занимается QA-инженер, какие навыки и инструменты требуют работодатели, на какие зарплаты QA-инженера стоит рассчитывать, как выглядит пошаговый путь от ручного тестирования к автоматизации и какие ошибки чаще всего тормозят новичков.
Если удобнее сначала увидеть весь путь целиком, в этом видео по шагам разобрано, как стать тестировщиком с нуля:
Чем на самом деле занимается QA-инженерPermalink to “Чем на самом деле занимается QA-инженер”
QA-инженер (инженер по тестированию) проверяет, что программа работает так, как задумано, до того, как её увидят пользователи. Звучит просто, но на деле это значит: читать требования, проектировать проверки, которые покрывают и обычный сценарий, и граничные случаи, выполнять эти проверки, понятно описывать дефекты и подтверждать исправления так, чтобы не сломать что-то ещё. Грамотный QA-инженер — последняя линия обороны между сломанной функцией и разочарованным клиентом.
Работа делится на две дисциплины с общим складом ума. Ручное тестирование — это проверка руками: вы изучаете приложение, проходите по тест-кейсам, пробуете нестандартные вводы и фиксируете, что сломалось. Здесь нужны терпение, здоровый скептицизм и умение точно воспроизвести баг. Автоматизация тестирования — это код, который запускает те же проверки за вас, чтобы регресс можно было прогнать за минуты, а не за часы, при каждом изменении программы. Автоматизация не заменяет ручное тестирование — исследовательское тестирование всё равно находит дефекты, которых скрипты не ждут. Она берёт на себя повторяющиеся, однозначные проверки и освобождает человека для непредсказуемых.
За типичную неделю QA-инженер может написать тест-кейсы по спецификации, прогнать регресс перед релизом, завести баги с шагами воспроизведения в Jira, разобрать вместе с разработчиком «мигающий» тест и добавить новую автоматическую проверку для функции, вышедшей в этом спринте. Роль стоит на стыке продукта, разработки и пользователя: вы понимаете, что должны были сделать, что сделали на самом деле и имеет ли значение разница.
Навыки, которые реально нужныPermalink to “Навыки, которые реально нужны”
В вакансиях QA перечислен длинный список инструментов, из-за чего сфера кажется сложнее, чем есть. На деле навыков немного, и каждый следующий легче предыдущего, если учить их по порядку.
| Группа навыков | Что это значит | Почему это важно |
|---|---|---|
| Тест-дизайн | Классы эквивалентности, граничные значения, исследовательское тестирование | Основа профессии — определяет, что проверять и как находить настоящие дефекты |
| SQL | Запросы и проверка данных в базе | Большинство багов прячется в данных; вы проверяете, что приложение записало, а не только что показало |
| Тестирование API | REST, запросы и ответы, коды статусов, Postman | Современные приложения — это API с интерфейсами; проверка бэкенда ловит дефекты раньше |
| DevTools браузера | Сеть, консоль, элементы, хранилище | Позволяет увидеть, что приложение реально сделало, а не то, что только кажется сделанным |
| Автоматизация тестирования | Фреймворк — Playwright, Cypress или Selenium | Повторяет регрессионные проверки быстро и надёжно |
| Контроль версий | Git, GitHub или GitLab | Автотесты живут в том же репозитории, что и код продукта |
| Гибкие навыки | Грамотное письмо, коммуникация, аналитика, эмпатия | О дефектах сообщают письменно и обсуждают с людьми; ясность решает, исправят ли их |
Закономерность неслучайна: тест-дизайн и SQL учат что проверять, API и DevTools — где искать, а автоматизация с Git — как повторять эти проверки в масштабе. Если вы определяете разрыв в навыках до того, как переучивать всё, порядок важен не меньше списка: броситься сразу к инструменту, пока вы ещё не умеете проектировать тест, — значит автоматизировать не те проверки.
Инструменты: чем реально пользуются работодателиPermalink to “Инструменты: чем реально пользуются работодатели”
Рынок инструментов автоматизации меняется быстро, но несколько фактов достаточно устойчивы, чтобы на них опираться. Selenium остаётся стандартом в корпоративном секторе — у него самая широкая экосистема, поддержка наибольшего числа языков, а вместе с Appium это по-прежнему выбор для нативного мобильного тестирования, недоступного новым инструментам. Playwright растёт быстрее всех: в опросе State of JS 2025 он вышел на 91% удовлетворённости против 72% у Cypress — рекордная разница, — а по недельным скачиваниям с npm обгоняет Cypress примерно в десять раз. Cypress сохраняет преданное ядро благодаря удобству разработчика и простоте старта.
| Инструмент | Для чего лучше всего | Где он в 2026 году |
|---|---|---|
| Selenium | Кросс-браузерные и унаследованные энтерпрайз-наборы; мобильное через Appium | Зрелый стандарт — чаще других встречается в вакансиях крупных компаний |
| Playwright | Современная веб-автоматизация в Chromium, Firefox, WebKit | Самый быстрый рост; лучшая удовлетворённость в State of JS 2025 |
| Cypress | Веб-тестирование с фокусом на фронтенд и удобством | Стабилен, популярен в небольших командах |
| Postman | Ручное и скриптовое тестирование API | Стандарт для проверки и исследовательского тестирования бэкенда |
| Appium | Нативная мобильная автоматизация | Выбор, когда нужно покрытие мобильных платформ |
Учить всё это не нужно. Разумный план — выйти на уверенное владение одним веб-фреймворком (Playwright, если начинаете сейчас, Selenium, если метите в крупные компании) плюс Postman для API. Глубина в одном инструменте ценнее поверхностного знакомства с пятью, а навыки переносятся: научившись автоматизировать на Playwright, вы разберётесь с Selenium или Cypress за счёт синтаксиса, а не с нуля.
Дорожная карта QA-инженера: пять шаговPermalink to “Дорожная карта QA-инженера: пять шагов”
Этот маршрут предполагает, что вы начинаете без технического опыта и занимаетесь примерно десять-пятнадцать часов в неделю. Если вы приходите из смежной роли — техподдержка, бизнес-анализ, разработка — ранние шаги можно сильно сократить.
Шаг 1: Основы ручного тестирования (месяцы 1–2)Permalink to “Шаг 1: Основы ручного тестирования (месяцы 1–2)”
Прежде чем браться за инструмент, научитесь думать как тестировщик. Изучите основы тест-дизайна: как превратить требование в тест-кейсы, как применять классы эквивалентности и анализ граничных значений, чтобы покрыть максимум проверками, и как проводить исследовательское тестирование, где вы намеренно ищете неожиданное.
- Освойте терминологию: тест-кейс, дефект, регресс, смоук-тест, граничный случай, серьёзность и приоритет
- Тренируйтесь писать баг-репорты: точные шаги воспроизведения, ожидаемый и фактический результат, данные окружения
- Тестируйте настоящие приложения: выберите публичный сайт, составьте тест-кейсы для функции и оформите найденные дефекты так, будто сдавали бы их команде
- Прочитайте программу ISTQB Certified Tester Foundation Level — она бесплатна и остаётся каноническим справочником по основам тестирования в мире
Результат: документ с грамотными тест-кейсами и баг-репортами для реального приложения, доказывающий, что вы умеете находить и описывать дефекты.
Шаг 2: SQL, API и DevTools (месяцы 2–4)Permalink to “Шаг 2: SQL, API и DevTools (месяцы 2–4)”
Здесь вы перестаёте проверять только поверхность и начинаете сверять то, что происходит под ней. Серьёзные дефекты чаще всего живут в данных и бэкенде, и работодатели ждут, что QA-инженер проверяет и там.
- Освойте SQL до уровня соединений, агрегаций и фильтрации — достаточно, чтобы проверять, что приложение записало в базу
- Изучите основы REST API: методы, коды статусов, тело запроса и ответа, аутентификацию
- Работайте в Postman: отправляйте запросы к публичному API и проверяйте ответы утверждениями
- Освойте DevTools браузера: читайте вкладку «Сеть», чтобы видеть реальные запросы, «Консоль» для ошибок и хранилище приложения
Результат: небольшой набор SQL-запросов, проверяющих состояние приложения, и коллекция в Postman, тестирующая публичный API от начала до конца.
Шаг 3: Первая автоматизация (месяцы 4–7)Permalink to “Шаг 3: Первая автоматизация (месяцы 4–7)”
Теперь вы пишете код, который проверяет код. Выберите один язык и один фреймворк и оставайтесь с ними. Если предпочтений нет, берите JavaScript или TypeScript с Playwright — современный, быстрый и самый востребованный из новых фреймворков — либо Python с фреймворком вроде Selenium, если хотите быть ближе к бэкенду и данным.
- Выучите свой язык настолько, чтобы читать код, писать функции и пользоваться условиями и циклами
- Создавайте автоматические UI-проверки в фреймворке: открыть страницу, заполнить форму, нажать кнопку, проверить результат
- Освойте Git: фиксируйте тесты, отправляйте в GitHub и тренируйтесь читать изменения (diff)
- Пишите проверки для тех же сценариев, что тестировали вручную на шаге 1, — автоматизация повторяет то, что спроектировал грамотный тестировщик
Результат: репозиторий на GitHub с небольшим набором автотестов, который авторизуется, проходит ключевой пользовательский сценарий и проверяет результат, — с README, объясняющим, как его запустить.
Шаг 4: Интеграция, доработка и глубина (месяцы 7–10)Permalink to “Шаг 4: Интеграция, доработка и глубина (месяцы 7–10)”
Этот шаг превращает набор скриптов в то, чем команда стала бы реально пользоваться. Настоящая работа автоматизатора — меньше про написание новых проверок и больше про поддержку надёжного набора, пока продукт меняется.
- Запускайте тесты в CI-пайплайне (проще всего начать с GitHub Actions), чтобы они выполнялись при каждом изменении
- Освойте сложное: ожидания и тайминги, Page Object Model для поддерживаемой структуры и дата-ориентированные тесты
- Диагностируйте и чините «мигающие» тесты — те, что проходят и падают без изменений кода, — потому что ненадёжный набор подрывает доверие быстрее, чем отсутствие набора
- Добавьте API-автоматизацию рядом с UI-тестами: самые быстрые и стабильные проверки обычно идут на уровень API
Результат: набор тестов, подключённый к CI, со структурированными page objects и смесью UI- и API-проверок, плюс короткий разбор мигающего теста, который вы нашли и починили.
Шаг 5: Портфолио, сертификация и поиск работы (месяцы 10–12)Permalink to “Шаг 5: Портфолио, сертификация и поиск работы (месяцы 10–12)”
К этому моменту у вас есть то, что ищут работодатели. Этот шаг — доказать это и грамотно подать.
- Соберите портфолио с настоящей тестовой работой — тест-планы, баг-репорты и запускаемые автотесты, — опираясь на принципы из полного руководства по портфолио для смены профессии
- Подумайте о сертификации ISTQB Certified Tester Foundation Level. По состоянию на май 2025 года ISTQB провёл более 1,5 млн экзаменов и выдал более 1,1 млн сертификатов в 130+ странах; экзамен базового уровня стоит около 20 000 ₽ (в России — у реселлеров ISTQB). Сама по себе она работу не принесёт, но подтвердит, что вы владеете терминологией и принципами дисциплины
- Адаптируйте резюме под тестовые навыки, которые вы наработали, а не под прошлые должности, и тренируйтесь рассказывать про найденный баг и автоматизированную проверку
Автоматизируйте то, что уже проверяете руками
Самая частая ошибка в автоматизации — писать проверки для сценариев, которые вы никогда не тестировали вручную. Прежде чем автоматизировать что-либо, пройдите сценарий руками, найдите реальные точки отказа и только потом пишите скрипт. Автоматизация повторяет ваше профессиональное суждение — поэтому сначала наработайте именно его.
Сертификации: какие действительно важныPermalink to “Сертификации: какие действительно важны”
Тестирование — одна из немногих сфер в IT, где существует признанный независимый от вендора сертификат. Схема ISTQB — мировой стандарт, и её базовый уровень логично выбрать стартом.
| Сертификация | Поставщик | Примерная стоимость | Когда получать |
|---|---|---|---|
| ISTQB Certified Tester Foundation Level (CTFL) | ISTQB / национальные советы | ≈20 000 ₽ (в РФ — у реселлеров ISTQB) | После шага 2 — подтверждает знание основ |
| ISTQB Agile Tester Extension | ISTQB | ≈22 000 ₽ | После CTFL, если метите в Agile-команды |
| Курсы по инструментам (Playwright, Selenium) | Разные | Варьируется | По желанию — проект в портфолио скажет больше, чем сертификат о курсе |
Сертификация — это сигнал, а не замена работе. CTFL плюс репозиторий на GitHub с настоящим набором автотестов — куда более сильная заявка, чем что-то одно. Если выбираете между платными курсами и самостоятельным обучением, сначала решите, нужна ли вам структура и оценки или достаточно самого материала. Для QA бесплатная программа ISTQB плюс практический проект покрывают большую часть того, чему учил бы платный курс.
Зарплаты: сколько зарабатывает QA-инженерPermalink to “Зарплаты: сколько зарабатывает QA-инженер”
Зарплата в тестировании повторяет разделение самой работы: ручные роли относятся к стартовому уровню, а автоматизация оплачивается выше. По данным «Хабр Карьеры», медианная зарплата в тестировании составляет около 179 800 рублей в месяц по всем грейдам — она смещена вверх, потому что данные «Хабр Карьеры» собираются с уже работающих специалистов, а не с тех, кто только ищет первую роль. По данным «Хабр Карьеры» и hh.ru за 2025 год грейдовые вилки выглядят так:
| Грейд | Типичная зарплата в России, ₽/мес |
|---|---|
| Junior (ручное тестирование) | 60 000 – 100 000 |
| Middle (ручное + базовая автоматизация) | 120 000 – 180 000 |
| Senior / автоматизация (SDET) | 200 000 – 300 000 |
Цифру увеличивают три фактора: умение автоматизировать, сеньорный опыт и работа со сложными или регулируемыми системами. Инженер, способный спроектировать надёжный набор автотестов и поддерживать его в CI, зарабатывает заметно больше ручного тестировщика при том же стаже. Актуальные цифры по уровням и регионам собраны в подробном разборе зарплат QA-инженера.
Для мирового контекста: в США медианная годовая зарплата аналитиков и тестировщиков качества ПО составляла $102 610 по данным Бюро статистики труда за май 2024 года, а занятость в группе «разработчики, QA и тестировщики» вырастет на 15% с 2024 по 2034 год — намного быстрее среднего. В России ориентируйтесь прежде всего на данные «Хабр Карьеры» и hh.ru.
Сколько на самом деле занимает переходPermalink to “Сколько на самом деле занимает переход”
Тестирование — одна из самых быстрых по входу ролей в IT, и именно поэтому оно привлекает тех, кто меняет профессию. Реальные сроки зависят от того, как глубоко вы заходите в автоматизацию и сколько часов готовы уделять:
| Отправная точка | Часов в неделю | Цель | Реальный срок до трудоустройства |
|---|---|---|---|
| Без опыта в IT | 10–15 | Ручное тестирование | 4–6 месяцев |
| Без опыта в IT | 10–15 | Джун-автоматизатор | 9–12 месяцев |
| Без опыта в IT | 20–30 | Джун-автоматизатор | 6–9 месяцев |
| Смежная роль (техподдержка, бизнес-анализ, PM) | 10–15 | Джун-автоматизатор | 5–8 месяцев |
| Разработчик, переходящий в QA | 10–15 | Автоматизация / SDET | 2–4 месяца |
Те, кто приходит из техподдержки, бизнес-анализа или управления проектами, получают реальную фору: они уже понимают таск-трекеры, требования и то, как общаются команды разработки, поэтому тратят время на ремесло тестирования, а не на азы работы в коллективе. Если неясно, куда относит ваш опыт, структурированный разбор сроков смены профессии по вашим навыкам даст более точную оценку, чем общая таблица.
Частые ошибки, которые тормозят новичков в QAPermalink to “Частые ошибки, которые тормозят новичков в QA”
Ошибка 1: Браться за автоматизацию до ручного тестированияPermalink to “Ошибка 1: Браться за автоматизацию до ручного тестирования”
Новички слышат, что автоматизация платит больше, и сразу переходят к фреймворку. Итог — скрипты, проверяющие очевидный путь и пропускающие каждый настоящий дефект, потому что автор не научился находить дефекты руками. Первые два месяца уделите тест-дизайну и ручному тестированию. Автоматизация усиливает ваш тестировочный навык, но не создаёт его с нуля. Где в работе QA-инженера уместно ручное тестирование, а где автоматизация, подробно разобрано в руководстве ручное тестирование или автоматизация: с чего начать в QA.
Ошибка 2: Собирать инструменты вместо глубиныPermalink to “Ошибка 2: Собирать инструменты вместо глубины”
В вакансиях QA перечислены Selenium, Cypress, Playwright, Appium, Postman, JMeter и ещё три названия. Новички пытаются выучить всё и остаются поверхностными во всём. Выберите один фреймворк автоматизации и один инструмент для API, дойдите до глубины и не трогайте остальное, пока не устроитесь, — именно глубина ведёт к офферу, а остальное быстро переносится потом.
Ошибка 3: Нет запускаемых доказательствPermalink to “Ошибка 3: Нет запускаемых доказательств”
Указать в резюме «Selenium» без репозитория в подтверждение не переживает техническое собеседование. Каждый шаг в этом маршруте имеет результат именно потому, что наниматели хотят видеть запускаемые тесты, настоящие баг-репорты и историю коммитов, а не список пройденных курсов. Это та же логика, что в полном руководстве по портфолио для смены профессии: доказательства убедительнее заявлений.
Ошибка 4: Игнорировать мигающие тестыPermalink to “Ошибка 4: Игнорировать мигающие тесты”
Ненадёжный набор, который падает случайно, хуже отсутствия набора, потому что команда привыкает его игнорировать. Умение диагностировать нестабильность — тайминги, разделяемое состояние, неустойчивые селекторы — часть работы, а не продвинутое дополнение. Если вы не можете объяснить, почему тест мигает, вы ещё не закончили его автоматизировать.
Подходит ли вам QAPermalink to “Подходит ли вам QA”
Тестирование подходит тем, кто любит намеренно ломать вещи, замечает детали, мимо которых проходят другие, и может описать проблему настолько точно, чтобы другой человек смог её воспроизвести. Оно ценит скептицизм, уравновешенный эмпатией: вы выступаете за пользователя, а не воюете с разработчиками.
Три признака, что QA вам подходит:
- Вы инстинктивно ищете граничные случаи и спрашиваете «а что, если кто-то сделает вот так неправильно?»
- Вы можете описать проблему письменно так ясно, что незнакомец её воспроизведёт
- Вам нравится автоматизировать рутину, чтобы освободить время для интересного
Три признака, что может не подойти:
- Вы хотите создавать функции, а не проверять их, — присмотритесь к разработке
- Кропотливая работа, требующая внимания к деталям, вас утомляет, а не заряжает
- Вам неприятны постоянные разбирательства: воспроизвести дефект и обсудить его с командой
Если колеблетесь между QA и смежными путями — аналитикой данных или разработкой, — общее сравнение в руководстве по переходу в IT сопоставляет порог входа, зарплаты и сроки, чтобы выбрать на фактах, а не наугад.
Чем помогает TraectaPermalink to “Чем помогает Traecta”
Самое медленное на пути в QA — понять, где вы уже стоите: какие из ваших навыков засчитываются в тестирование, какие пробелы по-настоящему важны для работодателей и в каком порядке их закрывать. Персональный план смены профессии в Traecta берёт это сопоставление на себя: он сопоставляет навыки, которые у вас уже есть, — из обращений в техподдержку, из документации, из вычитки чужой работы, — с тем, что реально проверяют наниматели в QA; отделяет пробелы, важные для автоматизации, от тех, что важны лишь для ручного тестирования; и выстраивает обучение вокруг тестового стека вашей цели — сначала тест-дизайн, затем SQL и проверки API, затем фреймворк вроде Playwright или Selenium. Ваш план стартует с сильных сторон, которые вы уже можете подтвердить.
Это не абстрактный совет. Когда я переходил из системного администрирования в аналитику внутри HealthTech-компании, важным оказался не сданный курс, а момент, когда код, который я написал, впервые провёл реальные данные пациентов через пайплайн. В эту секунду работа перестаёт быть теорией. То же верно и для тестирования: момент, который по-настоящему важен, — первый реальный дефект, который вы поймаете до того, как на него наткнётся пользователь. Ваш план должен подвести вас к этому моменту так быстро, как позволяют имеющиеся навыки.
ГлавноеPermalink to “Главное”
Дорожная карта QA-инженера ведёт от ручного тестирования к автоматизации в чётком порядке: научитесь проектировать тесты и находить дефекты руками, добавьте SQL и API, чтобы проверять под поверхностью, автоматизируйте проверки, достойные повторения, подключите их в CI и подтвердите всё запускаемым портфолио. Сфера растёт — медиана около 179 800 ₽ в месяц по «Хабр Карьере» и устойчивый спрос — и остаётся самой доступной дверью в IT для людей без технического опыта. Начинайте с ремесла тестирования, а не с инструментов, и пусть автоматизация развивает навык, который вы уже наработали. Если хотите выстроить этот путь под свой опыт, персональный план обучения в Traecta покажет следующие шаги.
