red_mad_index: исследование качества интерфейсов интернет-магазинов
Написать нам
Меню

Назад к главному

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

Когда-то давно наш далёкий предок вылез из мирового океана и начал эволюционировать. Встал на четвереньки, потом на две ноги, взял палку — слово за слово, и вот вы получили персональный ноутбук, должность 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 уже до Луны и обратно. Самое время показать свою суперсилу и приступить к активным действиям: ниже подсказки, которые помогут в работе на этом этапе.

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

  1. 1_

    Релизный поезд. Подходит, когда релиз зависит от двух и более команд. Чтобы тестирование было плавным, нужно заранее продумать использование фича-тоглов.

  2. 2_

    Выпускать полную фичу. Плюс очевиден: выпускается полноценная работающая функция. Но есть и недостатки — такой релизный цикл подойдёт для спринта длительностью две недели и более, а само тестирование начинается после полноценно выпущенной фичи.

  3. 3_

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

  4. 4_

    Выпускать код «по кусочкам». Можно использовать, если нужна быстрая поставка результата. Подойдёт только для коротких спринтов.

  5. 5_

    Ежедневный выпуск сборки. Подходит для коротких спринтов и порционной поставки фичей. Но важно внимательно подойти к распределению нагрузки QA — есть риск перегрузиться.

  6. 6_

    UAT-тестирование или пользовательская приёмка. Выдаём определённому проценту пользователей возможность протестировать продукт, сокращаем нагрузку на QA и можем получить нестандартные кейсы.

Пятый этап — релиз

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

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

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

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

Шестой этап — финализация проекта

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

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

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

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

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

  • размытия ответственности, особенно если вы работаете в интеграционной команде;

  • увеличения нагрузки на QA-лида, если процесс передачи фидбэка не урегулирован.

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

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

Подходим ко встречам с умом

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

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

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

Такой подход имеет смысл при работе небольшой команды до&nbsp;трёх человек, в&nbsp;условиях высокой неопределённости по&nbsp;планам релизов и&nbsp;составам задач, а&nbsp;также на&nbsp;стадии сетапа проекта.<br>
Такой подход имеет смысл при работе небольшой команды до трёх человек, в условиях высокой неопределённости по планам релизов и составам задач, а также на стадии сетапа проекта.
Этот подход будет уместен только там, где работа построена исключительно на&nbsp;личности лида, и&nbsp;клиенты или лиды других практик или команд согласны разговаривать только с&nbsp;ним. К&nbsp;сожалению, такие кейсы всё ещё встречаются.<br>
Этот подход будет уместен только там, где работа построена исключительно на личности лида, и клиенты или лиды других практик или команд согласны разговаривать только с ним. К сожалению, такие кейсы всё ещё встречаются.
Подход стоит применять в&nbsp;работе:<br>• большой команды&nbsp;— в&nbsp;этом случае он&nbsp;скорее обязателен,<br>• в&nbsp;условиях стабильности процессов на&nbsp;проекте,<br>• при организации работы с&nbsp;разграничением зон ответственности сотрудников.<br>
Подход стоит применять в работе:
• большой команды — в этом случае он скорее обязателен,
• в условиях стабильности процессов на проекте,
• при организации работы с разграничением зон ответственности сотрудников.

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

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

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

***

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

  • текст — Настя Корень, Оля Никитина, Ксюша Сергеева,

  • редактура — Алина Ладыгина, Виталик Балашов,

  • иллюстрации — Юля Ефимова

Наша рассылка
В ней только самое важное: новости, кейсы, немного аналитики. Присылаем два раза в месяц.
Политика обработки персональных данных
По вопросам работы с персональными данными и подписками пишите на [email protected]
© red_mad_robot, 2008— 
Сделано роботами для людей
Разработка —