Каждый программист знает: даже в самых небольших программах есть ошибки — баги. Это ошибки могут иногда проскальзывать незамеченными и появляться в самых невероятных местах.
История обнаружения бага может быть разной: на него случайно натыкается обычный пользователь, либо программист или тестировщик. И как сигнал тревоги, баг поступает в “баг-репорт” для исправления.
Баги — как капризные дети, каждый из них уникален и поведение их не всегда предсказуемо. Они могут показаться только определенным пользователям или в определенных условиях.
Иногда то, что мы принимаем за баг, на самом деле является просто непониманием того, как программа должна работать. Например, пользователь может запутаться в интерфейсе и решить, что это ошибка программы. Это момент, когда разработчики должны задуматься: может быть, им стоит улучшить интерфейс и сделать его более дружелюбным?
Когда баг наконец подтвержден и получает статус "открытый", начинается настоящая работа. Разработчики решают, насколько срочно нужно это исправить. Может, стоит сделать "хотфикс" и поправить сразу? И когда баг наконец исправлен, он переходит на новый этап своего "жизненного цикла" — становится "исправленным". Если исправление прошло успешные тесты, баг закрывается.
Но история бага может быть не такой простой. В реальности все намного сложнее и запутаннее. Иногда, даже после исправления, словно призрак из прошлого, баг может вернуться — и тогда его статус меняется на "переоткрытый".
Безусловно, подобное решается внедрением тестов, но на практике, по разным причинам, далеко не все проекты используют тесты и ограничиваются “ручным” тестированием, вместо автоматизированного. Понимание "жизненного цикла" бага помогает разработчикам быстрей находить ошибки и делать программное обеспечение еще лучше.