Что такое баг и как с ним бороться
Содержание
Что такое баг?
В современном мире 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 — никогда не исправлять, например, баги найдены в уже не поддерживаемом продукте.
Как избежать появления багов?
Можно ли избежать появления багов? Это практически невозможно. Любая ошибка — это опыт. Главное своевременно ее заметить и исправить.
Внимательность к деталям, хорошее знание языка программирования и написание тестов — вещи, существенно облегчающие работу.
Заключение
Избежать появления багов не получится — разработчик не в состоянии все предусмотреть. Для этого в командах всегда есть тестировщики, которые работают с программистами в плотной связке.
Чтобы упростить себе работу и меньше переписывать код после ревью тестировщиков, многие разработчики сразу покрывают код автотестами.
Сообщить об опечатке
Текст, который будет отправлен нашим редакторам: