Баги – ошибки, возникающие в работе приложения. Это зависания, ошибки транзакций и загрузок, внезапные отказы, проблемы с сохранением и пр. По багам традиционно много вопросов. В этой статье мы ответим на основные: откуда и почему появляются баги, кто виноват, если в готовом приложении обнаружилась ошибка и что с этим делать.
Почему нельзя сразу написать код без ошибок?
Потому что мы живем не в мире розовых пони. Ошибаются все: портные и швеи, повара и кондитеры, политики и военные. Тем более, мобильная разработка представляет собой сложную комплексную систему с сотнями элементов, блоков и составных частей. И чем такая система масштабней, тем выше шанс, что какая-то из этих частей где-то засбоит. Похоже на реальный мир – если участников много, договориться становится сложнее или невозможно.
Кроме того, при разработке приложения разработчик может иметь дело с элементами, с которыми ранее он не сталкивался. Соответственно, нельзя предугадать как неизвестный код будет вести себя в приложении.
Во всех ошибках виноваты разработчики?
Не всегда. Баги могут возникать на стороне сервиса, с которым интегрировано приложение и разработчик просто не сможет повлиять на них. К примеру, все еком-приложения связаны с работой платёжных систем – пользователь переходит на страницу банка и вводит свои данные для оплаты. И если в работе платежного шлюза случится ошибка, оплата не пройдет.
Разработчик приложения не виноват. Виноват банк. Все, что может сделать разработчик – сообщить в технический отдел банка и ждать решения проблемы.
Разве нельзя найти все баги автоматическим тестированием?
Можно, но чтобы покрыть весь код автотестами, нужно написать фактически два кода – код для приложения и код для тестирования. Это двойная работа с двойной оплатой. Возможно, «Сбер» с его бюджетами и может себе позвонить, но не обычный крупный и тем более средний бизнес.
Из автоматических вариантов для проверки приложений часто используется крашлитикс. Это инструмент отслеживания фатальных ошибок.
Программа/платформа показывает, на каких устройствах и при каких действиях приложение аварийно закрывается (происходит краш). Очень полезный инструмент, который подключается к процессу перед выпуском приложения в продакшн, при обновлении системы, появлении новых устройств.
Тестировщик нашёл баги в приложении, а разработчик их исправил. Почему ошибки на этом не заканчиваются?
Баги появляются и после тестов, и после выпуска приложения в магазины App Store и Google Play. Тестировщик не в силах предугадать все возможные сценарии поведения пользователя в приложении и сразу же их проверить. В мире тысячи моделей смартфонов плюс тысячи возможных действий, которые будет совершать человек в приложении. К тому же магазины приложений регулярно обновляют сертификаты, добавляют новые сервисы, так что приложения должны хорошо работать и с ними.
Все это приводит к появлению тех или иных багов после релиза. И к этому надо быть готовым. В багах нет ничего страшного. Главное оперативно исправлять отказы и доверять это техническим специалистам.
Как баги влияют на работу приложения
Все зависит от того серьёзная это ошибка или нет. Если мы говорим об уровне бага, довольно условно делим ошибки на 3 группы:
- Незначительные – мелкие ошибки, чаще остаются незамеченными пользователями приложений. Задержка загрузки на 1-2 секунды, временные перебои с приемом сети.
- Значительные – не мешают достижению главных функций приложений, но доставляют неудобства пользователям. Это когда залипают или неправильно отображаются шрифты, смещаются кнопки.
- Критические – ограничивают основные функции приложений и не дают пользователям воспользоваться предложением. К примеру, если в приложении кнопка «Оплатить» не откликается на нажатие – баг критический.
Какие баги в приложении исправляются в первую очередь
Приоритет ошибок определяет влияние ошибки на бизнес. Так что у критических ошибок далеко не всегда высокий приоритет.
Допустим, в мобильном приложении интернет-магазина пропала кнопка «Добавить в корзину» в категории шампуней. Это критическая ошибка, ведь пользователь не сможет купить товар. Если это единственная ошибка, ее исправят первой. Но когда одновременно с этой ошибкой обнаруживается смещение виджетов на главной, исправляют сначала виджеты. Баг, который бросается в глаза, снижает конверсию и портит имидж бизнеса, исправляется первыми. Ведь до шампуня доберутся не все, а вот проблему с главной увидит каждый.
Как исправлять чужие баги
Если приложение сделано плохо, после правки первых багов вылезают следующие, потом следующие и еще за ними. Со временем владельцу надоедает работать исключительно на исправление ошибок и он передает продукт на поддержку другой команде…Вернее, хочет передать. Потому что не каждая команда согласится поддерживать продукт, который дольше исправлять, чем сделать заново.
Исправлять чужие баги в приложении не любит никто. Иногда, чтобы поправить один баг, разработчикам приходится раскапывать несколько слоев кода и лечить десятки костылей. И не факт, что при следующем обновлении iOS или Android из-под оставшихся костылей не появится еще с десяток багов. Это неблагодарная, плохо оплачиваемая работа – «сизифов труд».
Что делать владельцу приложения, если обнаружил баг
После релиза мы держим приложение на гарантии и любой баг исправляется в приоритетном порядке. По окончании гарантийного периода несущественные ошибки исправляются в ближайшем плановом релизе.
Опыт показывает, что ошибки встречаются даже в хорошо написанном приложении. Баг – не катастрофа. Большую часть критичных багов отлавливают на этапе тестирования, а мелкие и несущественные убирают в плановом режиме. Это нормальная практика.