company_banner

Zero Bug Policy. Нет багов — нет проблем?

    Кто про что, а я про баги.


    В прошлом году я рассказывала вам про Багодельню — мероприятие, проводимое у нас в компании для чистки бэклога багов. Событие хорошее и полезное, но решающее проблему с багами разово. Мы провели уже шесть Багоделен, но количество участников постепенно снижалось и стало очевидно, что потребность в этом мероприятии начала отпадать. Основной причиной стало появление у нас Zero Bug Policy. О ней есть не так много источников на русском, где можно почитать и найти удобное решение для себя. В этой статье я расскажу про наш подход к теме и с удовольствием почитаю про ваш опыт в комментариях.



    Что же это такое?


    Zero Bug Policy (ZBP) — это политика обработки ошибок, основанная на правиле:


    «При появлении новой ошибки надо сразу принять решение исправить ее в ближайшее время, либо закрыть как “Won’t Fix”».

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


    Преимущества политики


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

    Звучит здорово, но ведь возможны и побочные эффекты.


    • Снижение качества продукта.
    • Деградация уровня команды тестирования. (Зачем тратить время на поиск хитрых и сложных багов, если их всё равно не исправят?).
    • Теряется полезный источник информации (в виде открытого бэклога) для новых членов команды.

    А ещё всегда остается фактор страха.


    «Вот мы закроем ошибку, а вдруг настанет светлое будущее, когда найдется время на исправление»?

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


    Вот мы закроем ошибку, а пользователь увидит ее в проде.

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


    Реализация


    Самое сложное — начать. Для этого надо найти время, ресурсы, желание (нужное подчеркнуть), чтобы перелопатить весь бэклог древних ошибок и принять радикальное решение об исправлении или закрытии.
    Затем собраться с силами и исправить «выжившие» после чистки ошибки.
    И начать жить по новым правилам.


    Начать делить баги на две категории:


    • баг, найденный при тестировании новой фичи;
    • баг, найденный на проде/при регрешне.

    Если вы находите баг при тестировании новой фичи, то надо сразу принять решение:


    • исправить баг до окончания разработки/тестирования фичи;
    • реклассифицировать баг (может, это на самом деле Improvement);
    • возможно, и не заводить баг вовсе, если вы не собираетесь его править.
      На стадии обкатки процесса лучше такие баги заводить и закрывать с резолюцией «Won’t Fix» с описанием причины закрытия. На основе этих данных вы сможете провести анализ дефектов и грамотно выработать критерии качества в своей команде.

    А если находится баг на проде/при регрешне, то надо принять решение, как поступить.


    • Исправить баг и при этом уложиться в срок, зависящий от приоритета бага. Сроки исправления — от «прямо сейчас» до двух спринтов. Если за два спринта баг не исправили, то его следует закрыть.
    • Изменить тип задачи с «Bug» на «Improvement».
    • Закрыть баг с резолюцией «Won’t Fix» с описанием причины закрытия.

    Для определения приоритета бага мы используем матрицу, которая объединяет в себе критичность бага в рамках конкретной команды и частоту возникновения.



    Другие детали


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


    Что позволит уменьшить количество багов при разработке новой фичи?


    1. Используйте широкий спектр технических и организационных практик (например, внедрение Quality Gates, Impact Analysis, Agile Testing).
    2. Исключите места генерации багов за счет рефакторинга старого кода.
    3. Исправляйте ошибки быстро, что позволит уменьшить их влияние в дальнейшем.
    4. Пишите автотесты, чтобы обнаруживать проблемные места быстрее и
      предотвратить повторение ошибок.

    Метрики


    Чтобы не делать выводы на своих ощущениях, мы следим за метриками по ZBP (я очень люблю Tableau и использую его для построения отчетов). Это позволяет отслеживать прогресс в динамике и подсвечивать возникающие проблемы.



    Результаты


    Какие же результаты работы по ZBP у нас?


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


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


    Выводы


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

    Всем добра и меньше багов!

    • +24
    • 4,4k
    • 2
    Авито
    235,28
    У нас живут ваши объявления
    Поделиться публикацией

    Комментарии 2

      +1
      Возможно и не заводить баг вовсе, если вы не собираетесь его править. На стадии обкатки процесса лучше такие баги заводить и закрывать с резолюцией «Won’t Fix».

      Мне кажется, что баг надо заводить в трекере, даже после этапа обкатки. QA же уже его воспроизвёл. Так любой желающий сможет на него посмотреть и понять что о проблеме знают.


      На основе этих данных вы сможете провести анализ дефектов и грамотно выработать критерии качества в своей команде.

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


      P.S.
      Возможно, в фразе "возможно и не заводить баг вовсе" не хватает запятой после слова "возможно".
      Надеюсь, я получил ачивку "указать на незначительную ошибку в здоровой статье, при этом допустив массу ошибок в маленьком комментарии?" :)

        0
        А есть какие-то идеи по автоматизации этого процесса

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

        Спасибо, Игорь)

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое