Вопросы профессионального развития — штука сложная. Иногда кажется, что ты немного подзастрял на своей должности (в своей сфере, своей компании — нужное подчеркнуть), и хочется сделать какой-то шаг вперед. Но куда именно и как — дилемма.

В этом посте мы при помощи наших коллег, Антона Масленникова и Антона Горбунова, попробуем наметить возможные векторы развития для QA-специалиста. Под катом — путь тестировщика, вертикальный и горизонтальный рост, переходы из тестирования в разработку или менеджмент и многое другое.

Вертикальное и горизонтальное развитие

С вертикальным все понятно — junior, middle, senior. 

Горизонтальное — это когда вы в рамках своего управления расширяете свои знания и практически навыки.

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

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

Senior — самостоятельная единица, которая самоорганизовывается, может организовывать других, выполняет самостоятельные задачи, в общем от него максимальная польза.

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

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

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

Например, у нас в СИБУРе некоторые ручные тесты хранятся в коде, так что в любом случае даже какому-нибудь простому ручнику приходится скачивать IDE, скачивать код, работать с гитом и постепенно разбираться с фреймворком автоматизации, который есть в проекте.

Хуже обстоят дела, когда этого фреймворка нет. 

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

Есть ли жизнь после автоматизации?

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

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

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

Здесь важно отметить, что на самом деле не все так просто.

Вы изучаете код, пишете какие-то маленькие задачи, потом более сложные. И вам в любом случае параллельно нужно будет изучать более глубоко абсолютно все технологии. Ведь, как правило, разработчики лучше разбираются в коде, в сетевых технологиях, в архитектуре. Допустим, если мы говорим, что тесты написаны на Java и на Kotlin, значит, вам в любом случае нужно будет изучать все фреймворки, которые нужны для разработки. Например, Spring.

Так что, если ваша конечная цель — перейти в разработку, то советуем не затягивать, ибо тут есть точка невозврата.

Точка невозврата

В чем же она заключается? 

Когда вы попытаетесь перейти из тестирования, вы можете потерять свой доход. Да, вы можете быть очень классным специалистом в автотестировании, у вас обширные знания, отличный опыт и все такое, но в плане разработки у вас будет недостаточно опыта, и вы будете дотягивать максимум до мидла. Ну ладно, ладно, мидла+. Соответственно, доход мидла будет ниже, чем senior QA. И будет достаточно некомфортно переходить.

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

И такая точка невозврата, в том, что если вы очень амбициозный автоматизатор, уже почти senior или мидл+, у вас, возможно, зарплата будет совпадать с мидлом-разработчиком или мидл-. 

Главное — не застрять в этой точке перехода.

А если не хочется из QA в разработку?

Да, не все хотят стать разработчиками. Вообще некоторые не хотят больше иметь дело с кодом, и что им тогда делать?

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

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

Если же такого нет, можно попробовать поизучать нагрузочное тестирование для себя. Обязательно нужно будет изучать язык, на котором будете нагружать технологии, архитектуру, инфраструктуру систем, потому что придется разворачивать стенды. И не забыть изучить инструмент какой-нибудь для нагрузки. Самый популярный сейчас — HP Loadrunner, либо Gmeter. Можно порешать любые легкие прикладные задачи. Как правило, если вы переходите в нагрузку, то вы уже умеете (умеете же?) разворачивать свои легкие микросервисы. Вот их-то и можно попробовать нагрузить. Либо если не хотите, либо нет возможности, то можно попробовать что-нибудь нагрузить именно в проекте. В нагрузочном тестировании очень важно изучить также теорию по нагрузочному тестированию, потому что она довольно-таки сильно дополняет ее.

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

Если всё это не так интересно

Посмотрите в сторону машинного обучения.

У нас есть одна история от коллеги — он попал именно в машинное обучение и вырос до руководителя подразделения. Сначала он был фриланс-разработчиком, потом заказчик ему предложил заняться автотестированием SDK (компания занималась вероятностными алгоритмами). После этого он успешно создавал тесты, затем начал участвовать в демо и в приемочном тестировании для заказчиков, начал с ними больше общаться. Как итог — он вырос до руководителя тестирования, а впоследствии до руководителя проекта.

Нашего героя интересовала именно цифровизация производственных процессов и область машинного зрения. И так совпало, что у нас в СИБУРе открылась вакансия на руководителя проекта в видеоаналитике. Он попал к нам, ему предоставили полный карт-бланш для того, чтобы он набрал людей, определил стек технологий. Между прочим, они уже внедрили успешный проект в видеоаналитике, который определяет брак на производстве, замечает, если сотрудники не соблюдают технику безопасности, фиксирует износ оборудования.

Данное направление сейчас очень перспективное, и специалистов сейчас достаточно мало по этому направлению.

Можно вообще без кода что-нибудь?

Можно. Продакт-менеджер.

Хороший продакт — это уже где-то процентов 70 удачного проекта. От такого человека многое зависит. Он принимает участие во всех аспектах жизни команды, отвечает за то, как все работает, насколько быстро и прочее.

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

Аналитика

Если продукт-менеджером быть не захотелось, то можно попробовать себя в аналитике.

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

Что в итоге

Как видите, реальных путей развития из QA на самом деле много. Тут нет серебряной пули и какого-то одного (да и двух) верных направлений, всегда выбирайте все под себя, отталкиваясь от собственных навыков, стремлений и интересов. Кстати, если напишете в комментах, как именно вам получилось пройти путь развития из QA куда-то дальше — будет здорово.