Как перейти из тестирования в разработку и дорасти до Senior. Советы из личного опыта

Привет, меня зовут Ольга, и я работаю Senior Back-end Developer в People.ai. В компанию я пришла как QA Automation и за три года прошла путь до текущей должности.

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

Статья пригодится инженерам позиций джуниор и мидл, которые хотят вырасти или сбалансировать свои hard skills и прокачаться в новых направлениях; QA, стоящим на распутье и думающим, куда двигаться дальше; нововходящим в отрасль и другим. Я не претендую на объективность, а расскажу, как это было, на своем опыте.

Иллюстрация Марии Рыбак

Кратко о моем пути в ІТ

Я закончила Национальный горный университет в Днепре по специальности «Экономическая кибернетика». Эта специальность пыталась объединить в себе модную тогда экономику с элементами Computer Science, поэтому после окончания вуза мне открывалось два пути — поприще экономиста и дорога в ІТ. И сначала я выбрала первое.

С карьерой экономиста не сложилось, зато стало понятно, чего я в жизни делать не хочу. Это нехотение дало мотивацию на занятия, и я стала учить HTML, CSS, SQL, JavaScript, запустила свой блог на WordPress. Меня восхищало то, как несколько тегов могут создать новую сущность, пусть даже одну HTML-страницу.

Затем моя компания стала задумываться о построении внутренней автоматизированной системы аудита, я помогала выделять use-cases и requirements, начала искать литературу, как это делать, и наконец поняла, что мои увлечения могут стать работой.

К тому времени у меня были знакомые в сфере IT, и дополнительной мотивацией стало желание другого отношения к себе как к работнику.

Официально в ІТ я попала в 2014 году, устроилась в Luxoft на позицию тестировщика — проект Deutsche Bank, связанный с тестированием ETL финансовых и рисковых данных и построением отчетов для регуляторов. Тогда моим хобби стал Python, но применить его на проекте возможности практически не было, поскольку работали на удаленной машине со строго ограниченным набором программ.

В 2016 году уволилась «в никуда»: устала от овертаймов, бюрократии на проекте (это когда по любому вопросу созревает цепочка писем с сотней менеджеров в копиях и никто не спешит брать ответственность за принятие решения) и хотелось уделить время себе и своему обучению.

В таком режиме продержалась не больше двух месяцев, так как получила заманчивый офер на QA Automation во Львов (молодая компания Lviv IT, работа на Go Daddy — тестирование системы по продаже услуг хостинга, доменов и прочего).

В 2017 году увидела на фейсбуке пост Олега Рогинского о том, что требуются QA Automation в стартап People.ai. Этот пост меня зацепил — от него повеяло смелостью, дерзостью и новыми технологиями. Написала. Мне ответили, последовала небольшая серия собеседований, потом офер.

История в People.ai

В People.ai необходимо было написать фреймворк для автотестирования по ручным тестам, которые занимали у QA по три дня, чтобы можно было прогонять его регулярно. Это было то, чего я хотела: самостоятельные решения, отсутствие микроменеджмента, интересные задачи. Засиживалась по выходным, потому что затягивало и было интересно попробовать новый подход.

Спустя некоторое время фреймворк был написан, а компания приняла решение работать без тестирования (end-to-end ownership — как девелопер, ты должен проверить свою фичу и провести ее до успешного релиза). Это означало, что QA в компании больше не будет. Мне предложили остаться в роли Junior-разработчика, и я с радостью согласилась.

У меня не было конкретного плана развиваться именно в разработке, но была уверенность, что я хочу заниматься кодом. Хочу создавать новые сущности и смотреть, как они функционируют. Я испытывала благоговение перед людьми, которые создают что-то новое и живое из символов. Это было и остается для меня магией, только в реальном мире. Со временем мои взгляды стали прагматичнее, но доля романтики в отношении к профессии сохранилась.

Первое время было тяжело: сложно уместить столько всего в голове и увидеть общую логику, страшно делать изменения в продуктовый код. Он казался чем-то сакральным. Наверное, этот страх остался где-то до сих пор, так как порой я ловлю себя на жадности к комментариям (простите, коллеги). Но со временем стало получаться легче и быстрее. Начало появляться понимание, как лучше сделать, как изменения повлияют на другие компоненты.

Примерно за полгода выросла в мидла. Наверное, больше всего помогло то, что делало меня хорошим QA — привычка к проверкам и к ownership. Я всегда тщательно тестировала свой код и хорошо покрывала юнит-тестами. К тому же накопилось системное знание о том, как работает продукт и как я могу проверить свои компоненты. Я чувствовала себя ответственной за код даже после релиза. Если видишь в проекте фичу, написанную корявенько, но покрытую на 95%, то это моя (шучу).

В 2020 году получила повышение до Senior. Раньше я думала, что Senior — это исключительно степень крутости твоих навыков кодинга. И что до этой ступени мне шагать еще много лет, особенно если оглянуться вокруг и посмотреть, с какими людьми я работаю.

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

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

Советы на пути к Senior

Я думаю, что Senior можно представить как некую общую сумму баллов, которую набираешь из разных категорий, все важны, но недостаток в одной из них может быть компенсирован другими.

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

Базовые вещи

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

Заношу темы и ссылки на статьи/учебники в документ и раскрашиваю цветами то, что уже прошла. Это дает мотивацию и позволяет замечать прогресс. До обучения по плану я постоянно видела только то, чего мне не хватает, и теряла мотивацию. Или шла по бесконечным ссылкам, пытаясь объять необъятное и съесть слона целиком, а в результате отчаивалась. Oдин только план не решает проблему системности и нехватки времени, поэтому нужно расставить приоритеты — в порядке важности для работы, актуальности и увлекательности.

Мне помогает тратить деньги на свое обучение, пусть даже символические. На том же Udemy в период распродажи можно купить курсы по 10 долларов, и эти 10 долларов будут мотивировать на продолжение.

Я люблю иногда зависнуть в онлайн RPG или поиграть в «Ведьмака», и мне помогает перенос RPG на реальную жизнь: я словно персонаж, который занимается прокачкой. Зарабатывает себе бейджики на Udemy, закрашивает ячейки в гугл-таблице с планом обучения. А если нет конкретных бейджиков и курсов, я использую простой таймер — пытаюсь как минимум пару часов в неделю тратить на улучшение своих скилов.

Еще один совет по базовым вещам — стараться выделить время на обучение в процессе работы над чем-то новым. Грубо говоря, лучше не бежать за хотфиксом на Stack Overflow, а выделить время на более глубокое изучение вопроса (конечно, если вокруг нет пожара и система не лежит).

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

Не кодингом единым

Кроме базы того, что делает человека инженером (а не доктором или архитектором), есть список умений и навыков, которые отличают именно Senior. Я бы хотела описать их подробнее, так как для меня они стали откровением.

• ownership;
• самостоятельность;
• инициативность;
• способность смотреть страху в лицо;
• коммуникация и прозрачность.

Ответственность за свой код. Это основное, особенно в продукте. Я бы даже сказала, что это условие попадания в продукт.

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

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

Это то самое «мне не все равно», которое не подделать и не изобразить. С ответственности начинаются все другие пункты, описанные ниже.

Самостоятельность. Это способность решить проблему. Размер проблемы зависит от уровня, на котором человек действует, и важно стремиться этот уровень повышать.

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

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

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

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

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

Пример из жизни. У нас есть репозиторий с кодом, хорошенько покрытый тестами. Тестов много, около двух тысяч. Каждый деплой на прод проходит после проверки линтером, проверки на уязвимости в библиотеках и прогона всех тестов. Тесты бегут не менее 10 минут. Итого, чтобы вмерджить код в master, необходимо 10 минут плюс еще 10 минут, чтобы задеплоить на прод.

Учитывая, что команда в среднем деплоит 7 раз в день, получаем 140 минут ожидания в день на команду. А если сталкиваемся с необходимостью сделать хот-фикс, то 20 минут превращаются в целую вечность.

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

Другой мой коллега очень не любит динамическую типизацию и использует в своих проектах статическую проверку типов через mypy. Там, где он касается кода, добавляет аннотацию с типами. Коллега активный ревьюер pull request’ов и, помимо рекомендаций по оптимизации кода, всегда напоминает о проверке типов. Сколько времени моей жизни он сэкономил, дав дельный совет или удержав от ошибки, я уже не берусь посчитать.

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

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

Сначала нас пугает необходимость работать с новыми технологиями, новой код-базой или новым языком. «Давайте попросим более опытного инженера разобраться с этим вопросом» ©

А потом вдруг понимаешь, что именно сделало упомянутого инженера более опытным. Он не боялся разбираться в новом, он читал код, документацию, логи и учился. И если не браться за новые задачи, то никакого опыта не будет, один лишь стаж. И это понимание — важная ступень между language-specific кодером и инженером.

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

Понимание последнего пришло ко мне с трудом. При переходе от джуниора я задавала много вопросов. Мне было неловко, но и работу надо было делать. А потом дошло, что целесообразнее потратить 10 минут времени более знающего коллеги, чем часами или днями биться об стену. Правда, и спрашивать теперь приходится гораздо реже.Тем самым я отвечаю своим коллегам — всегда готова ввести в курс дела или объяснить логику известного мне компонента.

Смотреть страху в лицо — это еще и умение признавать свои ошибки и учиться на них. В нашей компании с этим помогает практика написания постмортемов. Постмортем — это своеобразный отчет об инциденте, анализ его причин, таймлайна и поиск шагов по предотвращению подобных случаев в будущем, уменьшение времени на обнаружение и расследование. Каждый постмортем обсуждает инженерная команда. В результате всегда имеется список action items, которые будут предприняты в течение одной-двух недель. Таким action item может быть написание нового теста, добавление нового мониторинга или логов, введение дополнительных ограничений и политик.

Практика постмортема помогает принимать свои ошибки, принимать тот факт, что ошибиться может каждый, и конструктивно подходить к улучшению сервисов. Мы не ищем виноватых, мы улучшаем наш продукт и наши процессы.

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

Эстимейты, коммитменты и дедлайны можно нарушать! Главное — прозрачность процесса. И чтобы его обеспечить, необходимо научиться коммуницировать. Не просто писать или говорить на английском, а доносить нужную информацию правильным людям. Давать им пространство и время для маневра.

К примеру, в инженерном чате можно и нужно описывать самые суровые технические детали, а для нетехнических людей информацию следует подавать совершенно по-другому, в тех категориях, в которых мыслит целевая аудитория.

Людей бизнеса интересуют метрики и результаты того или иного решения для продукта и конечного пользователя. Вот на этом и необходимо сосредоточиться.

Если ведете разработку какой-то фичи или работаете над проектом, нужны регулярные апдейты, желательно каждый день и в одном и том же формате. Например, список шагов, что сделано, что в прогрессе, эстимейт текущего шага.

Вывод

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

И ответ на вопрос — зачем все это нужно? Мне это было нужно, потому что хотелось большей свободы и возможности создавать новые сущности и улучшать их. А также владеть суперспособностью починить прод и решить чью-то проблему (в диадеме и развевающемся плаще).

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

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

В заключение не могу удержаться и не посоветовать курс, с которого практически начался для меня Python — MITx: 6.00.1x Introduction to Computer Science and Programming Using Python, доступен на edx.org. Когда я проходила, проверка домашних заданий и получение сертификата еще были бесплатными.