QA-вакансии смешивают три профессии: ручной исследовательский контур, «человек с чек-листом и SQL», автоинженер. Вишлист при этом один на всех: Selenium, Cypress, Postman, Jira, CI, «желательно Java». Собирать по нему мозг бессмысленно. Сначала роль, потом инструменты.
Ниже — карта навыков QA без культа фреймворка: документация, ручной контур, данные, база автоматизации, грейды, два примера артефактов. Резюме — в резюме QA-инженера. Автопуть отдельно — в как стать автотестировщиком и резюме автоматизатора. Вход в профессию — в как стать QA.
Коротко:
- Ядро: понять продукт, воспроизвести, описать так, чтобы разработку не переспрашивали.
- Документация и баг-репорт — навык, не «умею Jira».
- SQL и API-проверки закрывают больше junior-вакансий, чем ранний Selenium.
- Автоматизация — слой, не замена головы. Junior не обязан тащить весь фреймворк команды.
- Сверяйте must с вакансиями QA и формулировки CV — в разборе резюме.
Что QA покупают на самом деле
Команда покупает меньше сюрпризов в проде и понятный сигнал «можно релизить / нельзя». Инструмент — способ. Если вы умеете кликать Selenium, но не отличаете баг от пожелания и не фиксируете окружение, вы дорогой шум.
На скрининге смотрят: как вы раскладываете сценарий, как пишете баг, что проверяете кроме счастливого пути, умеете ли сузить «не работает». Вопросы — в вопросах на собеседовании QA и в разборе собеседований.
Типы ролей: manual / mixed / automation / QA engineer в продукте. Не откликайтесь одним файлом на все. Смешение видно по skills из десяти фреймворков без одного сильного отчёта.
В CIS 2026 смешанные продуктовые роли всё ещё массовый вход: кабинет, регресс, SQL, API, немного авто. Чистый SDET без коммерческого кода входит сложнее, если нет артефакта. Не выбирайте путь только потому, что «автоматизация звучит круче». Выбирайте по вакансиям, на которые готовы пройти тестовое на этой неделе. Живые формулировки — в каталоге QA.
Ещё путаница: «QA» в аутсорсе на чужих заказчиках vs QA в продукте. В аутсорсе сильнее скорость кейсов и коммуникация с чужой разработкой. В продукте — знание домена и риск релиза. В резюме это разные пули. Не маскируйте трёхмесячные проекты заказчиков под «5 лет в одном продукте», если это набор коротких контуров: напишите модель, её спросят.
Ручной контур и мышление
Разбор требований: что не сказано, какие роли пользователей, какие запрещённые состояния. Эквивалентные классы и границы — рабочий навык, не билет. Регресс: что гонять всегда, что — по риску. Исследование: чартер, времябокс, заметки, не хаотичный клик.
Клиент, поддержка, логи — источники кейсов. Умение прочитать ответ API и HTML-ошибку экономит часы. Для удалёнки важен письменный статус: что проверили, что заблокировано, чем риск.
Чего нет в ядре junior: нагрузочное как отдельная профессия, security-аудиты, полное владение пайплайном DevOps. Соседние карты: backend, DevOps — чтобы понимать границы, не чтобы украсть их в CV.
Документация, баги, SQL
Чек-лист и тест-кейс: предусловие, шаги, ожидание, данные. Не роман. Баг: шаги, факт / ожидание, окружение, вложения, серьёзность без истерики. Дубли и «у меня не воспроизводится» закрываются окружением и точными шагами.
Скрин без шагов — не баг-репорт. «Ничего не работает» — не баг-репорт. «На проде, не знаю версию» — почти не баг-репорт. Навык junior в том, чтобы разработчик с первого чтения понял, куда смотреть. Если ваш отчёт вызывает три уточняющих сообщения, его ещё нельзя класть в папку-доказательство. Перепишите три лучших отчёта до состояния «можно слать без голосового» — это сильнее нового курса Postman.
SQL: выборка, джойн, понять, что в БД после действия UI. Это must смешанных junior-ролей чаще, чем UI-авто. API: Postman или аналог, статус, тело, заголовок, идемпотентный повтор. Не «коллекция из курса на 200 запросов» — 10 осмысленных.
Как класть это в резюме без «работал с Jira»: артефакты и цифры порядка (сценарии, регрессы, тип багов), см. как описать опыт и как описывать проекты.
Автоматизация: когда и сколько
База: что имеет смысл автоматизировать (стабильный регресс, API-контракт), что нет (раз в год, плавающий UI). Один язык команды. Селекторы и ожидания без sleep-магии. Отчёт, который читает не только автор.
Junior: несколько API-тестов или дымовой UI на главный сценарий плюс понимание, почему остальное ручное. Middle: слой в CI, флаки, ревью чужих тестов. Senior авто: архитектура набора, владельцы, стоимость поддержки.
Стоимость поддержки набора — аргумент, которым middle уже пользуется. «Эти 20 UI-тестов едят ночной прогон и краснеют на анимации» — решение снять их сильнее, чем «написал ещё 20». Пишите такие решения в резюме: это качество, не лень.
Не начинайте карьеру с «выучу Cypress за месяц вместо баг-репортов». Рынок смешанных ролей в CIS всё ещё кормит сильным ручным контуром плюс SQL/API. Чистый automation без головы слабо входит.
Флаки — отдельный навык middle. Тест, который красный раз в пять прогонов, хуже отсутствия теста: ему перестают верить. Умение снять его с ночного прогона и оставить ручной/API-контур — взрослая позиция, её стоит писать в CV. Не держите в skills «Selenium» как гордость, если набор флакает и его обходят.
Грейды без вишлиста
Junior: воспроизведение, аккуратный баг, чек-лист своего куска, готовность к тестовому. Коммерческий стаж не обязателен, обязателен артефакт. Без папки отчётов слово Junior в шапке не проверяется — его проверят тестовым, и пустой вход будет виден сразу.
Middle: риск-ориентированный регресс, оценка «что не успеем», общение с разработкой без эскалации каждого расхождения, свой контур в проде, кусок авто или SQL-проверок. Письменная оценка риска релиза — уже middle, даже если стек короткий.
Senior / lead: стратегия качества, процессы, люди, договор с продуктом про «достаточно», не обязательно самый длинный стек Selenium. Длинный стек без влияния на релиз — это не lead.
Титулы плавают. Смотрите задачи в каталоге QA, не слово Senior в шапке.