Когда-то давно наш далёкий предок вылез из мирового океана и начал эволюционировать. Встал на четвереньки, потом на две ноги, взял палку — слово за слово, и вот вы получили персональный ноутбук, должность QA-лида и отправились работать на удалёнку в распределённой команде.
В условиях плотного графика мы столкнулись с проблемой ненормированной нагрузки QA-лидов на проектах. И начали разбираться в причинах. О том, что из этого вышло, рассказывает QA-инженер red_mad_robot Настя Корень.
Чтобы понять, на что уходит время QA-лида в компании, которая создаёт цифровые продукты и сервисы, сначала нужно разобраться с его обязанностями. Для этого мы:
наложили задачи QA-лида на схему производственного процесса цифрового продукта;
нашли разрывы в производственном процессе;
оценили загрузку по встречам;
определили дополнительные процессы, влияющие на загрузку;
составили список внепроектной деятельности QA-лида;
проработали вопрос с онбордингом в проект;
выявили типовые ошибки и подумали, как их решить.
Дисклеймер: тема нагрузки лидов довольно объёмая, а местами и вовсе бесконечная. В этой статье мы постарались рассказать о самом интересном и поделиться материалами, которые можно брать и сразу применять на практике.
Упрощаем онбординг
Одним из ресурсоёмких процессов оказалось погружение команды или конкретного сотрудника в новый проект. Неструктурированный и хаотичный онбординг отнимает много сил и времени, поэтому мы придумали, как это облегчить, — составили и внедрили унифицированные чек-листы для онбординга в проект.
Саму суть онбординга все определяют по-разному, поэтому прежде всего мы провели опрос, в котором каждый участник команды рассказал, что это для него значит. Но результаты опроса все тоже интерпретировали по-своему, поэтому случился рассинхрон. Решили сделать подсказки в двух чек-листах:
для QA-лида, который погружается в проект со старта,
для QA-лида и/или QA-инженера, который онбордится в уже действующий проект.
Устраняем разрывы в этапах производственного процесса
За основу мы взяли шаблон производственного процесса, с которым каждый робот знакомится в самом начале работы в компании. Сверху наложили задачи QA-лида и поняли, что такая система будет работать только в том случае, если команда состоит из трёх QA-инженеров и лида. При любой другой конфигурации возникают несоответствия между ожиданиями и реальностью. Мы постарались собрать все разрывы и возможные решения.
Первый этап — инициация проекта
На этом этапе QA практически не принимают участие. Из-за этого мы:
слабо погружены в бизнес-процессы клиента,
должны самостоятельно разобраться в материалах и документах первых встреч,
не можем на первых этапах заложить время на тестирование.
Это стандартная ситуация, к которой просто нужно быть готовым. Чтобы минимизировать разрывы, можно:
пользоваться чек-листами,
выстроить и зафиксировать систему передачи информации от PM QA-лиду.
Второй этап — исследование
QA не принимают участие и на этом этапе. Как бы нам ни хотелось равномерно распределить нагрузку лида и QA-инженеров по всему проекту, простой на стартовых этапах и завал с овертаймами на следующих — это наша реальность. Но на этапе исследования QA всё же может внести свой вклад:
пообщаться с потенциальными пользователями,
консолидировать результаты исследования,
проработать чистый вариант тестирования,
зафиксировать представление о критичных функциях,
проработать риски движения сроков и возможные варианты, где время можно срезать.
Третий этап — проектирование
В этот момент QA активно вступает в игру. Чтобы лиду и команде было проще распределить своё рабочее время, мы составили список потенциально возможных активностей на следующих этапах и обозначили возможные профиты и риски от каждой.
Четвёртый этап — разработка
Тут у QA начинает кипеть работа. Сборки вот-вот поступят на тестирование, в команде прибавление, PM обрывает Zoom, а To Do List уже до Луны и обратно. Самое время показать свою суперсилу и приступить к активным действиям: ниже подсказки, которые помогут в работе на этом этапе.
Ещё на этом этапе важно выбрать и обсудить с командой релизный цикл. Какие есть варианты, их плюсы и минусы:
Релизный поезд. Подходит, когда релиз зависит от двух и более команд. Чтобы тестирование было плавным, нужно заранее продумать использование фича-тоглов.
Выпускать полную фичу. Плюс очевиден: выпускается полноценная работающая функция. Но есть и недостатки — такой релизный цикл подойдёт для спринта длительностью две недели и более, а само тестирование начинается после полноценно выпущенной фичи.
Выпускать сборки в определённый день. Подходит для любого вида спринта. Выпуск сборки может поставлять как полную фичу, так и частично реализованные функции. По аналогии с релизным поездом нужно использовать фича-тоглы и грамотно планировать время и оценку выпускаемых сборок.
Выпускать код «по кусочкам». Можно использовать, если нужна быстрая поставка результата. Подойдёт только для коротких спринтов.
Ежедневный выпуск сборки. Подходит для коротких спринтов и порционной поставки фичей. Но важно внимательно подойти к распределению нагрузки QA — есть риск перегрузиться.
UAT-тестирование или пользовательская приёмка. Выдаём определённому проценту пользователей возможность протестировать продукт, сокращаем нагрузку на QA и можем получить нестандартные кейсы.
Пятый этап — релиз
На этом этапе проводится подготовка к регрессу или оценка регресса заранее с QA. Мы даём оценку, исходя из процента своего участия в регрессе или от времени разработки. Есть нюанс — при такой оценке можно не учесть скорости и опасения других участников команды. А ещё оценка тестирования в процентах не всегда работает — бывают задачи, которые тестируются дольше, чем разрабатываются.
Подготовка и проведение демо-показа дают прозрачность в работе с клиентом и позволяют взглянуть на продукт со стороны. А ещё это возможность для дополнительного тестирования. Главное — составить сценарий показа и подготовить тестовые данные или видеоматериал.
Мы считаем, что лучше заранее определять встречу багскраба, исходя из сроков по текущему регрессу, и определять, сколько задач разработка возьмёт в исправление. Скорее всего, все задачи исправить не получится, поэтому нужно выбрать самые важные, опираясь на их критичность и скорость исправления. Чтобы не затягивать этот процесс, стоит подготовиться ко встрече, собрать информацию по дефектам и приоритетам и объяснить важность исправления отдельных задач.
Отдельный вопрос — как и когда готовить тестовую документацию. Договоритесь с клиентом о нужной тестовой документации и о сроках её сдачи (каждый спринт или к концу проекта). Если у клиента нет предпочтений, выбирайте документацию сами, но не забудьте согласовать. Учтите — если это произойдёт к концу проекта, то на QA упадёт большой объём работы, а именно этого мы и пытаемся избежать.
Шестой этап — финализация проекта
QA здесь задействованы в трёх основных активностях. Давайте чуть подробнее.
Оформление метрик по проекту
Определить метрики и формат их сбора нужно сразу же по приходу на проект: договориться с клиентом о метриках качества, количестве багов и т. д. А на этапе финализации остаётся только оформить их в таблицу, график или документ. Часто бывает так, что мы торопимся и забываем всё обговорить, а потом клиент хочет, например, отчёт на 100 страниц. Пахнет работой.
Работа с фидбэком от пользователя и клиента
Важно определиться с тем, кто собирает фидбэк, где вы будете его собирать (в Jira, Slack или Telegram) и какая информация передаётся QA: версия ОС, ID пользователя и т. д. При работе с фидбэком есть риски:
размытия ответственности, особенно если вы работаете в интеграционной команде;
увеличения нагрузки на QA-лида, если процесс передачи фидбэка не урегулирован.
Актуализация документации (ПСИ)
Стоит заранее обсудить формат проведения приёмо-сдаточных испытаний и зафиксировать результаты. Если не оговорить детали по ПСИ, есть риск, что придётся делать всё в последний момент. Помните: качественная документация — это хороший тон и плюс в карму.
Подходим ко встречам с умом
Работа занимает много времени, но созвоны тоже — это факт, с которым трудно спорить. Достаточно просто заглянуть в календарь. Но, помимо времени, встречи забирают ещё и силы. А в условиях ненормированной загрузки QA-специалистов разбрасываться ресурсами не стоит. Поэтому к вопросу созвонов стоит отнестись внимательно. Например, определиться, каким составом на них ходить.
Договоримся сразу: мы рассматриваем встречи, которые подразумевают присутствие QA, — груминги, технические синки, демо и т. д. Созвоны вроде совещаний по согласованию бюджета и прочие встречи, где специалисты QA не требуются, выносим за скобки.
Есть три подхода к посещению созвонов при условии, что на проекте работает больше одного QA. Показываем в картинках.
Такой подход имеет смысл при работе небольшой команды до трёх человек, в условиях высокой неопределённости по планам релизов и составам задач, а также на стадии сетапа проекта.
Этот подход будет уместен только там, где работа построена исключительно на личности лида, и клиенты или лиды других практик или команд согласны разговаривать только с ним. К сожалению, такие кейсы всё ещё встречаются.
Последний подход стоит применять в работе:
большой команды — в этом случае он скорее обязателен,
в условиях стабильности процессов на проекте,
при организации работы с разграничением зон ответственности сотрудников.
Чтобы повысить уровень взаимозаменяемости сотрудников, можно либо брать на встречу двух QA-инженеров, чтобы дальше они страховали друг друга, либо организовывать процесс погружения других QA в набор задач сотрудника, когда он, например, уходит в отпуск.
Выбирать подход стоит в зависимости от особенностей проекта, на котором вы работаете. Третий подход более эффективен для крупных проектов, первый — для маленьких и коротких. От второго подхода вообще хотелось бы уйти, а пострадавших на них лидов отправить на реабилитацию в санаторий.
И не стоит забывать, что стадии проектов меняются, а сами проекты могут разрастаться или уменьшаться. Очень важно гибко менять свой подход к организации работы, чтобы своевременно реагировать на эти изменения.
QA-лиды, как там с нагрузкой в вашей компании?
Над материалом работали:
текст — Настя Корень, Оля Никитина, Ксюша Сергеева,
редактура — Алина Ладыгина, Виталик Балашов,
иллюстрации — Юля Ефимова.
Чтобы ничего не пропустить, следи за развитием цифры вместе с нами:
red_mad_news
Design Jam
red_mad_dev
red_mad_product
LinkedIn
VK
Да пребудет с тобой сила роботов!
Интересные статьи
Интересные статьи
