Что такое баг и баг-репорт

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

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

Определение и значение термина «баг»

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

Что такое баги, обычно можно увидеть на этапе тестирования. В это время первая часть работы закончена, и программист отдаёт продукт тестировщикам.

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

И всё это — баги.

Типы багов

Можно выделить несколько типов основных ошибок, которые хорошо дают понять, что такое баг.

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

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

Пример:

def some_function(condition):
    if condition:
        print("Эта часть протестирована.")
    else:
        # Ошибка: пропущена буква в `print`
        prin("А эта — нет.")

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

Устранить синтаксические ошибки несложно, потому что чаще всего для этого достаточно немного подправить код.

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

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

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

def calculate_area(length, width):
    # Должно быть length * width, но вместо этого:
    return length + width 
# Ожидается 50, но мы получим 15
print(calculate_area(5, 10))

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

Ниже — пример ошибки типов в Python. Мы указываем, что функция должна работать с двумя целыми числами, а потом пытаемся прибавить к числу переменную-строку:

def add_numbers(a: int, b: int) -> int:
    return a + "b"

add_numbers(1, 2)

Сообщение в консоли при попытке запуска:

TypeError: unsupported operand type(s) for +: 'int' and 'str'

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

Ошибки среды выполнения, или runtime errors. Проявляются после успешного компилирования кода во время запуска программы.

Вот пример кода на Python, который будет успешно скомпилирован и запущен. В этой программе мы создаём список из 3 элементов и просим вывести на экран шестой элемент (помним, что нумерация начинается с нуля):

numbers = [1, 2, 3]
print(numbers[5])

В консоли получим такую ошибку:

IndexError: list index out of range

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

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

Арифметические ошибки происходят из-за неправильных вычислений. Один из самых простых примеров арифметических багов — деление на ноль.

x = 10 / 0

print(x)

Сообщение об ошибке:

ZeroDivisionError: division by zero

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

Ресурсные ошибки получаются, когда ресурсов машины не хватает. Например, попытка создать слишком большое число или другой объект может привести к ошибке Memory Error.

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

Ошибки взаимодействия означают, что какой-то атрибут программы не синхронизирован с другими и компоненты работают некорректно вместе. Например, программный интерфейс приложения (API) написан так, что ожидает JSON, но получает вместо этого XML.

Другой пример — многопоточные программы, которые выполняют несколько задач одновременно. Если они будут одновременно изменять какие-то ресурсы и фрагменты системы, результат работы может быть непредсказуемым и не таким, как его задумывали по бизнес-плану.

Серьёзность багов

Характеристика, которая показывает, как сильно баг влияет на работу программы. Может ли она работать, пока баг не исправлен? Насколько от этого страдает бизнес?

Есть 5 уровней серьёзности багов.

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

Пример тривиального бага — несоответствие текста брендбуку (правилам того, как что-то оформляется в компании).

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

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

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

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

Блокирующие баги полностью останавливают работу всей системы или её критически важных компонентов. Например, пользователи не могут нажать кнопку «Оплатить» и купить товар.

Приоритет багов

От приоритета зависит, как быстро нужно исправить баг.

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

Низкий приоритет — у багов без существенных последствий для работы программы.

Средний приоритет присваивается средним и серьёзным багам в зависимости от того, как сильно страдает бизнес без их исправления.

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

Причины появления багов

Недостаточное тестирование. Тестировщикам может не хватить опыта, времени или ресурсов. Иногда в проекте поджимают сроки, и команда может пожертвовать какими-то этапами проверки. 

Иногда это может быть оправдано, если продукт предполагается использовать только на какой-то одной платформе, например только iOS или только Android. Тогда на других платформах могут быть баги, но это не доставит компании непредвиденных проблем.

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

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

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

Изменения в требованиях. Если проект часто меняется, за кодовой базой сложно уследить. Разработчикам нужно переписывать программу, менять технологии, подстраиваться под новые условия.

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

Последствия багов

Неисправленные баги вредят компании несколькими способами.

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

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

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

Поиск и исправление багов

Бороться с багами можно разными способами.

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

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

Вот несколько таких инструментов.

Что такое баг-репорт

Когда тестировщик нашёл баг, ему нужно подробно его описать, записать, как всё должно работать, и отдать эту инструкцию разработчикам, чтобы они всё поправили. Этот документ называется bug report.

Оформление баг-репорта зависит от компании, но большинство шаблонов будет включать несколько пунктов, которые помогут программистам найти и устранить баг.

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

Пример: «При попытке открыть ссылку из всплывающей подсказки получаем ошибку 400».

Проект и версия — название проекта, в котором содержится баг, и версия программы, где он был найден.

Серьёзность — оценка серьёзности от тривиальной до блокирующей.

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

Ожидаемый результат. Это то, как программа должна работать без бага.

Фактический результат. Это то, как всё работает сейчас.

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

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

Приоритет по принятой в компании шкале для понимания, когда нужно приступать к исправлению.

Bug report должен быть понятным тем, кто будет с ним работать. Поэтому при составлении тестировщику следует позаботиться о том, чтобы донести свою мысль понятно. Нужно изложить всю информацию, которая может помочь исправить ошибку, и добавить имеющиеся материалы.

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

Жизненный цикл бага

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

Статус бага обычно отслеживается в таск-трекере, когда карточка с ним перемещается по разным колонкам жизненного цикла.

Открыт. Тестировщик нашёл баг и заводит баг-репорт. 

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

Определение статуса. Если баг допустим, то его статус может поменяться на «Закрыт» или «Отложен». Если разработчики и аналитики подтвердили, что это действительно баг, задаче присваивают статус «В работе».

В работе. Разработчики получилили баг-репорт и приступили к исправлению бага.

Повторное тестирование. Тестировщик проверяет, решена проблема или нет. Если баг требует повторной доработки, он снова получит статус «В работе».

Закрыт. Баг исправлен в соответствии с требованиями баг-репорта.