careerqa-thinking

Junior → Middle → Senior QA: реальные сигналы роста на каждом уровне

Половина QA-инженеров застревает между уровнями на 1–2 года. Не потому что мало знают — потому что не понимают, чего от них ждут на следующей ступени. Менеджер не видит «5 лет опыта» в CV — он видит, как вы себя ведёте.

Уровень — это не годы и не должность в job title. Это набор поведений и зона ответственности, которую человек реально берёт. Ниже — разбор по уровням: что ждут, чего НЕ ждут, по каким сигналам менеджер понимает, что вы готовы к следующему шагу.

Что меняется при росте

Логика простая. С каждым уровнем расширяются четыре оси: scope, autonomy, impact, communication.

  • Junior — исполнитель. Выполняет задачи, которые дали, под контролем.
  • Middle — владелец. Берёт ответственность за фичу/модуль/направление целиком.
  • Senior — стратег. Влияет на процессы, культуру и команду за пределами своих задач.

Если вы знаете в 10 раз больше джуна, но делаете ровно то, что попросили — вы джун в системе координат менеджера. Знания без расширения scope не двигают карьеру.

🌱 Junior QA — первые 6–12 месяцев

Что реально ожидают

  • Аккуратно выполнять тест-кейсы и план тестирования, который вам дали.
  • Писать понятные баг-репорты: steps to reproduce, expected, actual, окружение, артефакты (скриншот/видео/лог).
  • Знать основы: типы тестирования, тест-дизайн (эквивалентные классы, граничные значения), bug life cycle, severity vs priority.
  • Базовое владение инструментами стека: DevTools для веба, Charles/Proxyman для мобайла, Postman для API.
  • Не бояться задавать вопросы PM, разработчикам, дизайнерам. Молчание из «неудобно спросить» — главный антипаттерн джуна.
  • Изучать продукт и процессы команды: как идёт релиз, кто что делает, где документация.

Что НЕ ожидают

  • Знание Selenium/Playwright «как у сениоров».
  • Самостоятельную оценку сложных задач.
  • Архитектурные решения по тест-инфраструктуре.
  • Понимание всей системы.

Сигналы готовности к Middle

  • Берёт небольшую фичу целиком — от изучения требований до подписания релиза, без постоянного контроля.
  • Замечает странное за пределами задачи: «эта кнопка не сломана, но я заметил, что соседняя ведёт себя странно».
  • Не нужно объяснять одно и то же дважды.
  • Помогает новым джунам разобраться.
  • Стабильно даёт оценки по времени, которые сходятся ± с реальностью.

🌿 Middle QA — точка перегиба

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

Что реально ожидают

  • Ownership — фича/модуль/направление ваше. От анализа требований до пост-релизного мониторинга.
  • Тест-стратегия — самостоятельно решаете, как тестировать. Что важно покрыть, что нет, где автоматизировать, где оставить мануалкой.
  • Risk assessment — переводите «нашёл баг» в «вот риск для пользователя/бизнеса, severity такая-то потому что…».
  • Чините процесс — флэйки тесты, медленный CI, неудобный баг-трекинг. Не ждёте, пока кто-то это сделает за вас.
  • Менторите джунов — учите не «что нажать», а «как думать».
  • Можете сказать «не выкатывайте» и аргументировать. Это про навык конструктивного no, а не про вредность.
  • Понимаете связи модулей — что сломается в соседней системе, если поменяли тут.

Антипаттерны middle

  • Делает только то, что попросили. Идеальный исполнитель, но не владелец.
  • Сообщает баги в формате «вот баг», а не «вот риск». Разница огромная: первый кейс — нашёл, второй — помог принять решение.
  • Не лезет в процессы. «Это не моя зона ответственности» — фраза джуна.
  • Знает свою фичу хорошо, всё остальное — «ну, не моё».

Сигналы готовности к Senior

  • Влияет за пределами своей фичи: коллеги советуются по тестовой стратегии.
  • Bridges QA-PM-Dev — может сесть с продактом и разработчиком и привести разговор к решению.
  • Видит системные проблемы, а не их симптомы.
  • Поднимает темы, которые улучшают команду в целом — метрики качества, ритуалы, инструменты.
  • Может вести инициативу, которая не из его фичи.

🌳 Senior QA — стратегический уровень

Senior — это не «очень опытный middle с большей зарплатой». Это другая роль. Если вы продолжаете тестировать руками 80% времени и брать всё больше тех же задач — вы дорогой middle, а не senior.

Что реально ожидают

  • Стратегия качества для продукта/направления. Какие риски, как закрываем, какие метрики измеряем.
  • Влияние на инжиниринг-культуру — testability в коде, ownership разработчиков за качество, культура pre-merge тестирования.
  • Снижение ToIL — автоматизация рутины, инструменты, шаблоны. Не «я могу сделать это руками быстро», а «как сделать, чтобы это вообще не делали руками».
  • Mentoring и рост команды — наставничество, ревью тест-планов, training. Поднимаете уровень всех вокруг.
  • Amorphous problems — задачи вида «качество мобильного билда деградирует, разберись». Senior умеет распаковать такое в план.
  • Связь с бизнесом — понимаете unit economics, retention, churn. Тестируете не «всё», а то, что важно для денег.
  • Hiring — собеседуете, влияете на найм, поднимаете планку команды.
  • T-shaped — глубина в одном-двух доменах, ширина по остальным.

Антипаттерны senior

  • Senior как «очень опытный middle» — больше задач, та же роль. Самый частый случай.
  • Senior, который «сидит на тестах» и не отдаёт их джунам/мидлам. Боится отпустить контроль.
  • Senior-одиночка — эксперт без влияния на команду. Знает много, но команда не растёт.
  • Делает за всех. Героизм вместо системного улучшения.

🎯 Сигналы готовности к следующему уровню

Что видит менеджер на каждом переходе:

Junior → Middle

  • Завершает фичу без постоянного контроля.
  • Spots issues out-of-scope.
  • Стабильно даёт оценки, которые сходятся с реальностью.
  • Помогает новичкам.

Middle → Senior

  • К нему/ней приходят за советом.
  • Поднимает темы, которые улучшают команду (метрики, ритуалы, инструменты).
  • Может вести инициативу не из своей фичи.
  • Самостоятельно идентифицирует системные риски.

Senior → Staff/Lead/Principal

  • Влияет на org-level — практики, найм, стратегия качества организации.
  • Может выйти в отпуск на месяц — и качество не падает.
  • Cross-team влияние, не только внутри своей команды.

🪤 6 антипаттернов роста

  1. «5 лет опыта = 1 год × 5». Повторяете те же задачи годами, меняется только календарь. Лекарство: каждые 6–12 месяцев брать что-то новое — мобайл, если веб; перформанс, если только функционал; автоматизация, если только мануалка.
  2. Ниша-капкан. «Я делаю только регресс». Senior должен быть T-shaped — глубоко в одном, широко в остальном. Узкая ниша ограничивает рост.
  3. Перфекционизм. Застревание на 100% coverage вместо 80% того, что реально важно. Хорошо vs. идеально — в QA это особенно больно, потому что «можно ещё чуть-чуть лучше» всегда есть.
  4. Тихая работа. Никто не знает, что вы сделали. Sharing — не самореклама, а часть работы senior. Если ваша работа не видна — её как будто нет.
  5. Избегание сложных разговоров. «Разработчик не хочет фиксить», «PM торопит релиз». На каждом следующем уровне таких разговоров будет больше, не меньше. Учитесь сейчас.
  6. Job-title chasing. Менять компанию каждые 9 месяцев ради +1 в job title. Получите senior по табличке, но не по сути. Рынок это видит и проверяет на собеседованиях.

✅ Чек-лист самооценки

Берёте, отмечаете честно. Не «я могу при необходимости», а «я регулярно это делаю».

Junior

  • Я могу взять простую фичу и протестировать без помощи.
  • Мой баг-репорт не возвращают с вопросом «что воспроизводить?».
  • Я знаю, как открыть DevTools / Charles / Postman, и понимаю, что вижу.
  • Я задаю вопросы PM и не считаю это слабостью.
  • Я понимаю, как наша CI собирает и катит релиз.

Middle

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

Senior

  • Команда советуется со мной по стратегии тестирования.
  • Я понимаю бизнес-метрики продукта и могу связать с ними своё тестирование.
  • Я могу провести собеседование на любой уровень QA.
  • Я ввёл или изменил минимум одну практику в команде.
  • Если я уйду в отпуск на месяц — качество не упадёт.

💬 Как обсуждать рост на 1-1

Что НЕ работает

  • «Когда меня повысят?»
  • «Я устал, дайте больше денег.»
  • «Маше повысили зарплату, а мне нет.»
  • «Я давно работаю, пора бы.»

Это разговор про эмоции и зарплату, а не про рост. Менеджер либо уходит в защиту, либо обещает «посмотреть», и ничего не меняется.

Что работает

  • «Я хочу вырасти до middle/senior. По вашему мнению — каких 2–3 навыков мне не хватает?»
  • «Можно мне взять X как стрейч-задачу — я хочу попробовать себя в Y.»
  • «Я последние 6 месяцев делаю [конкретные вещи уровнем выше]. Хочу обсудить, как это формализовать.»
  • «Какие сигналы вы ждёте увидеть, чтобы рекомендовать меня на следующий уровень?»

Регулярные вопросы (раз в квартал)

  • Что я делал на следующем уровне в этом квартале?
  • Что мне мешает делать больше?
  • Где я могу взять стрейч-проект?
  • Какие у меня слепые зоны, которые я сам не вижу?

Эти разговоры — это не «выпрашивание». Это нормальная часть работы менеджера. Хороший менеджер сам их инициирует. Если ваш не инициирует — инициируйте вы.

Заключение

Уровень — это поведение и зона ответственности, которые вы реально берёте, а не годы в CV и не должность в job title. Менеджер видит уровень по тому, что вы делаете каждый день, а не по тому, что написано в офере.

Чем раньше вы понимаете, что от вас ждут на следующей ступени, — тем быстрее туда попадаете. Часто разница между middle и senior — это не «ещё два года опыта», а одно решение: перестать ждать, что вам дадут роль, и начать вести себя так, как ведёт себя человек на этой роли. Менеджер заметит — и формализует.