Данные из 416вакансий · 12 августа 2026

Как стать тестировщиком ПО: путь от нуля до первого оффера

Не «стань разработчиком за 3 месяца» — реальный путь входа на основе данных по 416 вакансий.

Мурадов ЮрийАвтор·Мурадов Юрий·Аналитик SkillStat
БАПроверено·Баранцев Алексей·Технический редактор·эксперт по тестированию ПО
Junior-вакансий сейчас
71
17% от всех 416 вакансий
Сложность входа
Низкая
17% junior-вакансий
Senior / Junior+Intern
1.3x
На каждого junior+intern — 1.3 senior
Навыков / вакансия
10
медиана по вакансиям
Всего вакансий
416
активных в Москве
Можно ли с нуля Короткий план Roadmap Junior-рынок Портфолио Резюме Собеседование Ошибки Обучение FAQ

Можно ли стать тестировщиком ПО с нуля

Да. По данным SkillStat, 17% вакансий тестировщика ПО — уровня junior или стажёр. Это 71 вакансия прямо сейчас.

«С нуля» у ручного тестировщика — это без коммерческого опыта, но с готовой головой: умение прочитать требование и увидеть, чего в нём не написано. Порог по инструментам низкий: Jira, Confluence и Postman осваиваются за пару вечеров, SQL-минимум — за две недели. Медиана требований в вакансии — 10 навыков, и бо́льшая часть списка про дисциплину проверки, а не про кнопки.

Трудность входа не в стеке. Тестирование — самая частая дверь в IT, и в очереди на junior-позицию стоят все, кому пообещали быстрый вход. Отсеивает не знание глоссария, а способность описать дефект так, чтобы разработчик воспроизвёл его без разговора с тобой. На одного junior приходится 1.3 senior-вакансии: платят за то, что человек находит проблему до релиза, а не после жалобы пользователя.

Как стать тестировщиком ПО: короткий план

Пять шагов от «нашёл кнопку» до дефекта, который команда принимает без уточняющих вопросов.

01
Тест-анализ
Бери требование и ищи, чего в нём нет: пустое поле, повторное нажатие, отказ на середине оплаты. Проверка начинается до продукта — с вопросов к постановке.
02
Тест-дизайн
Классы эквивалентности, границы, таблицы решений, переходы состояний. Это и отличает проверку от кликанья: ты решаешь, какие тридцать проверок заменяют триста.
03
Баг-репорт
Шаги, данные, окружение, факт, ожидание, доказательство. Навык меряется одним признаком: воспроизвёл ли разработчик дефект с первого раза.
04
API и данные
Postman — в 29.8% вакансий тестировщика ПО, SQL — в 45%. Нужны, чтобы понять, врёт экран или сервер, и что реально записалось в базу.
05
Портфолио и отклики
Тест-план, чек-лист, десяток баг-репортов, коллекция запросов. Дальше отклики: ждать «полной готовности» здесь дороже, чем в других ролях.

Что учить тестировщику ПО первым

Не всё сразу. Вот очерёдность по частотности в вакансиях — от самого нужного к менее срочному.

Полный список навыков с частотностью, связками и зарплатной премией — навыки тестировщика ПО →

Roadmap тестировщика ПО: от нуля до junior

Порядок опирается на частотность навыков по данным вакансий. Первые 4–5 этапов — минимум для первого оффера.

  1. 01
    Основы тестирования

    Виды тестирования, тест-дизайн, тест-кейсы, баг-репорты — фундамент профессии.

  2. 02
    SQL 45% вакансий

    Проверка данных на уровне БД — без этого нельзя полноценно тестировать backend.

    Подробнее →
  3. 03
    API-тестирование 17.3% вакансий

    HTTP/REST, Postman, Swagger — тестирование backend-интерфейсов.

    Подробнее →
  4. 04
    Баг-трекинг и документирование 34.4% вакансий

    Jira, Confluence, TestRail — работа с задачами и тестовой документацией.

    Подробнее →
  5. 05
    Автоматизация тестирования 13.9% вакансий

    Selenium, Playwright, PyTest — автоматизация регрессионных и e2e-тестов.

    Подробнее →
  6. 06
    CI/CD для тестов 13.5% вакансий middle+

    Интеграция тестов в пайплайн: запуск по PR, репорты, артефакты.

    Подробнее →
  7. 07
    Нагрузочное и безопасность middle+

    JMeter, k6, OWASP — производительность и базовые знания ИБ.

Junior-вакансии тестировщика ПО: что реально требуют работодатели

Срез построен на 416 активных вакансий.

Junior-вакансий
71
inc. стажировки
Доля junior
17%
от всего рынка
Senior / Junior+Intern
1.3x
соотношение
Навыков / вакансия
10
медиана
Распределение вакансий по грейдам
Intern — 4.3% (12)
Junior — 21% (59)
Middle — 39.1% (110)
Senior — 33.8% (95)
Lead — 1.8% (5)
Что значат эти цифры. 71 вакансия уровня junior из 416 — вход доступный. Особенность ручного тестирования: позиций много, но и откликов на каждую больше, чем где-либо ещё в IT. Зато отбор идёт не по объёму знаний, а через тестовое задание: дают форму или функцию и смотрят, какие проверки ты придумал и как описал найденное. Это единственное место в IT, где новичок и человек с годом опыта решают одну и ту же задачу на равных.

Какие проекты сделать для портфолио

Портфолио ручного тестировщика — не код. Это документы: тест-план, чек-лист, тест-кейсы и баг-репорты по живому продукту. Смотрящий проверяет одно — можно ли по твоему описанию работать, не задавая тебе вопросов.

Тест-план на одну функцию публичного сервиса
Средняя · 1 неделя
Стек: тестирование, Confluence, Jira
GitHub: Репозиторий или страница в Confluence: что проверяем, что не проверяем и почему, риски, окружения, критерии выхода
Ценность: Главный артефакт роли: видно, что ты решаешь, что проверять, а не проверяешь всё подряд
Десять баг-репортов по живому продукту
Лёгкая–средняя · 1–2 недели
Стек: тестирование, Jira
GitHub: Задачи в Jira или .md-файлы: шаги, данные, окружение, факт, ожидание, скриншот или запись экрана
Ценность: Проверка на профпригодность: дефект без шагов воспроизведения — причина отказа номер один
Коллекция API-проверок
Средняя · 1 неделя
Стек: Postman, REST API, Swagger, HTTP
GitHub: Экспорт коллекции Postman и README: какой сценарий закрывает каждый запрос и что считается ошибкой
Ценность: Postman — в 29.8% вакансий, Swagger — в 14.2%: проверка за пределами экрана
Сверка интерфейса и базы
Лёгкая–средняя · 3–5 дней
Стек: SQL, PostgreSQL
GitHub: Файл с запросами и коротким разбором: что показал экран, что лежит в базе, где разошлось
Ценность: SQL — в 45% вакансий тестировщика ПО, самый частый навык профессии
Регрессионный набор перед релизом
Средняя · 1 неделя
Стек: тестирование, Confluence
GitHub: Чек-лист с приоритетами: что гоняем всегда, что при изменении конкретного модуля, что можно пропустить
Ценность: Показывает мышление про риск, а не про полноту

Как оформить GitHub и резюме

Профиль GitHub
  • Публичный репозиторий с папками: тест-план, чек-листы, баг-репорты, коллекция запросов
  • Баг-репорты — текстом в .md, а не скриншотом задачи: их читают быстро и часто с телефона
  • Экспорт коллекции Postman положи файлом рядом с README, где описан проверяемый сценарий
  • SQL-проверки — отдельным файлом с комментарием, что именно доказывает каждый запрос
  • Бесплатный аккаунт Jira или Confluence — второй адрес портфолио: там видно, как ты ведёшь задачу
  • В README каждого артефакта: какой продукт, какая версия, какое окружение, почему проверял именно это
Резюме без коммерческого опыта
  • Раздел «Проекты» вместо «Опыт работы»: тест-план и набор дефектов описываются как рабочая задача
  • По каждому артефакту: что тестировал, какой техникой отбирал проверки, что нашёл
  • Навыки — только рабочие: SQL, REST. «Знаком с Postman» без коллекции в портфолио читается как ноль
  • Опыт из поддержки, операционки или колл-центра — не минус: ты уже разбирал чужие жалобы и знаешь продукт с другой стороны
  • Не пиши «внимательность и усидчивость» — это пишут все. Пиши, какой дефект нашёл в тестовом задании и почему его пропустили другие
Слабое резюме

«Изучил теорию тестирования, знаю Postman и SQL, умею писать тест-кейсы, внимательный и ответственный»

Сильное резюме

«Составил тест-план на модуль оформления заказа: разбил ввод на классы эквивалентности и границы, отобрал 34 проверки вместо 200 возможных. Нашёл 11 дефектов, три блокирующих — повторная отправка формы создавала дубль заказа, подтвердил запросом к PostgreSQL. Все баг-репорты с шагами и записью экрана. Портфолио: [ссылка]»

Самостоятельно, курсы или вуз — какой путь выбрать

Самостоятельно
Тест-дизайн и инструменты закрываются по открытым источникам, а тренироваться можно на любом публичном сайте или приложении
Никто не скажет, что твой баг-репорт нечитаемый, — сам ты этого не увидишь, пока по нему кто-то не попробует воспроизвести
Если рядом есть кому показать дефекты: сообщество, знакомый тестировщик, открытая бета
Курсы с ментором
Разбор твоих тест-кейсов и дефектов чужими глазами — единственное, что реально ускоряет вход
Дорого; половина программ учит глоссарию и молчит про то, как отобрать тридцать проверок из трёхсот
Если нужна структура и внешний дедлайн. Программу проверяй по одному признаку: разбирают ли там твои баг-репорты
Вуз / колледж
Даёт техническую базу — сети, базы данных, Linux — и вход в компании, где тестировщик сидит внутри команды разработки
Четыре года; тестирование в программе обычно занимает один курс, а тест-дизайну там почти не учат
Если выбираешь первое образование и целишься дальше в автоматизацию или технический QA
Ловушка ручного тестирования: теория вместо разбора. Виды и уровни тестирования пересказывают на любом собеседовании, и платят не за это. Платят за вопрос «что будет, если нажать „Оплатить“ дважды подряд при плохой сети». Глоссарий учится за неделю, привычка искать сломанный случай — месяцами и только на живом продукте.

Что спрашивают на собеседовании

Тест-дизайн
Типовые вопросы
  • ·Классы эквивалентности и границы на примере поля «возраст»
  • ·Когда нужна таблица решений
  • ·Как отобрать двадцать проверок вместо двухсот
  • ·Что такое переходы состояний и где они нужны
Как показать проектом

Тест-план из портфолио: объясни, почему часть проверок в него не попала

Дефекты и баг-репорты
Типовые вопросы
  • ·Приоритет и серьёзность — в чём разница
  • ·Что обязательно должно быть в баг-репорте
  • ·Разработчик пишет «не воспроизводится» — твои действия
  • ·Нашёл дефект за час до релиза
Как показать проектом

Набор баг-репортов: покажи тот, который переписал после вопросов разработчика

Клиент-сервер и API
Типовые вопросы
  • ·Что происходит между нажатием кнопки и ответом на экране
  • ·Коды ответов HTTP: ответ 200 с ошибкой внутри — что это значит
  • ·Как проверить в Postman негативный сценарий
  • ·Зачем читать Swagger, если есть интерфейс
Как показать проектом

Коллекция запросов: покажи проверку, которую через экран сделать нельзя

Данные и SQL
Типовые вопросы
  • ·SELECT, WHERE, JOIN — задача на бумаге
  • ·Как найти дубли в таблице
  • ·Экран показывает статус «Оплачено», а деньги не списались — где смотришь
  • ·Зачем тестировщику PostgreSQL, если есть интерфейс
Как показать проектом

Файл с SQL-проверками: покажи запрос, который поймал расхождение

Процесс и релиз
Типовые вопросы
  • ·Что такое регрессия и зачем гонять её каждый раз
  • ·Как ведёшь тестовую документацию в Confluence
  • ·Что проверяешь первым делом на новой сборке
  • ·Когда сценарий пора отдавать в автоматизацию
Как показать проектом

Регрессионный чек-лист: объясни приоритеты

Сколько времени нужно, чтобы стать тестировщиком ПО

Минимум
3–5 мес
С технической базой и разбором твоих дефектов от практика: тест-дизайн — единственное, что придётся учить всерьёз
Медиана
6–9 мес
Самостоятельно, с нуля, по 2–3 часа в день, с портфолио вместо конспектов
Реалистично
9–14 мес
При совмещении с работой и с поправкой на то, что первый отклик — не первый оффер

Почему «тестировщик за 3 месяца» — полуправда. Глоссарий и Postman за три месяца правда осваиваются. Но вход упирается не в них, а в очередь: тестирование — самая рекламируемая дверь в IT, и на тестовом задании сразу видно, кто пересказал курс, а кто разобрал продукт. Три месяца — срок до первого отклика, а не до оффера.

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

Ошибки новичков

Баг-репорт без шагов воспроизведения

Почему мешает: «Не работает кнопка оплаты» — это жалоба, а не дефект. Разработчик тратит полчаса на восстановление контекста и возвращает задачу со статусом «не воспроизводится». На тестовом задании это причина отказа номер один

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

Проверяют только позитивный сценарий

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

Как исправить: На каждый сценарий — минимум один негативный и один граничный. Привыкай спрашивать: что будет, если сделать это дважды

Учат Selenium вместо тест-дизайна

Почему мешает: Selenium — в 13.9% вакансий тестировщика ПО, и в manual-вакансиях это мост к автоматизации, а не ядро роли. Автотест, написанный без тест-дизайна, повторяет клики и не проверяет ничего

Как исправить: Сначала классы эквивалентности, границы, таблицы решений. Инструменты автоматизации — после первого оффера

Верят экрану

Почему мешает: Интерфейс показывает «Заказ создан», а в базе дубль или пустой статус. SQL — в 45% вакансий, самый частый навык профессии, и нужен он ровно для этого

Как исправить: Минимум: SELECT, WHERE, JOIN, GROUP BY. Каждую проверку статуса подтверждай запросом к PostgreSQL

Копят тест-кейсы, но не обновляют

Почему мешает: Набор из трёхсот устаревших кейсов хуже чек-листа на страницу: команда перестаёт ему верить и гоняет проверки по памяти

Как исправить: После каждого изменения продукта — вычистить набор. Устаревший кейс удаляют, а не помечают «проверить потом»

Заводят дубли дефектов

Почему мешает: Один и тот же баг тремя задачами — это шум в Jira и первый признак, что человек не искал перед созданием

Как исправить: Перед созданием — поиск по симптому и по модулю. Похожий есть — комментарий к нему, а не новая задача

Ставят приоритет по эмоции

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

Как исправить: Разведи серьёзность и приоритет: первое про масштаб поломки, второе про очередь на исправление

Ждут идеального портфолио

Почему мешает: Тестирование — это очередь. Пока ты доводишь тест-план до красоты, тестовые задания решают другие

Как исправить: Отклик с тремя читаемыми баг-репортами сильнее молчания с двадцатью ненаписанными

Как SkillStat считает данные

Источник: 416 вакансий в московском сегменте. Навыки и грейды извлекаются автоматически из текста каждой вакансии.

Грейды: определяются по требованиям вакансии — уровню опыта, упоминанию «junior», «intern», «стажёр». Это рыночная оценка объявления.

Сложность входа: рассчитывается по доле junior-вакансий и медиане навыков на junior-уровне. Это индикатор, а не гарантия.

Обновление: данные пересчитываются регулярно. Текущий срез — 12 августа 2026.

Частые вопросы

Можно ли стать тестировщиком ПО с нуля?
Да, это самая частая первая работа в IT. По данным SkillStat, junior и стажёров среди вакансий тестировщика ПО — 71 из 416. Технического образования обычно не требуют: берут за тест-дизайн и умение описать дефект. Обратная сторона — сюда же идут все остальные новички, поэтому отбор идёт через тестовое задание.
Нужно ли программировать ручному тестировщику?
Для первой работы — нет. Python встречается в 26.7% вакансий тестировщика ПО, Java — в 23.1%, но у manual-роли это чаще про чтение: понять, что проверяет чужой автотест, и разобрать лог. Писать автотесты — работа QA Automation, отдельной профессии со своим рынком.
Нужен ли SQL?
Да, это самый частый навык профессии: 45% вакансий (187 из 416). PostgreSQL — в 16.6%. Нужен, чтобы проверять факт, а не верить экрану: записался ли статус, не создался ли дубль, совпадают ли данные интерфейса и базы. Минимум — SELECT, WHERE, JOIN, GROUP BY.
Нужен ли Postman?
Да. Postman — в 29.8% вакансий тестировщика ПО (124 из 416), REST API — в 17.3%, Swagger — в 14.2%. Через экран не проверишь, что сервер отдаёт при пустом теле запроса, чужом токене или повторной отправке. Коллекция запросов — обязательный артефакт портфолио.
Чем чек-лист отличается от тест-кейса?
Детализацией и ценой поддержки. Чек-лист — список того, что надо проверить, без шагов: быстро писать, быстро обновлять, но нужен человек, знающий продукт. Тест-кейс — шаги, данные, ожидаемый результат: по нему проверку выполнит новичок, зато каждое изменение продукта заставляет его переписывать. Рабочий баланс — чек-листы на всё, кейсы на критичное и сложное.
Что обязательно в баг-репорте?
Окружение, тестовые данные, шаги по одному действию, фактический результат, ожидаемый результат и доказательство — скриншот, запись экрана или лог. Проверка одна: разработчик воспроизводит дефект, не задавая тебе вопросов. Баг-репорт без шагов — главная причина, по которой новичок не проходит тестовое задание.
Нужен ли Selenium ручному тестировщику?
Не для входа. Selenium — в 13.9% вакансий тестировщика ПО, и в manual-вакансиях он читается как мост к автоматизации: полезно понимать, что делает автотест, чтобы не проверять то же руками. Учить его вместо тест-дизайна — потеря времени: без тест-дизайна автотест просто повторяет клики.
Что такое регрессия и зачем гонять её каждый релиз?
Регрессия — повторная проверка того, что уже работало, после изменений в соседнем месте. Правка в корзине ломает оформление заказа чаще, чем кажется. Смысл роли не в том, чтобы прогнать весь набор, а в том, чтобы решить, какие проверки нужны при этом изменении, а какие можно пропустить без риска для пользователя.
Нужен ли Linux?
Полезен: Linux — в 22.6% вакансий тестировщика ПО. Нужен, чтобы дойти до логов на стенде самому, а не просить их у разработчика. Минимум — подключиться, найти файл, посмотреть хвост лога, отфильтровать по времени и ошибке. CI/CD (25.7%) и Jenkins (13.5%) в требованиях означают то же самое: тестировщик забирает сборку сам.
Когда переходить в автоматизацию?
Когда ручные проверки стали повторяемыми и надоели, а тест-дизайн уже не вызывает вопросов. Порядок именно такой: QA Automation — отдельная профессия, рынок там устроен иначе, а требования начинаются с языка, Git и CI/CD. Год ручного тестирования делает переход коротким; попытка перескочить — длинным.
Что показать в портфолио без коммерческого опыта?
Тест-план на одну функцию публичного сервиса, десяток баг-репортов по нему, коллекцию запросов и файл SQL-проверок. Используй ключевые навыки профессии: SQL, REST, Jira. Учебное «протестируйте карандаш» из курса не считается — бери живой продукт, где есть настоящие дефекты.
Нужен ли сертификат ISTQB?
Не обязателен. Он структурирует терминологию и иногда помогает пройти формальный фильтр в крупных компаниях и аутсорсе. Тестовое задание он не заменяет: там смотрят на набор проверок и читаемость дефектов, а не на строчку в резюме. Выбираешь между сертификатом и портфолио — бери портфолио.
Сколько времени нужно, чтобы стать тестировщиком ПО?
Медиана — 6–9 месяцев при самостоятельном обучении по 2–3 часа в день. С технической базой и разбором дефектов от практика — 3–5 месяцев. Теория закрывается за месяц, привычка искать сломанный случай — нет.
Где искать первую работу?
hh.ru с фильтром junior и стажировка, аутсорс и аутстафф (берут новичков потоком), внутренний переход из поддержки или операционки, открытые беты для портфолио. Названия у одной работы разные: «тестировщик», «QA engineer», «специалист по тестированию» — смотри все. Сейчас на рынке 71 вакансия для junior.
Что спрашивают на собеседовании junior QA?
Тест-дизайн (классы эквивалентности, границы, таблица решений), состав баг-репорта, разницу приоритета и серьёзности, клиент-серверное взаимодействие и коды ответов HTTP, SQL на уровне соединения таблиц. Почти всегда просят придумать проверки для простого объекта прямо на встрече. Подробнее — в разделе «Собеседование» на этой странице.
Сколько зарабатывает начинающий Ручной тестировщик?
Ориентир для junior — 56 925–82 225 ₽ при медиане по профессии 126 500 ₽. Разбивка по грейдам и динамика — на странице зарплат тестировщика ПО.
Где посмотреть навыки тестировщика ПО?
На странице навыков тестировщика ПО — частотность по 416 вакансий, разбивка по грейдам и связки инструментов.