Баг - то, чего при правильно выполненных условиях быть не должно

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

К примеру, вы обновили приложение любимой доставки еды и отправили в корзину ненужный товар. При попытках удалить его ничего не происходит – он остается с вами навсегда, и теперь вы не сможете пересобрать заказ (потому что у вас один аккаунт, где сохраняется корзина), да к тому же останетесь злым и голодным. Конечно, можно забить на свою ошибку, если ненужный товар стоит 30 рублей. А если 500? К тому же, следующий заказ пройдет не менее весело!
Баг ли это? Однозначно. Причем довольно неприятный, ведь из-за нарушения работы корзины вы, скорее всего, разоритесь на своей невнимательности, а при самом плохом сценарии - уйдете к конкурентам.

Или, возьмем более весомый пример. На конвейерном производстве автомобилей произошел сбой вспомогательного оборудования, и определенная деталь была собрана неправильно и встроена в целую партию машин. Вскрылось это только покупателями, которые стали жаловаться. Хорошо, если проблема будет связана с фарами или дворниками, и никто не пострадает – такие вещи легко исправляются в автосалоне. Представьте, если массово станут отказывать тормоза?
Баг ли это?
Еще какой! Такие вещи могут стереть репутацию и уничтожить бизнес. Если в первом случае мы столкнулись с голодными клиентами доставки, что исправляется одним обновлением, то второй пример касается производственной проблемы, потенциально угрожающей жизни водителей бракованных автомобилей.
Вот и получается, что баги встречаются нам довольно часто и в любой сфере. Теперь, когда мы выяснили их примерную бытовую этимологию, время поговорить об их значении для мира разработки ПО.

По сути, миру не обойтись без багов, ведь вокруг постоянно идут процессы отладки и улучшения. Как известно каждому тестировщику, исчерпывающие тестирование невозможно, а согласно одному из принципов QA под жутким названием “парадокс пестицида”: если багов не обнаружено, то это не означает, что их нет!
Конкретно в разработке баги - незаменимый атрибут качества, который показывает отношение команды к своему детищу. Кто-то пытается справиться без отдела тестирования (помянем), кто-то держит в штате целую гору QA, неизменно одно – чем внимательнее ты относишься к ошибкам и превентивным сценариям их предотвращения, тем более ты близок к если не идеальному, то отличному результату: доверию юзеров, большой пользовательской базе и новым горизонтам масштабирования.

Помимо классического бага, мы знаем и другие термины, обвиняющие программу в некорректной работе. Если баг (он же дефект) – это любое поведение, не совпадающее с требованиями, то существую его более масштабные производные, которые всегда сопровождают нас на пути к идеальному продукту:
Сбой - ситуация, когда приложение не может функционировать, как задумано.
Отказ - совокупность багов, приводящая к прекращению работы.
Кстати, багом не обязательно должно быть поведение. Это также лексические, синтаксические, логические и остальные виды ошибок программы.

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

Серьезность - степень влияния задачи/бага на систему в целом; от блокеров до минорных (не ломает функционал). Блокеры можно сравнить с закрытой комнатой без окон, от которой ты потерял ключ – ситуация безвыходная; как и у пользователя, который не может зарегистрироваться, или оплатить покупку в интернет-магазине, то есть – приложение/сайт не выполняет свое прямое назначение. Минорные баги не несут какой-то опасности для бизнеса/системы. К примеру, это может быть кривая (но работающая) кнопка, либо опечатка в тексте. Серьезность может задаваться тестировщиками или иными техническими специалистами, которые могут охарактеризовать проблему согласно ее влиянию на ПО.

При этом, существуют ситуации, когда может выставляться высший приоритет и низкая серьезность, или наоборот. Для примера далеко не пойдем – на главной странице сайта, куда ежедневно заходят тысячи пользователей, съехала верстка объекта. Баг не влияет на бизнес-процессы, но заметен КАЖДОМУ и вполне может заставить сомневаться в компетентности тех, кто этим сайтом владеет. Если же говорить о низком приоритете и критической серьезности, это может быть давно забытый функционал, которым пользуются крайне редко в Богом забытой части приложения… но его все равно, когда-нибудь, хорошо бы исправить!

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

Цикл этот обычно описывает порядок миграции баг-репорта между статусами за все время своего существования. При заведении бага он может быть закрыт – и погибнуть, потому что такой баг уже есть в трекере или исправлен накануне, либо открыт и отложен по причине наличия более серьезных задач. Но если все хорошо, баг попадает к разработчику, фиксится и отправляется на повторный тест, и в случае успешного ретеста – закрывается. Или… или будет ходить по всем кругам ада между QA и разработчиком, пока они не удостоверятся, что действительно все исправили! Учитывая факапы некоторых компаний, на этом сценарии вполне можно было бы создать вечный двигатель.

Баги - разнообразны и необходимы! Они помогают, бесят и повергают в ужас. Показывают наши слабые стороны и преумножают сильные. Бьют жадные корпорации по лицу и гладят те, что заботятся о качестве. Иного не дано, по-другому никак.
А чтобы досконально разобраться в их гибкости и величии, ты можешь пройти наши стажировки с обучением. Там мы копаемся в теории и точим практические навыки на реально существующем проекте, после которого будут открыты дороги к такой профессии, как тестировщик, или QA Engineer.