Что такое баг?

Баг (от англ. bug — жук, насекомое) — это ошибка, дефект или недочёт в программном обеспечении, который приводит к некорректному или неожиданному поведению программы. Баг возникает, когда фактическое поведение системы отличается от ожидаемого, описанного в требованиях или ожидаемого пользователем.

Баги являются неизбежной частью процесса разработки ПО. Даже самые опытные разработчики допускают ошибки, поэтому индустрия создала целые дисциплины — тестирование и [обеспечение качества (QA)](/ru/qa - quality assurance) — для систематического обнаружения и устранения багов.

В контексте Agile-разработки и Kanban баги требуют особого внимания к управлению, приоритизации и процессу исправления, поскольку они напрямую влияют на [cycle time](/ru/cycle time), throughput и удовлетворённость пользователей.

Происхождение слова

Популярная легенда связывает термин «баг» с инцидентом 9 сентября 1947 года, когда инженеры Гарвардского университета обнаружили мотылька, застрявшего в реле компьютера Harvard Mark II. Грейс Хоппер, работавшая с этим компьютером, зафиксировала инцидент в рабочем журнале с пометкой "First actual case of bug being found" (первый реальный случай обнаружения бага).

Однако термин «баг» в значении «техническая неисправность» использовался и ранее. Томас Эдисон в 1878 году применял это слово для описания проблем в своих изобретениях. В письме он писал: "Bugs — as such little faults and difficulties are called" (Баги — так называются мелкие неисправности и трудности).

Эволюция понятия

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

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

По серьёзности (Severity)

Критический (Critical / Blocker): система полностью неработоспособна или теряются данные пользователей. Примеры: падение сервера при входе в систему, утечка персональных данных, невозможность совершить оплату.

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

Средний (Medium): нарушение функциональности с наличием обходного пути. Примеры: некорректная сортировка списка, ошибка в отображении даты, некорректная работа фильтров.

Низкий (Minor / Trivial): косметические дефекты, не влияющие на функциональность. Примеры: опечатка в тексте интерфейса, неточное выравнивание элементов, некорректный цвет кнопки.

По приоритету (Priority)

Приоритет определяет порядок исправления и не всегда совпадает с серьёзностью:

• P1 (Критический): исправить немедленно, отложив всю остальную работу
• P2 (Высокий): исправить в текущем спринте
• P3 (Средний): включить в бэклог для следующего спринта
• P4 (Низкий): исправить при наличии свободного времени

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

По типу

Функциональные баги: программа не выполняет заявленную функцию или выполняет её некорректно.

Баги производительности: система работает слишком медленно, потребляет избыточные ресурсы или не справляется с нагрузкой.

Баги безопасности: уязвимости, позволяющие несанкционированный доступ к данным или системе.

Баги совместимости: программа некорректно работает в определённых браузерах, операционных системах или устройствах.

Баги юзабилити: интерфейс вводит пользователя в заблуждение или затрудняет выполнение задач, хотя технически работает корректно.

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

Каждый баг проходит через определённые стадии от обнаружения до закрытия:

1. Новый (New/Open): баг обнаружен и зарегистрирован в системе
2. Подтверждённый (Confirmed): баг воспроизведён и подтверждён командой
3. Назначен (Assigned): баг назначен конкретному разработчику для исправления
4. В работе (In Progress): разработчик приступил к исправлению
5. Исправлен (Fixed): разработчик внёс исправление в код
6. На проверке (In Review): исправление проходит code review
7. На тестировании (In QA): тестировщик проверяет исправление
8. Закрыт (Closed): баг подтверждён как исправленный
9. Переоткрыт (Reopened): если исправление не сработало или баг проявляется в другом сценарии

Отладка (debugging) — это процесс поиска, локализации и устранения причины бага. Это одна из ключевых компетенций разработчика.

Процесс отладки

1. Воспроизведение: первый и важнейший шаг — стабильно воспроизвести баг. Баг, который не удаётся воспроизвести, крайне сложно исправить.
2. Локализация: определение участка кода, в котором содержится ошибка. Для этого используются отладчики, логирование и метод бинарного поиска (поочерёдное отключение частей кода).
3. Анализ причины: понимание, почему код работает некорректно. Часто причина бага находится не в том месте, где проявляется симптом.
4. Исправление: внесение изменений в код, устраняющих причину бага.
5. Верификация: проверка того, что исправление решает проблему и не создаёт новых багов (регрессии).

Инструменты отладки

• Отладчики (Debuggers): встроенные инструменты IDE, позволяющие выполнять код пошагово и инспектировать переменные
• Логирование: запись информации о работе программы для анализа
• Профилировщики: инструменты для анализа производительности и потребления ресурсов
• Мониторинг ошибок: сервисы вроде Sentry, Bugsnag, Datadog для автоматического сбора информации об ошибках в production

Управление багами в Scrum

В Scrum существуют разные подходы к управлению багами:

• Критические баги обрабатываются как экспедиты и берутся в работу немедленно
• Баги, найденные в текущем спринте, исправляются в рамках текущего спринта и не считаются отдельными элементами бэклога
• Баги из предыдущих спринтов добавляются в [Product Backlog](/ru/product backlog) и приоритизируются [Product Owner](/ru/product owner) наравне с новыми функциями
• [Definition of Done](/ru/dod definition of done) должна включать критерии качества, минимизирующие количество багов, проникающих в production

Метрики качества

Команды отслеживают метрики, связанные с багами, для оценки и улучшения качества:

• Bug Escape Rate: процент багов, обнаруженных после релиза, а не во время тестирования
• Mean Time to Repair (MTTR): среднее время от обнаружения бага до его исправления
• Bug Density: количество багов на единицу кода (например, на 1000 строк)
• Regression Rate: процент исправлений, которые приводят к появлению новых багов
• Open Bug Count: количество незакрытых багов в системе

Лучший баг — это тот, который никогда не был создан. Существует множество практик для предотвращения багов:

Практики разработки

• [TDD (Test-Driven Development)](/ru/tdd - test-driven development): написание тестов перед кодом помогает предотвратить баги на этапе разработки
• BDD (Behaviour-Driven Development): описание поведения системы на понятном языке снижает разрыв между требованиями и реализацией
• Code Review: проверка кода коллегами позволяет обнаружить ошибки до слияния в основную ветку
• [Pair Programming](/ru/pair programming): совместная работа двух разработчиков над одним кодом снижает количество ошибок
• Статический анализ кода: автоматические инструменты обнаруживают потенциальные проблемы до запуска кода

Практики тестирования

• Автоматизированное тестирование: unit-тесты, интеграционные тесты и end-to-end тесты для систематической проверки кода
• Continuous Integration: автоматический запуск тестов при каждом коммите позволяет быстро обнаруживать регрессии
• Exploratory Testing: исследовательское тестирование для обнаружения неочевидных дефектов
• UAT (User Acceptance Testing): приёмочное тестирование с участием пользователей

Практики проектирования

• SOLID: принципы проектирования, снижающие сложность и хрупкость кода
• [DRY](/ru/dry - don't repeat yourself): устранение дублирования кода уменьшает количество мест, где может возникнуть баг
• [KISS](/ru/kiss - keep it simply stupid): простые решения содержат меньше багов, чем сложные

Стоимость исправления бага экспоненциально растёт на каждом последующем этапе жизненного цикла разработки:

• На этапе проектирования: минимальная стоимость — достаточно изменить требования или дизайн
• На этапе разработки: умеренная стоимость — нужно переписать часть кода
• На этапе тестирования: повышенная стоимость — нужно исправить код, обновить тесты, перетестировать
• В production: максимальная стоимость — помимо исправления, включает ущерб репутации, потерю клиентов, возможные юридические последствия

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

Чем баг отличается от дефекта?

В большинстве контекстов термины «баг» и «дефект» используются как синонимы. Однако в формальном контексте [QA](/ru/qa - quality assurance) иногда проводят различие: «дефект» — это несоответствие требованиям, а «баг» — это конкретная ошибка в коде. На практике в Agile-командах эти термины взаимозаменяемы.

Кто несёт ответственность за баги?

В Agile ответственность за качество несёт вся команда, а не только тестировщики. Разработчики пишут качественный код и автотесты, [Product Owner](/ru/product owner) устанавливает критерии качества, а [Scrum Master](/ru/scrum master) помогает выстроить процесс, минимизирующий количество дефектов.

Нужно ли оценивать баги в story points?

Это зависит от практик команды. Некоторые команды оценивают баги, чтобы учитывать их при планировании спринта. Другие считают, что баги — это «непредвиденная работа» и их оценка искажает velocity. Оба подхода имеют право на существование, важно быть последовательным.

Что такое «известная ошибка» (Known Issue)?

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

Как отличить баг от запроса на улучшение (Feature Request)?

Если поведение системы противоречит документированным требованиям или разумным ожиданиям пользователя — это баг. Если пользователь хочет, чтобы система делала что-то новое или иначе — это запрос на фичу. Граница иногда размыта, и [Product Owner](/ru/product owner) принимает решение о классификации.

Что такое «Zero Bug Policy»?

Zero Bug Policy — это подход, при котором команда обязуется исправлять все обнаруженные баги немедленно, прежде чем приступать к новой работе. Это не означает, что багов не бывает, — это означает, что они не накапливаются. Каждый новый баг либо исправляется сразу, либо осознанно отклоняется (если не критичен). Это помогает избежать разрастания технического долга и поддерживать стабильное качество продукта.

Как баги влияют на метрики команды?

Баги напрямую влияют на ключевые метрики: увеличивают [cycle time](/ru/cycle time) (время тратится на исправление вместо создания нового), снижают throughput (часть пропускной способности уходит на дефекты), увеличивают [lead time](/ru/lead time) (задержки из-за необходимости исправлений). Отслеживание доли багов в общем объёме работы — важный индикатор здоровья процесса разработки.