Проактивность на практике: как джуну найти интересные задачи

Привет, меня зовут Виктор, и я QA-инженер. Мне казалось, что у джунов только рутинные задачи, а чтобы брать интересные, надо поскорее стать мидлом. Я ошибался. На своем примере расскажу, как можно найти драйвовые задачи, даже если ты только начинаешь работать. 

Принять рутину как неизбежное, но полезное дело

Я пришел в Т-Банк стажером, и сначала мне поручали только простые задачи: например, протестировать изменения в ответе GET-ручки. Когда я только за них брался, они казались интересными, но через какое-то время я набивал руку и они превращались в рутину, поэтому мне становилось скучно. 

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

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

Конечно же нет, и вот почему.

Выбирать сложные задачи с низким приоритетом

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

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

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

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

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

Расскажу о нескольких задачах и о том, как я к ним пришел. 

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

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

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

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

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

Сначала я сомневался, что смогу это осилить, но ментор уверил, что все вполне решаемо: «Если возникнут вопросы, то просто спрашивай». Так и получилось. У меня появлялось много вопросов: как загружаются тест-кейсы в Allure из автотестов, как лучше представить графики, какие метрики кроме количества тест-кейсов стоит рассмотреть и многие другие. Со всеми мне помогали справляться коллеги выше по грейду.

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

Скрытие чувствительных данных в коде автотестов. Задача по интеграции с внутренним инструментом хранения чувствительных данных долгое время находилась в бэклоге. Я обговорил с проф. лидом возможности и сложности и взялся за задачу. Во время работы познакомился с новым для себя инструментом, работой с GitLab pipeline и с конфигурацией Gradle.

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

Искать задачи самому

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

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

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

• Внешние или внутренние митапы. Сходив на внутренний митап QA-инженеров по работе с Unit-тестами, я понял, что требовал лишнего от команды разработки (задача интеграции Unit-тестов разработки с проектом Allure, о которой писал выше): проставлять много аннотаций для тестов и классов, переименовывать методы. Я сократил инструкцию — оставил только необходимые пункты и убрал рекомендательные, чем ускорил работу для команды разработки.

• Тематические сообщества в компании, например SDET-команды, чаты по направлениям, тематические встречи и так далее. Благодаря этому и появилась идея написания этой статьи. Ребята агитировали к написанию материала, что показалось мне интересным и полезным для навыков структурированного изложения мыслей и работы с правками и замечаниями. Кто знает, может, и вы заметите то, что вам будет интересно и полезно.

• Другие команды. Многие практики и способы применения технологий можно на практике оценить у соседа. Например, во время выполнения задачи по внедрению процесса «Три амиго» я много общался с коллегами из других команд. Они без проблем рассказывали об опыте работы с этим инструментом — в каких ситуациях он показывает себя отлично, а в каких его лучше не использовать, делились документацией. Мне удалось вычленить из этого все необходимое для своей команды и начать внедрять процесс.

• Дейлики и брейнштормы — на них можно узнать о потребностях и проблемах. Будет здорово проявить инициативу. 

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