Переход из QA в разработку кажется естественным: вы уже внутри продукта, видели релизы и знаете, где система ломается. На практике вакансия junior developer всё равно спрашивает другое — можете ли вы сами собрать изменение, а не только поймать чужое. Опыт теста не вычёркивают. Его нельзя оставить единственным заголовком.
Ниже — как превратить QA в фундамент, а не в ярлык «бывший тестировщик»: что переносится, какой разрыв закрыть за 90 дней и за полгода, как выглядит внутренний переход и какие пули в резюме доказывают, что вы уже пишете код, а не только собираетесь.
Коротко:
- SDLC, git, крайние случаи и знание продукта — это уже капитал. Автотесты ещё сильнее, если это ваш код, а не запись кликов.
- Разрыв — в языке, проектировании и ответственности за изменение в проде, не в «ещё одном курсе алгоритмов».
- Самый короткий путь — внутренний: багфиксы, мелкие фичи рядом с автотестами, парное ревью с разработчиком.
- Снаружи продаёт один-два репозитория с вашей логикой, тестами и честным README, а не десять сертификатов.
- Откликайтесь на junior/middle dev, где ваш домен и стек совпадают. Универсальное «хочу в разработку» не читают.
Что из QA уже считается опытом разработчика
Нанимающий junior-разработчика боится двух вещей: человек не умеет довести задачу до релиза и не понимает, как его код ударит по соседям. У QA обе страха часто слабее, чем у выпускника курсов.
- Контур поставки. Ветки, релиз, регресс, hotfix — вы уже в этом календаре.
- Крайние случаи. Пустые данные, повторный клик, таймаут, «а если пользователь сделает дважды». Это проектирование, если вы переносите его в код, а не только в баг-репорт.
- Продукт. Вы знаете, какие сценарии реально ломаются. Джун с пет-проектом этого не знает.
- Автотесты. Если вы писали код проверок, у вас уже язык, git и ревью. Если только ручной тест — капитала меньше, маршрут тот же, только 90 дней жёстче.
Не начинайте резюме с «внимательный и усидчивый». Начинайте с факта: какой код или какую тестовую обвязку вы уже поставили в пайплайн.
Чего не хватает на junior-разработке
Сверьте пять вакансий по одному стеку, не по слову developer. Обычно ждут:
- Один язык до уровня «могу сам написать сервис/экран и покрыть тестом», не «читал главу».
- Модель данных или состояние интерфейса — не только проверка чужого API.
- Умение декомпозировать задачу и оценить, что не влезет в спринт.
- Ревью: объяснить своё изменение и принять чужое без войны.
- Базовый 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 уже стыдно.
- Месяц 4. Самостоятельная декомпозиция: берёте задачу без пошагового ТЗ, сами уточняете крайние случаи, сами режете объём.
- Месяц 5. Тесты как часть работы, не как «потом QA проверит». Для backend — модульные и контракт на API. Для frontend — логика состояния и критический сценарий.
- Месяц 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.