Полгода назад я испытал культурный шок. Всю карьеру — я QA Automation Engineer — пилил фичи в аутсорсе: стабильно, предсказуемо, местами даже комфортно. Но на январских каникулах впервые за долгое время задумался: мне скоро 30, я уверенный сеньор — а будто бы стою на месте.

Я просто включил «open to work» на LinkedIn — и неожиданно получил оффер в продукт. Пошёл на собеседование «чисто посмотреть» и остался.

Эта статья — честный разбор, как меняется работа, подход к качеству и жизнь в целом, когда уходишь из аутсорса в продукт. Без восторгов, но с фактами. Расскажу, что изменилось в процессе, что удивило, что порадовало — и почему релизы теперь не вызывают у меня тахикардию. Возможно, мой опыт поможет кому-то из вас решиться на перемены.

Онбординг и оформление

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

Всего было два собеса. Первый — с HR: рассказали о компании, команде, спросили про ожидания по деньгам. Второй — с менеджером тестирования бэка. Вова, привет! Забавно, но его статью на Хабре я читал задолго до этого разговора — не думал, что однажды он будет меня собеседовать.

Оформление — через личный кабинет. Без бумажек и беготни с паспортом. Контракт, реквизиты, всё нужное — загружается в пару кликов, и ты уже на испыталке. Все бюрократические вопросы — тоже через кабинет: возмещения за конференции, софт, обучение и прочее.

А если что-то идёт не так — можно просто написать хоть СЕО в Slack. Серьёзно. Да, дальше в статье ещё будет немного про бюрократию. Но про ту, которая не бесит. Почти.

Техническая документация ≠ бюрократия

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

Здесь всё иначе: за документацию отвечает технический писатель -  отдельный человек, и его работа не уходит в стол. Всё попадает в живую, структурированную Confluence — с заголовками, оглавлением, нормальным поиском и без архивной пыли.

Писатель — не в башне из слоновой бумаги. Он работает в связке с разработкой и тестированием: на коротких созвонах мы уточняем детали, не выпадая из потока. Благодаря этому документация получается не «для галочки», а реально полезная.

Сегодня даже ИИ помогает описывать код и тесты. Так что руками писать почти не приходится — разве что поправить формулировки. А вообще, документация — это как повторение пройденного: полезно для памяти и удобно для команды.

И да — нет ничего приятнее, чем найти свою же статью в конфле и, наконец, понять, что ты там год назад накрутил.

Обучение и внутренняя база знаний

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

У нас есть хранилище внутренних митапов — медиатека с докладами по технологиям и процессам, которые реально используются в продукте. Всё отфильтровано, без воды. Не надо тратить вечера на выбор курсов, читать отзывы, гуглить, кто из спикеров не теоретик.

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

Отдельно — про культуру QA. Она тут взрослая. В команде есть и SDET’ы, которые не просто собирают фреймворк, а делают его удобным, отлаженным, без боли и магии в debug’е. С ними ты растёшь в коде, учишься писать стабильно, без костылей и print() в проде.

Залить в репозиторий «как-нибудь» не выйдет. Любой код сначала проходит ревью у SDET’а — строгое, по делу, без лишней воды. И с этого начинается рост.

Как у нас проходят релизы

Следующее потрясение — релиз. Но не спешите морщиться: тут он не про ночные крики в прод и не про выгорание по вторникам.

Процесс выстроен, как надо. Ты дежуришь, но не ходишь по минному полю. Всё по плану, без паники.

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

За спринт (две недели) уходит максимум полтора часа. Всё. Без нервов и бессонницы.

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

А главное — никакого ручного регресса. Не нужно кликать по чеклисту два дня подряд. Автотесты работают, релиз идёт, нервы в порядке. Жизнь хороша.

Живая коммуникация

Хватит про технику — давайте про людей. Самое удивительное здесь — коммуникация действительно работает.

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

Если что-то не складывается с текущим руководителем — можно спокойно обратиться уровнем выше. Никто не делает вид, что тебя не существует. Все менеджеры доступны в Slack, а если не знаешь, кто именно твой — открываешь внутреннюю карту отделов и находишь нужного человека. Всё прозрачно.

Отдельный плюс — открытые календари. Если забыл, не позвали или просто хочешь послушать — заходишь, видишь встречу, присоединяешься. Никто не закроет дверь перед носом.

Минус? Много митов. Но это плата за распределённую структуру и десятки независимых команд. Тут как в космосе — без стыковки всё разлетится.

Есть ещё регулярные созвоны с тимлидом — и их можно настроить под себя. Хотите раз в неделю? Пожалуйста. Раз в месяц? Тоже норм. Можно обсудить задачи, пожаловаться на коммуникацию или просто выдохнуть. Особенно это спасает на онбординге — как стакан воды после трёх дней в пустыне.

Мне повезло: попал в период трансформации и общался сразу с двумя лидами. Узнал много нового и даже завёл себе секретную шпаргалку. Но её не покажу.

Влияние на продукт

Что важнее всего для тестировщика, который повидал жизнь? Для меня — это возможность реально влиять на продукт и процессы. Не просто закрывать таски, а видеть, как твои идеи что-то меняют.

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

Реальный пример из моего опыта. Я в компании около полугода, но уже успел предложить улучшение которое закрыло бизнес-необходимости. Один из наших проектов Core - большой калькулятор всей платформы, является отдельным сервисом и проверку его функций не всегда просто совмещать  с тестированием других сервисов. Так, для проверки расчета рисков для клиента, я совместил тестирование ядра и выставления ордера, за который отвечает другой сервис. Было сложно, но интересно!

В компании есть performance-бонусы, и они не только про цифры и метрики. Хочешь улучшить процесс — предлагай. Нашёл слабое место — озвучь. Есть идея — расскажи. Тут это воспринимается не как критика, а как вклад. И если для реализации нужно что-то доработать или изменить — тебе помогут.

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

Сроки и качество

Если вы дочитали до этого места — поздравляю, сейчас будет то, от чего у многих начинает подгорать. Встречайте: сроки и качество. Боль, жизнь и бессонные ночи любого QA.

Как попасть в центр между двумя крайностями? Ошибка в проде — дорого. Репутацией в первую очередь. Поэтому приоритет всегда один — качество. Не успели нормально протестировать фичу? Она просто не идёт в релиз. Да, её могут перенести, и это нормально. Никакого «давайте выкатим на стейдж, авось не бахнет».

Всё держится на планировании. Риски оцениваются заранее, под них закладывается буфер. Если идём по плану — вытаскиваем что-то из бэклога. Если нет — делаем то, что запланировано, но хорошо.

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

Релиз — только после апрува от QA. Это не рекомендация, а правило.

Как у нас планируют спринты:

• Учитывается чистое время — без дежурств, отпусков и праздников.

• Оценку даёт тот, кто будет делать задачу, и уже в теме.

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

Заключение

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

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

Что для меня оказалось важным:

• Работать без выгорания, но с высоким качеством.

• Влиять на продукт, а не просто кликать по тест-кейсам.

• Быть услышанным и реально что-то менять.

• Спокойно катить релизы — уже пять штук, и ни одного седого волоса.

• Учиться тому, с чем реально сталкиваешься в проде.

• Не заполнять бумажки и не гоняться за печатями.

Это — мой опыт. Возможно, он совпадёт с вашим. А может, даст повод задуматься. В любом случае, не бойтесь нажимать на кнопки, которые раньше обходили стороной.