Алексей пришёл в IT из сферы дорожной безопасности и за несколько месяцев прошёл путь от новичка до уверенного QA-инженера. Сегодня он работает в крупной IT-аккредитованной компании на полной удаленке, где коллеги и руководство отмечают его внимательность, инициативу и умение выстраивать коммуникацию в команде. В интервью Алексей рассказал, как учился, искал первую работу и почему тестирование стало для него делом души.
Артём:
Так, ребят, всем привет! Сегодня у нас очередная встреча с выпускником. Сегодня у нас в гостях Лёха, Алексей — наш ученик, который уже прошёл испытательный срок. Сейчас он расскажет, как у него всё сложилось. Лёх, привет! Очень рад тебя видеть
Алексей:
Привет! Взаимно, рад всех видеть, готов поделиться и рассказать, чем смогу.
Артём:
Как настроение, нормальное?
Алексей:
Да, хорошее. Немного волнуюсь, давно не разговаривал на публику.
Артём:
Да тут все свои, можно расслабиться. Окей, давай начнём, как обычно, с самого начала. Расскажи, как ты вообще пришёл в эту сферу и чем занимался до этого.
Алексей:
Я пришёл в IT, потому что сейчас эта сфера бурно развивается. Всё растёт очень быстрыми темпами, появляются новые идеи, и всё крутится вокруг технологий. Здесь большие перспективы — и по росту, и по саморазвитию, и по знаниям. До перехода в QA я работал в сфере безопасности дорожного движения, специалистом по сопровождению стационарных комплексов фото- и видеофиксации нарушений.
Артём:
То есть ты занимался чем-то вроде координации, менеджментом?
Алексей:
Да, всё верно. Это была больше координационная работа: сопровождение комплексов после установки, поддержка, мониторинг их работы. Если не вдаваться в детали — так, коротко. Конечно, там много нюансов, но это уже совсем узко, вряд ли кому интересно.
Артём:
Понял. То есть до нашей школы ты нигде в IT не учился?
Алексей:
Нет, не учился.
Артём:
Хорошо. И как тебе вообще далась учёба? Как шло обучение, легко ли было?
Алексей:
Ну, на самом деле, учеба далась непросто. Было тяжело перестроить мозг на другой лад, потому что всё-таки QA — это человек, который видит продукт с самого начала и до самого конца: от анализа требований до сопровождения и поддержки.
Нужно было развить внимательность, дотошность, научиться смотреть на всё под другим углом. Большинство пользователей просто пользуются продуктом, а тестировщик должен видеть, как он устроен изнутри. Вот перестроиться на это мышление было сложнее всего. Но потом, в процессе обучения, стало легче. Материал был очень подробно подан — без “воды”, всё чётко структурировано: только самое нужное и важное.
Артём:
Окей. А по времени сколько у тебя заняла учёба? Как ты занимался — каждый день или через день?
Алексей:
Я занимался примерно один-два раза в неделю, в основном по выходным. Весь курс у меня растянулся где-то на полгода. Я шёл спокойно, не торопясь, стараясь вникнуть во всё, что проходили. Конечно, были трудности, но помогали менторы — особенно ты, кстати, как наш ментор, очень хорошо помогал, когда были проблемы. В общем и целом, шесть месяцев ушло на всё обучение.
Артём:
Хорошо. А какой спринт тебе запомнился больше всего — любимый или, может, наоборот, самый сложный?
Алексей:
Самый тяжёлый для меня — это спринт по SQL. Очень интересный, но непростой, если не понимать принцип его работы. Тут важно именно понять, как SQL устроен, а не просто выучить команды. Когда понял, всё пошло как по маслу. Осознал я это уже во время прохождения собеседований — и это на самом деле мне очень помогло. Так что, наверное, это мой нелюбимый и тяжелый для меня спринт.
Артём:
А любимый какой?
Алексей:
Любимый — это, конечно, спринт с Postman. Классный инструмент, с ним интересно работать.
Артём:
Мы вчера как раз на тире с ребятами SQL-задачи решали, было весело. Ну, понял, супер. Ты ведь активно посещал созвоны и тиры, насколько я помню, да?
Алексей:
Да, тир я посещал очень активно — особенно когда вышел на рынок. Ходил почти каждый день: повторял материал, закреплял то, что прошли, и разбирал интересные вопросы, которые попадались на собеседованиях. Хотел обсудить их с ребятами, услышать разные мнения. Поэтому тиры я не пропускал — считаю, это очень важный этап обучения, особенно перед выходом на рынок. Без них успешное прохождение техсобесов было бы гораздо сложнее.
Артём:
Да, без этого, конечно, тяжело. Окей. А можешь вспомнить какие-то трудности во время учёбы? Или всё шло спокойно, планово?
Алексей:
Есть одна история, запомнилась до сих пор. Кажется, это был третий спринт — там, где баг-репорты, чек-листы, тест-кейсы. Было задание: к одной задаче придумать три уточняющих вопроса. Я тогда был в деревне, сел вечером делать. Думаю: «Сейчас быстро напишу». В итоге просидел над этим часов пять или шесть! Сижу, уже 11 вечера или 12, жена приходит: «Ты спать собираешься?» А я только тогда понял, сколько времени прошло. Вот это был реально запоминающийся момент — полностью ушёл в процесс.
Артём:
Ну круто, круто. Окей, спасибо. Тогда перейдем ближе к собесам. Ты прошёл все спринты, сдал домашки, и вот началась подготовка к выходу на рынок. Вот ты всё подготовил, вышел на рынок. Расскажи, как у тебя шли собесы. Насколько помню, не всё быстро получилось?
Алексей:
Поиск оффера у меня занял около трёх месяцев. Это был довольно долгий процесс. За это время я прошёл примерно 13 технических собеседований и где-то около 20 скринингов. В день откликался на 25–30 вакансий, иногда меньше — просто потому, что подходящие заканчивались.
Артём:
Помнишь свое первое собеседование? Или, может, какое-то, которое особенно запомнилось?
Алексей:
Да, конечно! Первое техническое собеседование у меня было, если не ошибаюсь, в ***. И там QA просто меня задушил вопросами — такой, знаете, классический “душнила”. Он сразу говорит: “Вот тебе JSON”, — открывает экран и: “Смотри, найди ошибки”. Я нахожу несколько, он кивает и спрашивает: “А скобки посчитал?”. Он говорит: “JSON невалидный, тут 25 скобок должно быть, а у тебя 23.” А потом я в начале собеседования честно сказал, что с SQL пока не очень дружу, могу разве что простенький запрос написать. И он мне, конечно, сразу дал задачу на JOIN. Я говорю: “Слушайте, не смогу сейчас сходу придумать запрос.” А он: “Ну, вы же сами сказали, что у вас слабый SQL.” И вот так, знаете, прямо сверху вниз — “давай, рассказывай, что знаешь!”. Для первого собеса — стресс колоссальный. Я тогда сидел в шоке.
Зато потом, ближе к концу, был собес у меня был в *** — там я, наоборот, сам “задушил” лида вопросами. Это был мой последний собес перед тем, как я получил оффер от текущей компании. И ещё я обратил внимание, что у них QA подключается только на этапе тестирования, а не в начале цикла разработки. Я сказал прямо: “Это плохая практика. Если тестировщик не участвует в процессе с самого начала, то потом можно легко упустить что-то важное и задержать релиз.” Я эту идею до сих пор везде продвигаю — и на своём проекте тоже.
Артём:
Это было, получается, сколько? Полгода назад?
Алексей:
Нет, четыре месяца назад.
Артём:
А, да, точно — четыре. Кстати, интересно: у тебя тогда было 13 технических собесов, и это всего четыре месяца назад. Сейчас, кажется, рынок уже немного изменился — не так активно, как раньше. Не уверен, что сейчас у кого-то набирается по 12–13 собеседований. По 5–6 — ещё да, но 13 — это, конечно, плотненько. Ну, ничего, такие циклы всегда бывают. Так, получается, собес с *** был одним из последних. И в итоге там — отказ, да?
Алексей:
Разумеется. К тому моменту мне уже прислали оффер из компании, где я сейчас работаю — на отличных условиях и очень приятную сумму. Я написал им, что, мол, жду ответ, а они сказали — “вернемся на следующей неделе”. Но неделя уже подходила к концу, и я уточнил: “Ответьте, пожалуйста, чтобы я мог принять решение”. Хотя, если честно, я уже знал, что туда не пойду — просто хотелось поставить точку. В итоге часа через два они написали: “Извините, но мы выбрали другого кандидата.” Классическая отписка.
Артём:
Да, стандартная история. Хорошо. Расскажи про оффер, который ты в итоге принял — без конкретных цифр, просто по условиям. Это удаленка?
Алексей:
Да, полная удаленка. Причём не только по России — можно работать из любой точки мира. Нет фиксированного графика “с девяти до шести”. Каждый выбирает удобное время: кто-то работает с восьми до пяти, кто-то с десяти до семи. Главное — предупредить коллег, чтобы все понимали, в какие часы ты онлайн и можно планировать совместную работу. Компания предоставляет оборудование — корпоративный ноутбук, мощный, с отличным экраном и железом. Если работаешь из офиса, за тобой закрепляют рабочее место. И офис, кстати, шикарный: кухня с кофемашинами, закусками, даже корзинка с коньяком на “тяжёлый день” стоит — не шучу! Есть небольшой спортзал, чтобы размяться. А ещё в офисе есть массажист. Можно записаться и прямо в рабочее время сходить на массаж.
Артём:
А ты уже пользовался?
Алексей:
Нет, я в офис не хожу. Но если бы ходил, обязательно воспользовался бы, прям на 200%.
Артём:
Я понял, ну круто, да. А у тебя, кстати, СБ была?
Алексей:
СБ не было. Мы просто заполняли анкету для неё. Сказали, что это чистая формальность.
Артём:
А ты же ведь работал параллельно, когда проходил собеседования, верно?
Алексей:
Да, да. И, собственно, из-за этого всё немного затянулось. Работа у меня была очень объемная, тяжелая, и совмещать ее с подготовкой к собеседованиям было сложно. После рабочего дня ты уже выжат, а на собесе нужно быть собранным, думать, отвечать — это тоже выматывает. Если планируешь интервью на вечер, то уже никакой — два слова связать тяжело. Поэтому я тогда работал на удаленке, старался ставить собеседования на утро — часов на 11, 12, максимум на час дня. Так легче: голова свежая, не уставший. Плюс успеваешь пробежаться по материалам, освежить всё, что уже учил. Иногда даже делал шпаргалки — выписывал несколько ключевых слов, чтобы во время собеса легче вспоминать нужные темы.
Артём:
Ну да, шпаргалки можно — я тоже раньше пользовался. Окей, получается, ты получил оффер, тебе дали две недели на отработку?
Алексей:
Да, всё верно. Две недели отработал, в пятницу забрал трудовую книжку с прошлого места, а уже в понедельник вышел на новое и оформился.
Артём:
Круто, круто. Всё официально у тебя, всё чётко.
Алексей:
Да, абсолютно всё официально. И, кстати, наша компания аккредитована как IT-компания.
Артём:
Угу, то есть ипотеку уже взял или скоро возьмешь?
Алексей:
Ну, пока этим ещё не пахнет, но, возможно, в перспективе воспользуюсь такой привилегией.
Артём:
Окей, понял. Давай тогда про проект. Это, на самом деле, самое интересное — думаю, и для ребят тоже. Расскажи про проект, про команду, процессы, особенно про первые дни: как тебя приняли, чем занимался. Потому что у всех всё по-разному — у кого-то месяц доступы выдают, у кого-то помощи никакой, всё по-разному. Как это у тебя было?
Алексей:
Когда я только пришёл, мне сказали: “У тебя будет онбординг, недели две”.
Артём:
Это на собесе сказали?
Алексей:
Да, на собеседовании. Но я сразу понял — кто-то что-то недоговаривает. В итоге прихожу на проект — и никакого онбординга нет. Вообще. Ни методичек, ни вводных, ничего. Просто: вот тебе документация, вот требования, вот бизнес-постановки, вот тебе таск-трекер с задачами и описанными API-контрактами — садись, разбирайся. Я сижу и думаю: “А с чего вообще начать?” Проект новый, требования еще меняются, документация дописывается на ходу, ничего окончательно не утверждено. И вот ты сидишь, смотришь на всё это и пытаешься понять, как вообще в голове всё это собрать. Был жёсткий стресс. Выручил тот факт, что в команде был еще один QA, который пришел на несколько недель раньше меня. Мы пообщались, и он начал меня погружать в проект — объяснил, какие инструменты использовать для тестирования, какие сервисы у нас в работе, где что лежит. Он мне очень помог. Ну, пришлось разбираться. Естественно, я замучил всех разработчиков вопросами по работе с сервисами — чтобы вообще понять, что к чему. С каждым лично созванивался — начиная от Project Manager и заканчивая нашим QA — чтобы познакомиться и понять, кто чем занимается.
Артём:
Лично ты имеешь в виду онлайн?
Алексей:
Да, всё верно. Потом потихоньку пошло: начал изучать техническую документацию, бизнес-постановки, вникать. И параллельно начал гулять по самому проекту — нашёл там столько багов, что просто устал их описывать. Мы со вторым QA вдвоём сидели и всё фиксировали. До этого он этим особо не занимался, а тут втянулся вместе со мной. Проект у нас был новый, регресса не было вообще, тестовой документации — ноль. Лид сказал на одном из созвонов: “Ребят, нужно написать техническую документацию. Всё, что видите — фиксируйте и документируйте.” Я спрашиваю: “А эталон будет, как писать правильно? Чтобы потом не сказали — вроде красиво, но не по стандарту?”. Он отвечает: “Зайдите в другой проект, посмотрите там кейсы, доступ есть.”. Ну, мы посмотрели — и всё равно написали по-своему. Лид потом посмотрел и говорит: “Нормально, в принципе, всё.” Я говорю: “Мы сделали, как нам удобно. Мы между собой всё понимаем, если кто-то новый придёт — спокойно его погрузим.” Главное, что всё описано четко и понятно. Сам проект построен на микросервисной архитектуре. Используется REST API. Бэкенд пишется на Python, фронтенд — на JavaScript. Когда я пришел, было где-то 7–8 сервисов, сейчас — уже 21.
Артём:
Нормально, разрослись.
Алексей:
Да, да. У нас используются такие технологии, как Kafka, Redis, PostgreSQL, Elasticsearch — это такая мощная поисковая система. Плюс Kibana, Kubernetes, контейнеры с образами — всё по классике. Может, что-то ещё упускаю, но в потоке информации уже не всё вспомню.
Артём:
А как быстро тебе дали первую задачу после прихода на проект?
Алексей:
Через четыре дня, в пятницу, сказали: “Давай, бери задачку.” Я сижу и думаю: “Что-то быстро…”
Артём:
Помнишь, что это была за задача?
Алексей:
Честно, уже нет. Сейчас у нас был большой релиз, я весь в нём закопался, всё подзабыл.Помню только, что первая задача была простенькая, фронтовая.
Артём:
А у тебя больше фронт или бэк? С чем работаешь чаще?
Алексей:
Со всем — примерно 50 на 50. Мне самому интересно и там, и там. Поскольку проект микросервисный, очень важно понимать структуру всей системы — как всё между собой связано. QA должен знать, как всё работает, чтобы находить уязвимые места. Например, где одно изменение может повлиять на другой сервис. А во фронте мне просто интересно экспериментировать. Я даже свои идеи предлагал.
Вот одна из них: если пользователь заполнил форму (даже просто поставил точку) и случайно захочет закрыть страницу — должно появляться окно с предупреждением. Project Manager сказал: “Хорошая идея”. Я позвонил аналитику, рассказал, что хочу реализовать.Она говорит: “Да, опишу”. В итоге задача была создана, PM её согласовал, взяли в разработку, я потом сам же её и тестировал.
Артём:
Ну прикольно. Классный пейс.
Алексей:
Это как раз один из моментов, когда по каким-то фронтенд-штукам можно привнести свои идеи. Но когда я предлагал идею, я всегда подкреплял её фактами с других проектов. Но, конечно, поначалу с взаимодействием в команде было сложно. Все люди новые, друг друга не знают, все сидят на удаленке — кто в разных городах, кто за границей. Коммуникация была нарушена: команда только-только собралась, и каждый работал, как говорится, в своём углу. Из-за этого часто не хватало общения при решении задач. Например, фронт хотел подтянуть данные с бэка, писал запрос — а он неправильно сформирован. В payload-е передается неправильное значение, бэк его просто не может прочитать. А контракта в тот момент либо не было, либо он был плохо описан. И вместо того, чтобы просто созвониться и договориться, как правильно, все тянули это до дейлика. Из-за этого дейлики растягивались с 15 минут до полутора часов. Я сидел и думал: “Господи, когда же вы просто начнете звонить друг другу?”. Постепенно, в процессе работы, я начал это менять. Ходил ко всем и говорил: “Почему вы не разговариваете?”. И реально — коммуникация стала лучше. Потом на ретро кто-то из команды сказал: “У нас тестировщики какие-то аномальные.” И директор департамента согласился.Но в хорошем смысле — потому что мы очень коммуникабельные, стараемся помочь всем, налаживаем взаимодействие, предлагаем улучшения. Вот так и продвигали всё постепенно.
Артём:
Ну круто, круто! Я тоже считаю, что тестировщик — это важный человек в команде. Он — связующее звено между всеми: знает многое, видит всё, общается со всеми. Классно, что ты так влился и нашёл своё место, свой проект.
Алексей:
Когда мы один раз с лидом виделись лично, он разговорился и говорит: “Слушай, мне за тебя и второго тестировщика дали грамоту и благодарность. За то, что я нашёл таких классных QA на проект.”
Артём:
Круто, круто. Класс. Расскажи теперь про инструменты, с которыми работаешь, и вообще — как выглядит твой типичный день тестировщика?
Алексей:
Первый вопрос — какие инструменты для тестирования я использую. Это Offset Explorer — инструмент для работы с Kafka. Он допотопный, конечно, но очень простой в использовании, интуитивно понятный. Естественно, DBeaver — для работы с базами данных PostgreSQL. Также, разумеется, Kibana — для работы с логами и локализации проблем по сервисам, в основном по бэкенду. Ну и, конечно, Postman — это просто must-have для работы с API. Даже если его никто не использует на проекте, всё равно стоит применять. В Swagger, например, после каждого обновления страницы сбрасываются значения, и всё приходится переписывать руками. А Postman это решает — очень удобно. Ну и, разумеется, DevTools — используем практически все вкладки при тестировании.
Теперь о рабочем дне. У меня он начинается примерно в 9 утра. Сначала захожу и просматриваю колонку In Testing — какие задачи поступили в тестирование. Поскольку ребята из разных часовых поясов, задачи могут приходить в любое время, поэтому утром важно всё проверить, чтобы понимать, что можно брать в работу. Также захожу на почту — посмотреть сообщения от аналитиков. Когда они пишут контракты или заводят задачи, они всегда просят нас их апрувить. Мы просматриваем задачу или контракт со своей стороны как QA: если видим проблемы или вопросы — оставляем комментарии. Если есть несостыковки в контрактах, подсвечиваем: “Вот здесь не так, обратите внимание.”
Артём:
А в чём это? В Confluence? Типа уведомления на почту приходят, когда странички обновляют, или как?
Алексей:
Нет, не в Confluence. У нас всё локализовано внутри компании — Outline и Azure DevOps. Все системы крутятся на наших серверах, ничего внешнего мы не используем. Даже Test Management System — своя, внутренняя. В Azure DevOps, когда создаешь задачу, просто тегаешь нужных людей — QA, разработчика — и система через хуки автоматически отправляет уведомление на почту: “Вас отметили, обратите внимание, такие-то комментарии.” Всё работает очень удобно. После этого, если есть новые задачи в In Testing, мы с моим вторым QA созваниваемся минут на 5–10. Распределяем, кто что берёт, и начинаем тестирование. Если находим баги — заводим только критичные, которые блокируют работу системы или серьезно влияют на функционал. А мелкие вещи просто пишем в комментариях в задаче, дублируем сообщение в чат и лично разработчику, чтобы не плодить кучу багов.Мы к этому формату сами пришли, и нам за это сказали “молодцы”, потому что не создаём лишнюю бюрократию. Иногда разработчики правят баг прямо в моменте. Ты пишешь: “Слушай, глянь, тут проблема.” Он отвечает: “О, давай посмотрим.” — и тут же исправляет. И, конечно, они нас за это благодарят: “Спасибо, что не заводите баги и не портите статистику.”
Артём:
Ну да, сразу всё решается.
Алексей:
Да. Потом, если есть дейлики — созваниваемся, обсуждаем, что делали, какие проблемы, что в планах. Плюс работа с тестовой документацией — она у нас сейчас в процессе написания. Мы периодически проводим ревью: проверяем, где нужно что-то переписать, обновить, исправить, чтобы поддерживать актуальность. Смотрим друг у друга, помогаем в этом плане. В целом, вот так и устроен наш рабочий день.
Артём:
А как у вас ревью устроено? Вы как-то помечаете где-то в ТМСке или переносите в отдельную таблицу?
Алексей:
Да, всё верно — у нас в ТМСке. Мы создаем тест-план, где, например, 10 кейсов, взятых с определенным тегом “новые”. Кладём их себе в отдельную папку для работы и начинаем проходить ревью. Если кейс актуален, ставим соответствующий статус “reviewed”. Если есть правки — в моменте их вносим: переписываем, дополняем, отмечаем в комментарии, что тест-кейс обновлён, потому что функционал изменился. После этого закрываем его и переводим из “на ревью” в “готово”.
Артём:
А регрессию уже успели внедрить, или пока ещё нет?
Алексей:
Внедрили, но она такая… вялая, несуразная. Это просто другие аналитики и разработчики ходят по ресурсу — ну, не сайту, а именно по нашему продукту — и проходят, что-то кликают, что-то смотрят. Такой, знаете, своеобразный регресс без нас решили провести. И потом выдают нам целый список проблем. А потом говорят:
“Ну, заводите баги.” Я смеюсь: “Ребят, ну это же неправильно. Вы половину моментов даже не учли.” Потому что они, как аналитики и разработчики, проверяли только позитивные сценарии — просто что-то кликнули, посмотрели, функционал работает — и всё. А QA же видит совсем по-другому: мы замечаем всё то, что неочевидно. Те сценарии, на которые разработчики даже не обращают внимания. В итоге мы потом всё равно сами прошлись, когда уже выкатили все задачи и обновили сервисы, и нашли кучу проблем. Часть из них исправили сразу же в моменте, не оформляя баги. А после демонстрации — уже оставшиеся незначительные баги оформили официально.
Артём:
Окей, а DevOps-ы у вас есть?
Алексей:
Да, есть отдельная команда DevOps, но мы с ними напрямую тоже не взаимодействуем. С ними работают разработчики. Например, когда нужно что-то обновить — они просто пишут DevOps-ам заявку на почту. DevOps берут готовую мастер-ветку и перевыкатывают ее на demo-стенд. Вот так у нас устроено взаимодействие.
Артем:
Круто! Мне нравится, что у тебя с одной стороны много самостоятельности — ты сам принимаешь решения, как и что проверять, — а с другой стороны проект насыщенный: и бэк, и фронт. Очень здорово. Хочу ещё спросить: как тебе в целом QA? Не разочаровался? Может, есть уже что-то, что не нравится? Или наоборот — что больше всего нравится в тестировании?
Алексей:
Ну, я скажу так: в QA очень весело и интересно, особенно когда тебе не бьют по рукам. Когда у тебя есть свобода действий, но при этом ты можешь отстаивать свою точку зрения. Важно уметь доказать свою правоту — не просто “я так думаю”, а показать факты, доказательную базу. И да, QA реально влияет на проект целиком, не только на отдельные задачи. Ты можешь своим решением повлиять даже на PM — развернуть задачу и сказать: “Иди к бизнесу, переуточняй.” Такое тоже бывает. А самое приятное — видеть результат своей работы. Когда ты видишь, что продукт развивается, становится лучше, качественнее — и понимаешь, что в этом есть и твоя заслуга. Сказать, что мне что-то не нравится — не могу. Вначале было страшно, а сейчас я прям дышу полной грудью и наслаждаюсь. Даже, можно сказать, веселюсь по-своему, потому что у нас руки не связаны, работаем свободно и самостоятельно. И это — кайф.
Артём:
Круто. Ребят, может, у вас есть вопросы? Пишите в чат, ответим, если кто-то хочет уточнить.
Участник:
Испыталка три месяца была?
Алексей:
Да, испыталка была три месяца. Но когда мы были в неформальной обстановке, лид сказал, и потом уже на созвоне повторил: “Ребят, вы два месяца отработали — считайте, что вы прошли испыталку на 300%. Всё хорошо, не переживайте.” Так что формально она длилась три месяца, но по факту нас закрыли раньше.
Участник 2:
Куда планируешь дальше развиваться? Может, в авто?
Алексей:
Да, у нас есть перспектива пойти в автоматизацию на Python в рамках проекта. Но я скажу честно — то, что тебе дадут на проекте, не всегда отражает полную картину. Тебе могут дать библиотеку, где ты просто подставляешь переменные, не понимая, как писать код. Это, по сути, полумера — не для меня. Я за то, чтобы учиться основательно: сначала теоретическая база, потом практика, чтобы понимать, что ты делаешь, и быть самостоятельным.
Артём:
Ну да, конечно. Писать код и просто менять переменные — это очень разные вещи. Потому что одно дело — свой код писать, а другое — читать чужой. А это намного сложнее.
Алексей:
Согласен. Ну и в целом, автоматизация — это не панацея. Да, компании это приветствуют, радуются, когда ты развиваешься, изучаешь новые технологии. Им реально приятно — прям хлопают в ладоши.
Артём:
А вас поощряют обучение? Может, оплачивают?
Алексей:
Пока не уточнял, но должны. Плюс у нас есть премиальная часть: если ставишь себе план и осваиваешь новые навыки — возможен пересмотр зарплаты или надбавка.
Участник 3:
Какие вообще зарплаты предлагали на собесах, какая вилка была?
Алексей:
Были предложения от 130 до 240 тысяч. Те, где 240 — это “чёрные” зарплаты: самозанятость, налоги платишь сам, отпускных и больничных нет, работаешь со своим оборудованием. А где 150–180 — там уже “белая” зарплата, официально, с техникой, с отпуском, всё как положено.
Артём:
Сейчас примерно та же вилка, плюс-минус, по рынку. Хорошо, спасибо. Тогда твоё напутствие ребятам — особенно тем, кто готовится выходить на рынок. На что обратить внимание, как справляться с трудностями в начале пути?
Алексей:
Я скажу так: при подготовке к выходу на рынок нужно хорошо знать теорию — не просто читать по листочку, а уметь объяснить своими словами, понимать, о чём говоришь. Плюс советую интересоваться у выпускников или у тех, кто уже работает: спрашивайте, как у них устроен процесс, как идёт флоу. Это важно, потому что на собесах часто бывают вопросы по менеджменту, и я сам на этом спотыкался. Если на проекте возникают непонимания или трудности — сначала загуглите вопрос. Даже в том же ИИ. Иногда мы задаём слишком простые вопросы, которые каждый QA должен знать, и это может вызвать лишние подозрения. Самое главное — не бойтесь гуглить, не бойтесь обращаться к коллегам. Если в команде есть другой QA — общайтесь, если нет — идите к лиду или начальнику по тестированию. Не замыкайтесь, всё можно решить.
Артём:
Круто. Думаю, если придерживаться этих советов, всё будет хорошо. Окей, Лёх, спасибо, что пришёл. Рад, что у тебя всё складывается, что ты развиваешься. Желаю дальнейшего роста, перехода в автоматизацию — куда захочешь — и чтобы всё было круто.
Алексей:
Вам большое спасибо, что позвали, дали возможность рассказать свою историю и поделиться, может, чем-то полезным для учеников.
Артём:
Спасибо тебе! Ну всё, ребят, спасибо, что пришли. Всем пока!
Алексей:
Всем пока, всем до связи. Спасибо!
Контакты
Телеграм-бот для связи: https://t.me/quality_academy_bot
Телеграм-канал школы: https://t.me/quality_academy
Отзывы учеников: https://t.me/+C2yITW3SfQ05ZjJi
Сайт школы: https://quality-academy.ru/
Артём:
Так, ребят, всем привет! Сегодня у нас очередная встреча с выпускником. Сегодня у нас в гостях Лёха, Алексей — наш ученик, который уже прошёл испытательный срок. Сейчас он расскажет, как у него всё сложилось. Лёх, привет! Очень рад тебя видеть
Алексей:
Привет! Взаимно, рад всех видеть, готов поделиться и рассказать, чем смогу.
Артём:
Как настроение, нормальное?
Алексей:
Да, хорошее. Немного волнуюсь, давно не разговаривал на публику.
Артём:
Да тут все свои, можно расслабиться. Окей, давай начнём, как обычно, с самого начала. Расскажи, как ты вообще пришёл в эту сферу и чем занимался до этого.
Алексей:
Я пришёл в IT, потому что сейчас эта сфера бурно развивается. Всё растёт очень быстрыми темпами, появляются новые идеи, и всё крутится вокруг технологий. Здесь большие перспективы — и по росту, и по саморазвитию, и по знаниям. До перехода в QA я работал в сфере безопасности дорожного движения, специалистом по сопровождению стационарных комплексов фото- и видеофиксации нарушений.
Артём:
То есть ты занимался чем-то вроде координации, менеджментом?
Алексей:
Да, всё верно. Это была больше координационная работа: сопровождение комплексов после установки, поддержка, мониторинг их работы. Если не вдаваться в детали — так, коротко. Конечно, там много нюансов, но это уже совсем узко, вряд ли кому интересно.
Артём:
Понял. То есть до нашей школы ты нигде в IT не учился?
Алексей:
Нет, не учился.
Артём:
Хорошо. И как тебе вообще далась учёба? Как шло обучение, легко ли было?
Алексей:
Ну, на самом деле, учеба далась непросто. Было тяжело перестроить мозг на другой лад, потому что всё-таки QA — это человек, который видит продукт с самого начала и до самого конца: от анализа требований до сопровождения и поддержки.
Нужно было развить внимательность, дотошность, научиться смотреть на всё под другим углом. Большинство пользователей просто пользуются продуктом, а тестировщик должен видеть, как он устроен изнутри. Вот перестроиться на это мышление было сложнее всего. Но потом, в процессе обучения, стало легче. Материал был очень подробно подан — без “воды”, всё чётко структурировано: только самое нужное и важное.
Артём:
Окей. А по времени сколько у тебя заняла учёба? Как ты занимался — каждый день или через день?
Алексей:
Я занимался примерно один-два раза в неделю, в основном по выходным. Весь курс у меня растянулся где-то на полгода. Я шёл спокойно, не торопясь, стараясь вникнуть во всё, что проходили. Конечно, были трудности, но помогали менторы — особенно ты, кстати, как наш ментор, очень хорошо помогал, когда были проблемы. В общем и целом, шесть месяцев ушло на всё обучение.
Артём:
Хорошо. А какой спринт тебе запомнился больше всего — любимый или, может, наоборот, самый сложный?
Алексей:
Самый тяжёлый для меня — это спринт по SQL. Очень интересный, но непростой, если не понимать принцип его работы. Тут важно именно понять, как SQL устроен, а не просто выучить команды. Когда понял, всё пошло как по маслу. Осознал я это уже во время прохождения собеседований — и это на самом деле мне очень помогло. Так что, наверное, это мой нелюбимый и тяжелый для меня спринт.
Артём:
А любимый какой?
Алексей:
Любимый — это, конечно, спринт с Postman. Классный инструмент, с ним интересно работать.
Артём:
Мы вчера как раз на тире с ребятами SQL-задачи решали, было весело. Ну, понял, супер. Ты ведь активно посещал созвоны и тиры, насколько я помню, да?
Алексей:
Да, тир я посещал очень активно — особенно когда вышел на рынок. Ходил почти каждый день: повторял материал, закреплял то, что прошли, и разбирал интересные вопросы, которые попадались на собеседованиях. Хотел обсудить их с ребятами, услышать разные мнения. Поэтому тиры я не пропускал — считаю, это очень важный этап обучения, особенно перед выходом на рынок. Без них успешное прохождение техсобесов было бы гораздо сложнее.
Артём:
Да, без этого, конечно, тяжело. Окей. А можешь вспомнить какие-то трудности во время учёбы? Или всё шло спокойно, планово?
Алексей:
Есть одна история, запомнилась до сих пор. Кажется, это был третий спринт — там, где баг-репорты, чек-листы, тест-кейсы. Было задание: к одной задаче придумать три уточняющих вопроса. Я тогда был в деревне, сел вечером делать. Думаю: «Сейчас быстро напишу». В итоге просидел над этим часов пять или шесть! Сижу, уже 11 вечера или 12, жена приходит: «Ты спать собираешься?» А я только тогда понял, сколько времени прошло. Вот это был реально запоминающийся момент — полностью ушёл в процесс.
Артём:
Ну круто, круто. Окей, спасибо. Тогда перейдем ближе к собесам. Ты прошёл все спринты, сдал домашки, и вот началась подготовка к выходу на рынок. Вот ты всё подготовил, вышел на рынок. Расскажи, как у тебя шли собесы. Насколько помню, не всё быстро получилось?
Алексей:
Поиск оффера у меня занял около трёх месяцев. Это был довольно долгий процесс. За это время я прошёл примерно 13 технических собеседований и где-то около 20 скринингов. В день откликался на 25–30 вакансий, иногда меньше — просто потому, что подходящие заканчивались.
Артём:
Помнишь свое первое собеседование? Или, может, какое-то, которое особенно запомнилось?
Алексей:
Да, конечно! Первое техническое собеседование у меня было, если не ошибаюсь, в ***. И там QA просто меня задушил вопросами — такой, знаете, классический “душнила”. Он сразу говорит: “Вот тебе JSON”, — открывает экран и: “Смотри, найди ошибки”. Я нахожу несколько, он кивает и спрашивает: “А скобки посчитал?”. Он говорит: “JSON невалидный, тут 25 скобок должно быть, а у тебя 23.” А потом я в начале собеседования честно сказал, что с SQL пока не очень дружу, могу разве что простенький запрос написать. И он мне, конечно, сразу дал задачу на JOIN. Я говорю: “Слушайте, не смогу сейчас сходу придумать запрос.” А он: “Ну, вы же сами сказали, что у вас слабый SQL.” И вот так, знаете, прямо сверху вниз — “давай, рассказывай, что знаешь!”. Для первого собеса — стресс колоссальный. Я тогда сидел в шоке.
Зато потом, ближе к концу, был собес у меня был в *** — там я, наоборот, сам “задушил” лида вопросами. Это был мой последний собес перед тем, как я получил оффер от текущей компании. И ещё я обратил внимание, что у них QA подключается только на этапе тестирования, а не в начале цикла разработки. Я сказал прямо: “Это плохая практика. Если тестировщик не участвует в процессе с самого начала, то потом можно легко упустить что-то важное и задержать релиз.” Я эту идею до сих пор везде продвигаю — и на своём проекте тоже.
Артём:
Это было, получается, сколько? Полгода назад?
Алексей:
Нет, четыре месяца назад.
Артём:
А, да, точно — четыре. Кстати, интересно: у тебя тогда было 13 технических собесов, и это всего четыре месяца назад. Сейчас, кажется, рынок уже немного изменился — не так активно, как раньше. Не уверен, что сейчас у кого-то набирается по 12–13 собеседований. По 5–6 — ещё да, но 13 — это, конечно, плотненько. Ну, ничего, такие циклы всегда бывают. Так, получается, собес с *** был одним из последних. И в итоге там — отказ, да?
Алексей:
Разумеется. К тому моменту мне уже прислали оффер из компании, где я сейчас работаю — на отличных условиях и очень приятную сумму. Я написал им, что, мол, жду ответ, а они сказали — “вернемся на следующей неделе”. Но неделя уже подходила к концу, и я уточнил: “Ответьте, пожалуйста, чтобы я мог принять решение”. Хотя, если честно, я уже знал, что туда не пойду — просто хотелось поставить точку. В итоге часа через два они написали: “Извините, но мы выбрали другого кандидата.” Классическая отписка.
Артём:
Да, стандартная история. Хорошо. Расскажи про оффер, который ты в итоге принял — без конкретных цифр, просто по условиям. Это удаленка?
Алексей:
Да, полная удаленка. Причём не только по России — можно работать из любой точки мира. Нет фиксированного графика “с девяти до шести”. Каждый выбирает удобное время: кто-то работает с восьми до пяти, кто-то с десяти до семи. Главное — предупредить коллег, чтобы все понимали, в какие часы ты онлайн и можно планировать совместную работу. Компания предоставляет оборудование — корпоративный ноутбук, мощный, с отличным экраном и железом. Если работаешь из офиса, за тобой закрепляют рабочее место. И офис, кстати, шикарный: кухня с кофемашинами, закусками, даже корзинка с коньяком на “тяжёлый день” стоит — не шучу! Есть небольшой спортзал, чтобы размяться. А ещё в офисе есть массажист. Можно записаться и прямо в рабочее время сходить на массаж.
Артём:
А ты уже пользовался?
Алексей:
Нет, я в офис не хожу. Но если бы ходил, обязательно воспользовался бы, прям на 200%.
Артём:
Я понял, ну круто, да. А у тебя, кстати, СБ была?
Алексей:
СБ не было. Мы просто заполняли анкету для неё. Сказали, что это чистая формальность.
Артём:
А ты же ведь работал параллельно, когда проходил собеседования, верно?
Алексей:
Да, да. И, собственно, из-за этого всё немного затянулось. Работа у меня была очень объемная, тяжелая, и совмещать ее с подготовкой к собеседованиям было сложно. После рабочего дня ты уже выжат, а на собесе нужно быть собранным, думать, отвечать — это тоже выматывает. Если планируешь интервью на вечер, то уже никакой — два слова связать тяжело. Поэтому я тогда работал на удаленке, старался ставить собеседования на утро — часов на 11, 12, максимум на час дня. Так легче: голова свежая, не уставший. Плюс успеваешь пробежаться по материалам, освежить всё, что уже учил. Иногда даже делал шпаргалки — выписывал несколько ключевых слов, чтобы во время собеса легче вспоминать нужные темы.
Артём:
Ну да, шпаргалки можно — я тоже раньше пользовался. Окей, получается, ты получил оффер, тебе дали две недели на отработку?
Алексей:
Да, всё верно. Две недели отработал, в пятницу забрал трудовую книжку с прошлого места, а уже в понедельник вышел на новое и оформился.
Артём:
Круто, круто. Всё официально у тебя, всё чётко.
Алексей:
Да, абсолютно всё официально. И, кстати, наша компания аккредитована как IT-компания.
Артём:
Угу, то есть ипотеку уже взял или скоро возьмешь?
Алексей:
Ну, пока этим ещё не пахнет, но, возможно, в перспективе воспользуюсь такой привилегией.
Артём:
Окей, понял. Давай тогда про проект. Это, на самом деле, самое интересное — думаю, и для ребят тоже. Расскажи про проект, про команду, процессы, особенно про первые дни: как тебя приняли, чем занимался. Потому что у всех всё по-разному — у кого-то месяц доступы выдают, у кого-то помощи никакой, всё по-разному. Как это у тебя было?
Алексей:
Когда я только пришёл, мне сказали: “У тебя будет онбординг, недели две”.
Артём:
Это на собесе сказали?
Алексей:
Да, на собеседовании. Но я сразу понял — кто-то что-то недоговаривает. В итоге прихожу на проект — и никакого онбординга нет. Вообще. Ни методичек, ни вводных, ничего. Просто: вот тебе документация, вот требования, вот бизнес-постановки, вот тебе таск-трекер с задачами и описанными API-контрактами — садись, разбирайся. Я сижу и думаю: “А с чего вообще начать?” Проект новый, требования еще меняются, документация дописывается на ходу, ничего окончательно не утверждено. И вот ты сидишь, смотришь на всё это и пытаешься понять, как вообще в голове всё это собрать. Был жёсткий стресс. Выручил тот факт, что в команде был еще один QA, который пришел на несколько недель раньше меня. Мы пообщались, и он начал меня погружать в проект — объяснил, какие инструменты использовать для тестирования, какие сервисы у нас в работе, где что лежит. Он мне очень помог. Ну, пришлось разбираться. Естественно, я замучил всех разработчиков вопросами по работе с сервисами — чтобы вообще понять, что к чему. С каждым лично созванивался — начиная от Project Manager и заканчивая нашим QA — чтобы познакомиться и понять, кто чем занимается.
Артём:
Лично ты имеешь в виду онлайн?
Алексей:
Да, всё верно. Потом потихоньку пошло: начал изучать техническую документацию, бизнес-постановки, вникать. И параллельно начал гулять по самому проекту — нашёл там столько багов, что просто устал их описывать. Мы со вторым QA вдвоём сидели и всё фиксировали. До этого он этим особо не занимался, а тут втянулся вместе со мной. Проект у нас был новый, регресса не было вообще, тестовой документации — ноль. Лид сказал на одном из созвонов: “Ребят, нужно написать техническую документацию. Всё, что видите — фиксируйте и документируйте.” Я спрашиваю: “А эталон будет, как писать правильно? Чтобы потом не сказали — вроде красиво, но не по стандарту?”. Он отвечает: “Зайдите в другой проект, посмотрите там кейсы, доступ есть.”. Ну, мы посмотрели — и всё равно написали по-своему. Лид потом посмотрел и говорит: “Нормально, в принципе, всё.” Я говорю: “Мы сделали, как нам удобно. Мы между собой всё понимаем, если кто-то новый придёт — спокойно его погрузим.” Главное, что всё описано четко и понятно. Сам проект построен на микросервисной архитектуре. Используется REST API. Бэкенд пишется на Python, фронтенд — на JavaScript. Когда я пришел, было где-то 7–8 сервисов, сейчас — уже 21.
Артём:
Нормально, разрослись.
Алексей:
Да, да. У нас используются такие технологии, как Kafka, Redis, PostgreSQL, Elasticsearch — это такая мощная поисковая система. Плюс Kibana, Kubernetes, контейнеры с образами — всё по классике. Может, что-то ещё упускаю, но в потоке информации уже не всё вспомню.
Артём:
А как быстро тебе дали первую задачу после прихода на проект?
Алексей:
Через четыре дня, в пятницу, сказали: “Давай, бери задачку.” Я сижу и думаю: “Что-то быстро…”
Артём:
Помнишь, что это была за задача?
Алексей:
Честно, уже нет. Сейчас у нас был большой релиз, я весь в нём закопался, всё подзабыл.Помню только, что первая задача была простенькая, фронтовая.
Артём:
А у тебя больше фронт или бэк? С чем работаешь чаще?
Алексей:
Со всем — примерно 50 на 50. Мне самому интересно и там, и там. Поскольку проект микросервисный, очень важно понимать структуру всей системы — как всё между собой связано. QA должен знать, как всё работает, чтобы находить уязвимые места. Например, где одно изменение может повлиять на другой сервис. А во фронте мне просто интересно экспериментировать. Я даже свои идеи предлагал.
Вот одна из них: если пользователь заполнил форму (даже просто поставил точку) и случайно захочет закрыть страницу — должно появляться окно с предупреждением. Project Manager сказал: “Хорошая идея”. Я позвонил аналитику, рассказал, что хочу реализовать.Она говорит: “Да, опишу”. В итоге задача была создана, PM её согласовал, взяли в разработку, я потом сам же её и тестировал.
Артём:
Ну прикольно. Классный пейс.
Алексей:
Это как раз один из моментов, когда по каким-то фронтенд-штукам можно привнести свои идеи. Но когда я предлагал идею, я всегда подкреплял её фактами с других проектов. Но, конечно, поначалу с взаимодействием в команде было сложно. Все люди новые, друг друга не знают, все сидят на удаленке — кто в разных городах, кто за границей. Коммуникация была нарушена: команда только-только собралась, и каждый работал, как говорится, в своём углу. Из-за этого часто не хватало общения при решении задач. Например, фронт хотел подтянуть данные с бэка, писал запрос — а он неправильно сформирован. В payload-е передается неправильное значение, бэк его просто не может прочитать. А контракта в тот момент либо не было, либо он был плохо описан. И вместо того, чтобы просто созвониться и договориться, как правильно, все тянули это до дейлика. Из-за этого дейлики растягивались с 15 минут до полутора часов. Я сидел и думал: “Господи, когда же вы просто начнете звонить друг другу?”. Постепенно, в процессе работы, я начал это менять. Ходил ко всем и говорил: “Почему вы не разговариваете?”. И реально — коммуникация стала лучше. Потом на ретро кто-то из команды сказал: “У нас тестировщики какие-то аномальные.” И директор департамента согласился.Но в хорошем смысле — потому что мы очень коммуникабельные, стараемся помочь всем, налаживаем взаимодействие, предлагаем улучшения. Вот так и продвигали всё постепенно.
Артём:
Ну круто, круто! Я тоже считаю, что тестировщик — это важный человек в команде. Он — связующее звено между всеми: знает многое, видит всё, общается со всеми. Классно, что ты так влился и нашёл своё место, свой проект.
Алексей:
Когда мы один раз с лидом виделись лично, он разговорился и говорит: “Слушай, мне за тебя и второго тестировщика дали грамоту и благодарность. За то, что я нашёл таких классных QA на проект.”
Артём:
Круто, круто. Класс. Расскажи теперь про инструменты, с которыми работаешь, и вообще — как выглядит твой типичный день тестировщика?
Алексей:
Первый вопрос — какие инструменты для тестирования я использую. Это Offset Explorer — инструмент для работы с Kafka. Он допотопный, конечно, но очень простой в использовании, интуитивно понятный. Естественно, DBeaver — для работы с базами данных PostgreSQL. Также, разумеется, Kibana — для работы с логами и локализации проблем по сервисам, в основном по бэкенду. Ну и, конечно, Postman — это просто must-have для работы с API. Даже если его никто не использует на проекте, всё равно стоит применять. В Swagger, например, после каждого обновления страницы сбрасываются значения, и всё приходится переписывать руками. А Postman это решает — очень удобно. Ну и, разумеется, DevTools — используем практически все вкладки при тестировании.
Теперь о рабочем дне. У меня он начинается примерно в 9 утра. Сначала захожу и просматриваю колонку In Testing — какие задачи поступили в тестирование. Поскольку ребята из разных часовых поясов, задачи могут приходить в любое время, поэтому утром важно всё проверить, чтобы понимать, что можно брать в работу. Также захожу на почту — посмотреть сообщения от аналитиков. Когда они пишут контракты или заводят задачи, они всегда просят нас их апрувить. Мы просматриваем задачу или контракт со своей стороны как QA: если видим проблемы или вопросы — оставляем комментарии. Если есть несостыковки в контрактах, подсвечиваем: “Вот здесь не так, обратите внимание.”
Артём:
А в чём это? В Confluence? Типа уведомления на почту приходят, когда странички обновляют, или как?
Алексей:
Нет, не в Confluence. У нас всё локализовано внутри компании — Outline и Azure DevOps. Все системы крутятся на наших серверах, ничего внешнего мы не используем. Даже Test Management System — своя, внутренняя. В Azure DevOps, когда создаешь задачу, просто тегаешь нужных людей — QA, разработчика — и система через хуки автоматически отправляет уведомление на почту: “Вас отметили, обратите внимание, такие-то комментарии.” Всё работает очень удобно. После этого, если есть новые задачи в In Testing, мы с моим вторым QA созваниваемся минут на 5–10. Распределяем, кто что берёт, и начинаем тестирование. Если находим баги — заводим только критичные, которые блокируют работу системы или серьезно влияют на функционал. А мелкие вещи просто пишем в комментариях в задаче, дублируем сообщение в чат и лично разработчику, чтобы не плодить кучу багов.Мы к этому формату сами пришли, и нам за это сказали “молодцы”, потому что не создаём лишнюю бюрократию. Иногда разработчики правят баг прямо в моменте. Ты пишешь: “Слушай, глянь, тут проблема.” Он отвечает: “О, давай посмотрим.” — и тут же исправляет. И, конечно, они нас за это благодарят: “Спасибо, что не заводите баги и не портите статистику.”
Артём:
Ну да, сразу всё решается.
Алексей:
Да. Потом, если есть дейлики — созваниваемся, обсуждаем, что делали, какие проблемы, что в планах. Плюс работа с тестовой документацией — она у нас сейчас в процессе написания. Мы периодически проводим ревью: проверяем, где нужно что-то переписать, обновить, исправить, чтобы поддерживать актуальность. Смотрим друг у друга, помогаем в этом плане. В целом, вот так и устроен наш рабочий день.
Артём:
А как у вас ревью устроено? Вы как-то помечаете где-то в ТМСке или переносите в отдельную таблицу?
Алексей:
Да, всё верно — у нас в ТМСке. Мы создаем тест-план, где, например, 10 кейсов, взятых с определенным тегом “новые”. Кладём их себе в отдельную папку для работы и начинаем проходить ревью. Если кейс актуален, ставим соответствующий статус “reviewed”. Если есть правки — в моменте их вносим: переписываем, дополняем, отмечаем в комментарии, что тест-кейс обновлён, потому что функционал изменился. После этого закрываем его и переводим из “на ревью” в “готово”.
Артём:
А регрессию уже успели внедрить, или пока ещё нет?
Алексей:
Внедрили, но она такая… вялая, несуразная. Это просто другие аналитики и разработчики ходят по ресурсу — ну, не сайту, а именно по нашему продукту — и проходят, что-то кликают, что-то смотрят. Такой, знаете, своеобразный регресс без нас решили провести. И потом выдают нам целый список проблем. А потом говорят:
“Ну, заводите баги.” Я смеюсь: “Ребят, ну это же неправильно. Вы половину моментов даже не учли.” Потому что они, как аналитики и разработчики, проверяли только позитивные сценарии — просто что-то кликнули, посмотрели, функционал работает — и всё. А QA же видит совсем по-другому: мы замечаем всё то, что неочевидно. Те сценарии, на которые разработчики даже не обращают внимания. В итоге мы потом всё равно сами прошлись, когда уже выкатили все задачи и обновили сервисы, и нашли кучу проблем. Часть из них исправили сразу же в моменте, не оформляя баги. А после демонстрации — уже оставшиеся незначительные баги оформили официально.
Артём:
Окей, а DevOps-ы у вас есть?
Алексей:
Да, есть отдельная команда DevOps, но мы с ними напрямую тоже не взаимодействуем. С ними работают разработчики. Например, когда нужно что-то обновить — они просто пишут DevOps-ам заявку на почту. DevOps берут готовую мастер-ветку и перевыкатывают ее на demo-стенд. Вот так у нас устроено взаимодействие.
Артем:
Круто! Мне нравится, что у тебя с одной стороны много самостоятельности — ты сам принимаешь решения, как и что проверять, — а с другой стороны проект насыщенный: и бэк, и фронт. Очень здорово. Хочу ещё спросить: как тебе в целом QA? Не разочаровался? Может, есть уже что-то, что не нравится? Или наоборот — что больше всего нравится в тестировании?
Алексей:
Ну, я скажу так: в QA очень весело и интересно, особенно когда тебе не бьют по рукам. Когда у тебя есть свобода действий, но при этом ты можешь отстаивать свою точку зрения. Важно уметь доказать свою правоту — не просто “я так думаю”, а показать факты, доказательную базу. И да, QA реально влияет на проект целиком, не только на отдельные задачи. Ты можешь своим решением повлиять даже на PM — развернуть задачу и сказать: “Иди к бизнесу, переуточняй.” Такое тоже бывает. А самое приятное — видеть результат своей работы. Когда ты видишь, что продукт развивается, становится лучше, качественнее — и понимаешь, что в этом есть и твоя заслуга. Сказать, что мне что-то не нравится — не могу. Вначале было страшно, а сейчас я прям дышу полной грудью и наслаждаюсь. Даже, можно сказать, веселюсь по-своему, потому что у нас руки не связаны, работаем свободно и самостоятельно. И это — кайф.
Артём:
Круто. Ребят, может, у вас есть вопросы? Пишите в чат, ответим, если кто-то хочет уточнить.
Участник:
Испыталка три месяца была?
Алексей:
Да, испыталка была три месяца. Но когда мы были в неформальной обстановке, лид сказал, и потом уже на созвоне повторил: “Ребят, вы два месяца отработали — считайте, что вы прошли испыталку на 300%. Всё хорошо, не переживайте.” Так что формально она длилась три месяца, но по факту нас закрыли раньше.
Участник 2:
Куда планируешь дальше развиваться? Может, в авто?
Алексей:
Да, у нас есть перспектива пойти в автоматизацию на Python в рамках проекта. Но я скажу честно — то, что тебе дадут на проекте, не всегда отражает полную картину. Тебе могут дать библиотеку, где ты просто подставляешь переменные, не понимая, как писать код. Это, по сути, полумера — не для меня. Я за то, чтобы учиться основательно: сначала теоретическая база, потом практика, чтобы понимать, что ты делаешь, и быть самостоятельным.
Артём:
Ну да, конечно. Писать код и просто менять переменные — это очень разные вещи. Потому что одно дело — свой код писать, а другое — читать чужой. А это намного сложнее.
Алексей:
Согласен. Ну и в целом, автоматизация — это не панацея. Да, компании это приветствуют, радуются, когда ты развиваешься, изучаешь новые технологии. Им реально приятно — прям хлопают в ладоши.
Артём:
А вас поощряют обучение? Может, оплачивают?
Алексей:
Пока не уточнял, но должны. Плюс у нас есть премиальная часть: если ставишь себе план и осваиваешь новые навыки — возможен пересмотр зарплаты или надбавка.
Участник 3:
Какие вообще зарплаты предлагали на собесах, какая вилка была?
Алексей:
Были предложения от 130 до 240 тысяч. Те, где 240 — это “чёрные” зарплаты: самозанятость, налоги платишь сам, отпускных и больничных нет, работаешь со своим оборудованием. А где 150–180 — там уже “белая” зарплата, официально, с техникой, с отпуском, всё как положено.
Артём:
Сейчас примерно та же вилка, плюс-минус, по рынку. Хорошо, спасибо. Тогда твоё напутствие ребятам — особенно тем, кто готовится выходить на рынок. На что обратить внимание, как справляться с трудностями в начале пути?
Алексей:
Я скажу так: при подготовке к выходу на рынок нужно хорошо знать теорию — не просто читать по листочку, а уметь объяснить своими словами, понимать, о чём говоришь. Плюс советую интересоваться у выпускников или у тех, кто уже работает: спрашивайте, как у них устроен процесс, как идёт флоу. Это важно, потому что на собесах часто бывают вопросы по менеджменту, и я сам на этом спотыкался. Если на проекте возникают непонимания или трудности — сначала загуглите вопрос. Даже в том же ИИ. Иногда мы задаём слишком простые вопросы, которые каждый QA должен знать, и это может вызвать лишние подозрения. Самое главное — не бойтесь гуглить, не бойтесь обращаться к коллегам. Если в команде есть другой QA — общайтесь, если нет — идите к лиду или начальнику по тестированию. Не замыкайтесь, всё можно решить.
Артём:
Круто. Думаю, если придерживаться этих советов, всё будет хорошо. Окей, Лёх, спасибо, что пришёл. Рад, что у тебя всё складывается, что ты развиваешься. Желаю дальнейшего роста, перехода в автоматизацию — куда захочешь — и чтобы всё было круто.
Алексей:
Вам большое спасибо, что позвали, дали возможность рассказать свою историю и поделиться, может, чем-то полезным для учеников.
Артём:
Спасибо тебе! Ну всё, ребят, спасибо, что пришли. Всем пока!
Алексей:
Всем пока, всем до связи. Спасибо!
Контакты
Телеграм-бот для связи: https://t.me/quality_academy_bot
Телеграм-канал школы: https://t.me/quality_academy
Отзывы учеников: https://t.me/+C2yITW3SfQ05ZjJi
Сайт школы: https://quality-academy.ru/