- PVSM.RU - https://www.pvsm.ru -
Кто про что, а я про баги.
В прошлом году я рассказывала вам про Багодельню [1] — мероприятие, проводимое у нас в компании для чистки бэклога багов. Событие хорошее и полезное, но решающее проблему с багами разово. Мы провели уже шесть Багоделен, но количество участников постепенно снижалось и стало очевидно, что потребность в этом мероприятии начала отпадать. Основной причиной стало появление у нас Zero Bug Policy. О ней есть не так много источников на русском, где можно почитать и найти удобное решение для себя. В этой статье я расскажу про наш подход к теме и с удовольствием почитаю про ваш опыт в комментариях.
Что же это такое?
Zero Bug Policy (ZBP) — это политика обработки ошибок, основанная на правиле:
«При появлении новой ошибки надо сразу принять решение исправить ее в ближайшее время, либо закрыть как “Won’t Fix”».
При этом не надо впадать в крайности: вообще не заводить ошибки или править все подряд. Важно выработать для себя критерии качества для фич, которые вы готовы отдавать пользователям и считать задачу выполненной после исправления всех важных ошибок.
Преимущества политики
Звучит здорово, но ведь возможны и побочные эффекты.
А ещё всегда остается фактор страха.
«Вот мы закроем ошибку, а вдруг настанет светлое будущее, когда найдется время на исправление»?
Очень маловероятно, что у вас появится лишнее время. Это как хранение старого барахла на балконе: вы не теряете надежду что-то из этих вещей использовать, но, скорее всего, это не произойдет никогда.
Вот мы закроем ошибку, а пользователь увидит ее в проде.
Расстроенный пользователь напишет в саппорт, который в свою очередь сообщит вам. Надо будет пересмотреть приоритет этой ошибки и повторно принять решение, исправлять ее или нет.
Самое сложное — начать. Для этого надо найти время, ресурсы, желание (нужное подчеркнуть), чтобы перелопатить весь бэклог древних ошибок и принять радикальное решение об исправлении или закрытии.
Затем собраться с силами и исправить «выжившие» после чистки ошибки.
И начать жить по новым правилам.
Начать делить баги на две категории:
Если вы находите баг при тестировании новой фичи, то надо сразу принять решение:
А если находится баг на проде/при регрешне, то надо принять решение, как поступить.
Для определения приоритета бага мы используем матрицу, которая объединяет в себе критичность бага в рамках конкретной команды и частоту возникновения.
Профит от использования такого подхода скорее всего будет незначительный, если вы дополнительно не станете менять процессы и подходы в разработке и тестировании.
Что позволит уменьшить количество багов при разработке новой фичи?
Чтобы не делать выводы на своих ощущениях, мы следим за метриками по ZBP (я очень люблю Tableau и использую его для построения отчетов). Это позволяет отслеживать прогресс в динамике и подсвечивать возникающие проблемы.
Какие же результаты работы по ZBP у нас?
Мы живем в реальном мире, и в чистом виде использовать политику не получилось.
Кто-то столкнулся с проблемой легаси и невозможностью в ограниченный срок исправлять некоторые баги. У кого-то был накопленный годами бэклог, к нему просто страшно было подступиться и они не торопились начинать этот процесс.
Но в целом многим командам удалось разобрать свои бэклоги и поставить определенную планку на количество открытых багов. Команды стали лучше оценивать баги и быстрее принимать решения о необходимости исправления.
Всем добра и меньше багов!
Автор: J_eve
Источник [2]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/testirovanie/320091
Ссылки в тексте:
[1] Багодельню: https://habr.com/ru/company/avito/blog/351736/
[2] Источник: https://habr.com/ru/post/455068/?utm_campaign=455068&utm_source=habrahabr&utm_medium=rss
Нажмите здесь для печати.