Автор статьи: Кирилл Маркидонов

Опыт в IT более 13 лет. QA Head, руководитель курса QA Lead

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

Может показаться, что при таком уровне коллективной ответственности лиды тестирования уже как будто бы и не нужны. Ведь если решение по многим вопросам команда принимает самостоятельно; если самые волнующие команду вопросы обсуждаются на ретро (и часто это не вопросы тестирования), то в итоге команда сама выбирает свой путь, а лиды упраздняются, являются просто частью команды разработки, тестируют сложные задачи и всё.

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

Об этом я и хочу поговорить в данной статье.

Дисклеймер

Меня зовут Кирилл Маркидонов. Вот уже почти 5 лет я Head of QA в сфере финтеха. Также я являюсь руководителем курса QA lead в OTUS. Будучи профессионалом в QA с более, чем 12-летним стажем, я безусловно различаю понятия «QA» и «тестирование», «обеспечение качества» и «контроль качества», «тест-лид» и «QA manager». Тем не менее, в данной статье я буду говорить о QA специалистах, чаще применяя понятие «тестировщик». Потому что просто так легче для изложения. Если мне потребуется провести разграничительную линию, отделяющую «высокий» QA от «простого» тестирования, я сделаю это отдельно по ходу повествования. 

Аналогично и с менеджментом в QA. Я буду использовать термин «тест-лид». Ваша должность может называться по-разному, но если речь идёт о том, что вы являетесь прямым руководителем конечных тестировщиков, при этом сами вы так же активно тестируете приложения и являетесь частью команды разработки, то эта статья будет вам полезна, а я буду говорить о вас как о тест-лиде, даже если вы QA lead, QA manager или Primary QA.

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

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

Типичные примеры таких ситуаций:

• Программисты не пишут юнит-тесты. Значит тестировщикам надо усилить и продлить тестирование.

• Программисты не помогают с импакт-анализом. Хорошо, дайте доступ к коду, будем тестировать методом белого ящика.

• Менеджер жалуется, что тестирование идёт слишком долго. Давайте мы начнём тестировать пораньше, а регресс сделаем выборочным. Будем пробовать сами писать автотесты, как сможем.

• Плохой swagger и документация к АПИ - пофиг, просто будем упарываться по UI автотестам.

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

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

Servant leadership

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

Суть этого подхода в том, что мы, как руководители, не назначаем задачи сверху, как это принято в обычной схеме руководства “сверху-вниз”. Вместо этого мы обеспечиваем среду, фокусируемся на потребностях команды и каждого её участника. 

В Servant leadership руководители больше отдают предпочтение влиянию на решения сотрудников, нежели на контроль их работы. Подсвечивают сильные стороны людей, нежели указывают на недостатки. Активно слушают, нежели выдают прямые указания. Цели таких руководителей всегда долгосрочные, а не сиюминутные. Сервант-лидер должен обладать такими навыками (не побоюсь этого слова - скиллами), как:

• умение слушать;

• излучение уверенности в себе;

• умение прогнозировать;

• эмпатия;

• умение мотивировать и убеждать;

• умение фасилитировать изменения;

• умение брать ответственность за успехи других;

• эмоциональный интеллект (и психолог на полставочки);

• стратегическое мышление (ака концептуализация);

• командообразующие навыки (даже правильнее сказать - построение сообщества).

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

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

• тест-лид как центр экспертизы QA;

• тест-лид как people manager;

• тест-лид как евангелист процессов в команду разработки;

• тест-лид как relationship manager;

Тест-лид как центр QA экспертизы

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

Тест-лид как евангелист процессов в команду разработки

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

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

Тест-лид как people manager

Вне зависимости от аджайл контекста, хороший лид должен владеть навыками пипл менеджмента. Умение общаться со своими сотрудниками, помогать им в сложных рабочих (а иногда и личных) ситуациях, мотивировать на свершения, оказывать психологическую поддержку, всё это очень важно для работы. Для этого нужно уметь как минимум проводить встречи один-на-один, а также проводить командообразующие мероприятия.

Тест-лид как relationship manager

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

Нам важно умение донести до своего руководителя (в нашем случае это часто QA manager/Head of QA) какие-то проблемы и сложности, с которыми сталкивается команда или конкретный сотрудник. Немаловажно и говорить об успехах своей команды. О достижении поставленных целей (вы же ставите цели?), о каких-то подвигах кого-то из команды. 

Всё это - важная часть работы лида, и с приходом скрама она никуда не девается. Да, скрам-мастер делает эту работу со своей стороны. Но в разрезе департамента качества (или QA гильдии, смотря какая у вас организационная структура) именно тест-лид должен подсвечивать успехи и вызовы своей команды.

Я тут много всего красивого расписал, но понимаю, что конкретики-то не очень много. Что такое «командно-образующие мероприятия»? Какие митинги один-на-один по настоящему эффективны? Какие приёмы фасилитации, можно использовать в сложных рабочих ситуациях? А как быть, если на тебе ответственность за несколько команд, но ты являешься частью только одной скрам-команды? Все эти и многие другие вопросы требуют не одного часа на ответ. Сложно взять и написать это в одной небольшой статье. 

Смотрите видео на ютубе, ходите на конференции, читайте статьи на хабре - много информации доступно в интернете. А если хотите поддержки профессионалов, которые уже прошли путь становления менеджеров и помогли многим инженерам вырасти в тест-лидов, то приходите к нам на курс QA Lead в OTUS. Там за 6 месяцев мы разберем, как технические вопросы менеджмента качества, так и вопросы общего менеджмента и развития команды. На странице курса вы также можете зарегистрироваться на бесплатные вебинары про дизайн команды и формирование стратегии тестирования.

Подытожим

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

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

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

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