Zero Bug Policy
t.me/qa_chillout
Что такое Zero Bug Policy?
Zero Bug Policy это такой подход к разработке программного обеспечения, который направлен на то, чтобы в бэклоге продукта не было ошибок. При проведении исследования по этой теме появилось несколько различных реализаций этой политики, но все они преследуют общую цель — нулевое количество накопившихся ошибок. Это не означает, что багов никогда не будет, но цель состоит в том, чтобы багов не было в известной кодовой базе. Основной принцип политики заключается в том, что любое известное несоответствие или ошибка должна быть устранена перед добавлением новых функций или выпуском продукта.
Преимущества Zero Bug Policy
1. Качество продукта — продукт с минимальным количеством багов обеспечивает лучший пользовательский опыт, повышая удовлетворенность клиентов и укрепляя репутацию компании.
2. Снижение затрат на поддержку — исправление багов на этапе разработки дешевле и быстрее, чем после релиза. Это снижает затраты на поддержку и исправление ошибок в будущем.
3. Улучшение производительности команды — разработчики и тестировщики работают в более стабильной и предсказуемой среде, что повышает общую производительность команды.
4. Психологическое облегчение — отсутствие раздувающегося бэклога ошибок снижает давление на команду и помогает сосредоточиться на текущих задачах.
Возможные побочные эффекты
1. Снижение качества продукта — если баги закрываются с резолюцией «Won’t Fix» слишком часто, это может привести к снижению общего качества продукта.
2. Снижение уровня команды тестирования — тестировщики могут потерять мотивацию искать сложные баги, зная, что их могут не исправить.
Реализация Zero Bug Policy
Самое сложное — провести субботник и разобрать бэклог команды. Но не просто пересмотреть, а принять решение по каждому багу: исправляем или закрываем.
Дефекты можно разделить на 2 категории:
1. Баги, найденные во время тестирования новой фичи:
Такого рода дефекты должны быть исправлены немедленно, в противном случае ставить DONE тестируемой Story или Feature категорически нельзя. В противном случае, вы нарушаете базовое правило Agile, гласящее, что DONE — значит DONE. Story / Feature может считаться завершенной только после того, как она была полностью протестирована и нет открытых дефектов.
2. Баги, найденные в продакшене или во время регресса:
- Вы можете исправить их либо сразу (либо в следующем спринте, но не позже).
- Вы можете закрыть их как «Won’t Fix», если ценность исправления ошибки меньше, чем усилия по ее исправлению.
- Вы можете отложить исправление ошибки на будущее путем преобразования в доработку (изменить тип с «Bug» на «Feature» / «Improvement»).
Инструменты и процессы
Наиболее используемые инструменты:
- JIRA (таск трекер).
- Metabase (визуализация данных).
Метрики
Zero Bug Policy ориентирован на минимизацию ошибок в программном обеспечении. Для эффективного выполнения этой политики используются разнообразные метрики, позволяющие измерить качество кода и оптимизировать процесс разработки. Разберем основные.
Количество ошибок (bug count): общее число обнаруженных ошибок в коде за определённый временной период.
Среднее время обнаружения ошибок (mean time to detect, MTTD): среднее время от появления ошибки до её выявления.
Коэффициент повторного появления ошибок (recurring bug ratio): процент ошибок, которые появляются снова после их первоначального исправления.
Качество кода (code quality): общая оценка качества кода, основанная на применении стандартов кодирования, читаемости и эффективности кода.
Среднее время исправления ошибок (mean time to repair, MTTR): среднее время от обнаружения ошибки до её устранения.
Скорость исправления ошибок (bug fix rate): темп, с которым команда разработки устраняет обнаруженные ошибки.
Плотность дефектов (defect density): отношение числа ошибок к размеру кода, что позволяет определить количество ошибок на тысячу строк кода (KLOC).
Покрытие тестами (test coverage): процент кода, который был проверен автоматическими тестами, что помогает оценить степень проверки функциональности.
Практическая реализация
Zero Bug Policy — это не одноразовая инициатива, а постоянный процесс. Представим, что в компании X проводились мероприятия по чистке бэклога багов. В этой компании внедрили Zero Bug Policy и с течением времени необходимость в этих мероприятиях снизилась. Основной принцип — устранение всех багов сразу после их обнаружения или их закрытие с пометкой «Won’t Fix».
В команде каждый раз делят дефекты на две категории:
- найденные при тестировании новой фичи,
- обнаруженные в продакшене / при регрессионном тестировании.
Для каждой категории устанавливается флоу по работе с дефектами и сроки их исправления.
Заключение
Zero Bug Policy — это амбициозный, но достижимый подход к разработке программного обеспечения. Он требует значительных усилий и изменений в культуре и процессах команды, но результаты в виде высокого качества продукта и удовлетворенных пользователей оправдывают эти усилия. Самым сложным этапом является убеждение команды в том, что такой подход является правильным и вполне жизнеспособным.
Обсудить статью, узнать больше можно в телеграм канале «Тестировщики нужны».