Переход из QA в разработку кажется естественным: вы уже внутри продукта, видели релизы и знаете, где система ломается. На практике вакансия junior developer всё равно спрашивает другое — можете ли вы сами собрать изменение, а не только поймать чужое. Опыт теста не вычёркивают. Его нельзя оставить единственным заголовком.

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

Коротко:

  • SDLC, git, крайние случаи и знание продукта — это уже капитал. Автотесты ещё сильнее, если это ваш код, а не запись кликов.
  • Разрыв — в языке, проектировании и ответственности за изменение в проде, не в «ещё одном курсе алгоритмов».
  • Самый короткий путь — внутренний: багфиксы, мелкие фичи рядом с автотестами, парное ревью с разработчиком.
  • Снаружи продаёт один-два репозитория с вашей логикой, тестами и честным README, а не десять сертификатов.
  • Откликайтесь на junior/middle dev, где ваш домен и стек совпадают. Универсальное «хочу в разработку» не читают.

Что из QA уже считается опытом разработчика

Нанимающий junior-разработчика боится двух вещей: человек не умеет довести задачу до релиза и не понимает, как его код ударит по соседям. У QA обе страха часто слабее, чем у выпускника курсов.

  • Контур поставки. Ветки, релиз, регресс, hotfix — вы уже в этом календаре.
  • Крайние случаи. Пустые данные, повторный клик, таймаут, «а если пользователь сделает дважды». Это проектирование, если вы переносите его в код, а не только в баг-репорт.
  • Продукт. Вы знаете, какие сценарии реально ломаются. Джун с пет-проектом этого не знает.
  • Автотесты. Если вы писали код проверок, у вас уже язык, git и ревью. Если только ручной тест — капитала меньше, маршрут тот же, только 90 дней жёстче.

Не начинайте резюме с «внимательный и усидчивый». Начинайте с факта: какой код или какую тестовую обвязку вы уже поставили в пайплайн.

Чего не хватает на junior-разработке

Сверьте пять вакансий по одному стеку, не по слову developer. Обычно ждут:

  1. Один язык до уровня «могу сам написать сервис/экран и покрыть тестом», не «читал главу».
  2. Модель данных или состояние интерфейса — не только проверка чужого API.
  3. Умение декомпозировать задачу и оценить, что не влезет в спринт.
  4. Ревью: объяснить своё изменение и принять чужое без войны.
  5. Базовый git-поток: ветка, PR, конфликт, откат.

Алгоритмы на собеседовании бывают. Для перехода важнее живой кусок продукта, чем полгода LeetCode без репозитория. Подтянете структуры данных точечно под формат компаний, куда идёте — не вместо кода.

План на 90 дней

Цель квартала: одно изменение в проде или максимально близко к нему плюс один собственный сервис/экран со стеком целевой роли. Пока оба пункта пустые, рынок видит QA, который «хочет попробовать».

Дни 1–30. Язык и свой контур.

  • Выберите один язык вакансий, на которые пойдёте: тот, на котором уже пишете автотесты, или тот, на котором пишут вашу команду разработки.
  • Каждый день — маленькая задача: функция, обработчик, компонент. Не курс «с нуля», если автотесты уже на этом языке.
  • Заведите репозиторий учебного сервиса: одна сущность, CRUD или один пользовательский сценарий, тесты, README.

Дни 31–60. Багфиксы и чужой код.

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

Дни 61–90. Фича, не только баг.

  • Одна небольшая фича целиком: постановка → код → тесты → регресс вашего контура → выкладка или стенд.
  • Добавьте в учебный проект то, чего стыдно не уметь на junior-созвоне: ошибки, логирование, простой auth или очередь — по роли.
  • Черновик резюме с пулями перехода. Заголовок уже не «QA engineer», а «Junior backend / frontend (ex-QA)».

План на полгода

Второй квартал нужен, чтобы вас перестали звать «тестировщиком, который кодит». Закрываете ширину, без которой middle-dev ещё рано, а junior-dev уже стыдно.

  1. Месяц 4. Самостоятельная декомпозиция: берёте задачу без пошагового ТЗ, сами уточняете крайние случаи, сами режете объём.
  2. Месяц 5. Тесты как часть работы, не как «потом QA проверит». Для backend — модульные и контракт на API. Для frontend — логика состояния и критический сценарий.
  3. Месяц 6. Одна зона в продукте, за которую вас можно спросить: платежи, кабинет, импорт, отчёты. Глубина важнее второго фреймворка.

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

Внутренний переход: как договориться

Компании чаще соглашаются, когда вы не просите «переведите меня завтра», а предлагаете смешанный квартал. Шаблон разговора:

Хочу за 90 дней закрыть переход в разработку без дыры в поставке теста. Предлагаю: 60% времени — текущий QA-контур, 40% — багфиксы и одна фича в паре с разработчиком. Критерий успеха: N смерженных PR в прод (или на стенд) и одна зона, которую я веду сам. Если через 90 дней команда не готова взять меня как junior-dev — фиксируем, каких навыков не хватило, и я не тяну процесс бесконечно.

Принесите список багов, которые вы уже можете закрыть кодом. Абстрактное «хочу расти» руководитель не может защитить перед своим руководителем.

Если ответа нет два цикла планирования — это ответ. Тогда внешний рынок и честный заголовок. Как искать IT-роль без распыления: как найти работу в IT.

Пет-проект и тестовое

Один основной репозиторий. Для backend: API, база, миграции, тесты, docker-compose, что не сделано. Для frontend: кабинет или сценарий, состояние, обработка ошибок, как запустить. Не «интернет-магазин на все сущности».

Автотесты продукта можно показать как код, если это ваш код и его можно открыть без клиентских данных. Скрин отчёта Allure без репозитория почти ничего не даёт.

На тестовом задании вас будут ловить на спешке и на игноре крайних случаев. Бывший QA здесь в плюсе, если не забывает тесты и не обещает космос за выходные. Как не провалить объём: тестовое задание на работу.

Пример: automation QA → junior backend

Стек команды: Python, Django, Postgres. Кандидат год пишет API-тесты на pytest, руками почти не тестирует.

90 дней. Переписал три хрупких теста на фикстуры и контракт. Закрыл четыре бага в обработке ошибок импорта CSV — правки в том же сервисе, который тестировал. Учебный сервис: загрузка файла, валидация строк, запись в Postgres, тесты на пустой файл и дубликат. README: как поднять, что не сделано (очередь, ретраи).

Разговор с лидом: 40% времени на багфиксы импорта, цель — junior backend в этой зоне. Пули в резюме уже про код сервиса, не про «составлял тест-кейсы».

Ручной QA без кода идёт тем же маршрутом, только первый месяц — язык и учебный сервис, а багфиксы просит позже. Не прыгайте сразу в «fullstack на всё». Сначала одна сторона: backend, frontend или fullstack.

Неделя вперемешку: тест не должен умереть в первый же спринт

Частая ошибка внутреннего перехода — бросить регресс, пока фича ещё не идёт. Команда запоминает дыру, а не ваш git. Держите явную границу.

Понедельник: регресс своего контура как раньше, без «сегодня только код». Вторник-среда: багфикс или кусок фичи, PR с тестами и с тем, как проверить руками. Четверг: ревью чужого dev-PR с фокусом на края — ваш козырь. Пятница: учебный сервис (если внутреннего кода мало) или закрытие замечаний. В статусе пишите оба потока, чтобы не казалось, что QA «пропал».

Если смешанный график не дают, не копите обиду полгода. Зафиксируйте отказ и усиливаете внешний артефакт. На рынке ваш QA не минус, если первые пули — код. Минус — резюме, где десять лет тест-кейсов и внизу «также знаю Python». Переставьте сюжет.

Для внешней воронки заложите ещё 4–6 недель на формат отбора: живой кодинг, разбор учебного сервиса, тестовое. Не учите алгоритмы вместо репозитория, но и не идите на backend-интервью, ни разу не написав функцию вслух. Один вечер в неделю — маленькая задача с проговариванием. Вопросы к интервью: вопросы на собеседовании. Тестовое не раздувайте до бесплатной фичи: рамка тестового.

Резюме: заголовок и пули перехода

Плохо: «QA engineer. Хочу развиваться в разработке». Хорошо: «Junior backend (Python), ранее QA: автотесты и багфиксы импорта».

Пули, которые доказывают переход:

  • Закрыл 6 багов в сервисе импорта (валидация, пустой файл, дубликаты): правки в проде, покрытие тестами, регресс своего контура.
  • Перевёл API-проверки с UI-записи на pytest + контракт: стабильность пайплайна, падения ловятся до релиза, а не после.
  • Собрал учебный сервис загрузки файлов: API, Postgres, тесты крайних случаев, docker-compose, ссылка на репозиторий.
  • Декомпозировал фичу «экспорт отчёта»: оценка, риски по таймауту и объёму, что вырезали из первой версии.
  • Ревью PR разработки: поймал необработанный 404 и гонку на повторный запрос — до прода, не баг-репортом после.

Пули «написал 200 тест-кейсов» оставляйте только если идёте ещё и на QA. Для dev-ролей они шумят. Каркас файла: как составить резюме, формулировки навыков: навыки в IT-резюме. Прогон верха: разбор резюме.

Как отвечать на «зачем уходите из QA»

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

Не унижайте QA. Нанимающий часто сам вырос из теста. Уничтожение своего бэкграунда выглядит как дыра в суждении, не как амбиция.

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

Automation QA уже разработчик?

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

Берут ли сразу на middle-dev после пяти лет QA?

Редко, если в коде не было ответственности за прод. Чаще junior/middle с оговоркой по домену. Честнее войти на junior-dev в знакомом продукте, чем спорить с грейдом на бумаге.

Нужно ли бросать тест в резюме?

Нет. Нужно перестать делать его единственным сюжетом. Первые пули — код и поставка. QA — контекст.

Стоит ли идти в SDET вместо «чистого» dev?

Если вам ближе инфраструктура проверок и пайплайн — да, это отдельная роль, не утешение. Если хотите продуктовый код — не застревайте в SDET «на всякий случай»: рынок прочитает это как отказ выбрать.

Что делать, если внутренний переход запрещён политикой?

Соберите артефакты и идите наружу. Стажировка в разработке имеет смысл только как программа, не как бесплатный junior. Рамка: стажировка в IT. Вход без сильного коммерческого кода: как найти работу без опыта — те же правила доказательств, только у вас уже домен.

Какой стек выбрать, если команда на одном, а вакансии на другом?

Сначала стек, на котором можете смержить PR в ближайшие 90 дней. Смена языка с нуля удлиняет переход. Рынок смотрите по junior-вакансиям того языка, на котором уже есть код.

Что сделать сейчас

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

Перепишите заголовок и четыре пули под разработку и откликнитесь на пять вакансий, где задачи совпадают с вашей зоной. Смотреть вход удобно в каталоге junior-ролей, не в ленте «IT-специалист». Письмо к отклику — короткое, с ссылкой на PR или репозиторий, по формуле письма без опыта: факт, не извинение за QA.