Автор: Мэг МакКей (Meg MacKay)
Оригинал статьи
Перевод: Ольга Алифанова

Переход от «рассмотрения» к «уточнению» багов

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

Как новичок и тестировщик, я должна была поддержать команду в улучшении качества продукта. Но это было возможно только после решения вопроса, как нам работать в изменившихся командных условиях.

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

Что такое «сессия уточнения багов»?

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

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

Кто должен посещать сессии уточнения багов?

Как правило, сессия уточнения багов включает следующие роли:

• Менеджер проекта
• Представитель QA
• Представитель разработки.

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

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

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

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

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

Как проходит обычная сессия уточнения багов?

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

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

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

Верификация багов и анализ первопричин. На этом этапе команда определяет, баг перед ними или пользовательская ошибка, плохие данные, или какое-либо иное недопонимание. Этой быстрой оценкой руководят менеджер продукта и QA – у них в этой области больше опыта. Когда команда убедилась, что это действительно баг, владеющие кодом участники могут попытаться отследить первопричину в коде продукта. Пока они этим заняты, кто-то еще может открыть браузер с инструментами разработчика, чтобы исследовать сетевые запросы на предмет потенциальных ошибок данных, или использовать инструменты для исследования компонентов фронтэнда. Можно также погрузиться в системные логи в поиске полезных сообщений об ошибках. Цель тут – быстро выявить первопричину проблемы.

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

Приоритезация. Методология приоритезации в вашей компании может отличаться от нашей, но вне зависимости от методологии в ней будут такие элементы, как явное согласие всех участников насчет сроков исправления, основанных на риске, влиянии бага на бизнес и потребителей, и важности исправления по отношению к текущим задачам. Это будет отмечено в задаче при помощи принятой системы обозначений – скажем, «высокий – средний – низкий» или P0 – P5.

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

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

Преимущества уточнения багов

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

Эффективность и скорость

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

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

Выстраивание отношений

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

Единодушие

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

Проблемы

Внедрение нового процесса в организацию не всегда проходит гладко. Как тестировщики, мы знакомы с распространенными возражениями вроде «У нас нет на это времени» или «Встреч и так слишком много, как нам поможет еще одна?»

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

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

Заключение

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

Самым трогательным для меня моментом стало, когда один из наших регулярных участников сказал, что это их любимая встреча на неделе. «Это не просто про очистку багов – это про веселую командную работу над качественным ПО!»

Обсудить в форуме