Взаимозаменяемая команда тестирования — это реально. Делюсь своим опытом

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

По плану мы выпускаем два релиза в неделю. Но бывают горящие периоды, когда мы можем выпустить по 6+ релизов в неделю, и, бывает, даже ни один в день. Раньше в такие периоды я чувствовала себя не тест‑лидом, а релизным инженером, потому что кроме как на деятельность вокруг релизов, времени ни на что не хватало. Собрать, поставить на тестовые стенды, сборка падает, разбираешься. Поставили, проверили, отрегрессили, заполняешь, согласовываешь, передаешь, если поздняя установка — вообще танцы с бубном проходишь, потом ждешь установки, проверяешь, что в спешке ничего не положили.

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

Я не успевала ревьюрить тест‑кейсы, отслеживать качество тестирования срочных задач (хорошо, что у меня отличные ребята в команде!) — успевала заниматься только выводом релизов. Это было нехорошо, но так было заведено. Так было во всех командах, в том числе в моей команде, пока я была просто тестировщиком. Затем передалось мне «по наследству» и шло по накатанной. Первые месяцы моего тест‑лидства, пока я принимала все работы и процессы по команде, я ничего не могла с этим поделать, мне просто не хватало времени на подумать.

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

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

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

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

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

На этом этапе стало легче: я была уверена, что меня есть кому подстраховать, причем практически в любой ситуации сделать работу без моего участия. У команды были все инструкции, и коллегам не приходилось мне писать, если что‑то забылось.

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

Через пол года уже трое тестировщиков моей команды могли выводить релизы. И не просто под моим руководством, а вполне самостоятельно. В последний мой отпуск мне не написали ни разу!

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

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

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

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

P. S. Недавно мой коллега‑лид ушел в отпуск, и тут у замещающих его ребят, как обычно бывает, случилось комбо: одним релизом вывести новый приклад (чего они еще ни разу не делали), вторым вывести сложную доработку, которая затрагивает и другие приклады. И это при отсутствии лида! Вот тут мне помогли приобретенные навыки обучения процессам и наши инструкции. Мы спокойно разобрались во всех вопросах, передали свои записи, и ребята успешно справились, ничего не положили и порадовали свою команду.

Спасибо, что прочитали статью! Делитесь своим опытом в комментариях. Если материал окажется для вас полезным — у этой статьи появится продолжение:)