Быть QA-лидом: опыт роботов в распределении нагрузки тестировщиков

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

В условиях плотного графика мы столкнулись с проблемой ненормированной нагрузки QA-лидов на проектах. И начали разбираться в причинах. О том, что из этого вышло, рассказывает QA-инженер red_mad_robot Настя Корень.

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

Дисклеймер: тема нагрузки лидов довольно объёмая, а местами и вовсе бесконечная. В этой статье мы постарались рассказать о самом интересном и поделиться материалами, которые можно брать и сразу применять на практике.

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

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

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

На этом этапе QA практически не принимают участие. Из-за этого мы:

Это стандартная ситуация, к которой просто нужно быть готовым. Чтобы минимизировать разрывы, можно:

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

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

Тут у QA начинает кипеть работа. Сборки вот-вот поступят на тестирование, в команде прибавление, PM обрывает Zoom, а To Do List уже до Луны и обратно. Самое время показать свою суперсилу и приступить к активным действиям: ниже подсказки, которые помогут в работе на этом этапе.

Ещё на этом этапе важно выбрать и обсудить с командой релизный цикл. Какие есть варианты, их плюсы и минусы:

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

Подготовка и проведение демо-показа дают прозрачность в работе с клиентом и позволяют взглянуть на продукт со стороны. А ещё это возможность для дополнительного тестирования. Главное — составить сценарий показа и подготовить тестовые данные или видеоматериал.

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

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

QA здесь задействованы в трёх основных активностях. Давайте чуть подробнее.

Оформление метрик по проекту

Определить метрики и формат их сбора нужно сразу же по приходу на проект: договориться с клиентом о метриках качества, количестве багов и т. д. А на этапе финализации остаётся только оформить их в таблицу, график или документ. Часто бывает так, что мы торопимся и забываем всё обговорить, а потом клиент хочет, например, отчёт на 100 страниц. Пахнет работой.

Работа с фидбэком от пользователя и клиента

Важно определиться с тем, кто собирает фидбэк, где вы будете его собирать (в Jira, Slack или Telegram) и какая информация передаётся QA: версия ОС, ID пользователя и т. д. При работе с фидбэком есть риски:

Актуализация документации (ПСИ)

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

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

Договоримся сразу: мы рассматриваем встречи, которые подразумевают присутствие QA, — груминги, технические синки, демо и т. д. Созвоны вроде совещаний по согласованию бюджета и прочие встречи, где специалисты QA не требуются, выносим за скобки.

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

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

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

Подход стоит применять в работе:

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

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

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

QA-лиды, как там с нагрузкой в вашей компании?

Над материалом работали:

Чтобы ничего не пропустить, следи за развитием цифры вместе с нами:

Да пребудет с тобой сила роботов! 🤖

#red_mad_robot #qa #qaengineer