Что такое баг и как с ним бороться

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

В современном мире nothing is perfect — ничто не безупречно. Мелочь, влияющая на фидбек от пользователя или существенная проблема, замедляющая разработку?

Да, сегодня мы поговорим о багах. Что это такое и почему его обязательно нужно фиксить? Будем разбираться.

С технической точки зрения баг — это ошибка, возникающая при разработке программного обеспечения (ПО).

Баг — от английского bug, то есть «жук». Осенью 1947 года инженеры Гарвардского университета никак не могли понять, в чем причина поломки ЭВМ Mark II, пока не обнаружили застрявшего между контактами реле мотылька. Один из них записал в документации это как «Первый случай обнаружения бага». Таким образом с тех пор ошибки выполения ПО стали называть багами.

Как же с ними бороться? Во-первых, воспроизведите баг и убедитесь в том, что вам понятно, в каком случае он возникает. После этого можно начинать работу с кодом.

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

Чтобы проверить, что баг исправлен и ничего нового в процессе не сломалось, нужно будет провести автоматические или мануальные тесты.

Алгоритм исправления бага выглядит следующим образом:

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

Почему возникают баги?

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

К вышеперечисленным причинам добавим следующие:

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

Давайте немного подробнее поговорим о каждой из причин, приведенных выше.

Невнимательность при написании кода

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

Пример: вся команда не могла понять, почему не работает текст, проверяли в поле значение Сontact. При проверке кода теста (с включенным spellchecker) обнаружили, что буква «С» написана кириллицей.

В примере ниже в missKey пропущена буква «s»:

В таких случаях на помощь придут:

• анализаторы кода;
• проверка кода;
• парное программирование.

Непонимание логики кода

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

Если возможности связаться с автором кода нет, можно задействовать тесты. Также брейншторм с менеджером проекта или QA — хорошая альтернатива.

Непонимание особенностей языка программирования

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

К примеру, для входного параметра value = 10 условие будет выполняться. Нужно добавить сравнение ===.

Тесты

Как мы уже писали выше, тесты делятся на мануальные и автоматизированные.

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

Иногда таких специалистов называют «манки-тестерами»От англ. monkey — обезьяна, как бы намекая на то, что подобная работа вроде как не слишком интеллектуальна, хотя на самом деле это не так.

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

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

Автотестер должен уметь:

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

Отсутствие взаимодействия с ошибками

Чтобы познать дзен и научиться эффективно взаимодействовать с багами, нужно уметь обезопасить свой код от внешнего воздействия:

• проверять входящие параметры;
• обрабатывать исключения;
• применять паттерн Null-object.

Копирование чужих ошибок

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

Классификация багов: какими они бывают?

Существуют две главные классификации багов: по степени критичности и приоритетности.

По степени критичности можно выделить следующие баги:

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

По приоритетности выделяют баги:

• fix in release — можно исправить в новой версии продукта. Как правило, это баги, обнаруженные при тестировании нового функционала системы.
• must fix — срочно исправить. Часто это блокирующие баги, устраняющие выход новой версии в специальном сервисном пакете.
• fix if time — исправить, если позволяет время.
• never fix — никогда не исправлять, например, баги найдены в уже не поддерживаемом продукте.

Как избежать появления багов?

Можно ли избежать появления багов? Это практически невозможно. Любая ошибка — это опыт. Главное своевременно ее заметить и исправить.

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

Заключение

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

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