Ответы на вопросы про баги в приложении - Блог ТехноФабрика

Ответы на вопросы про баги в приложении

Ответы на основные вопросы про баги в приложениях
Чтение займет: 4 мин.

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

Почему нельзя сразу написать код без ошибок? 

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

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

Баги в приложении нельзя предугадать, но можно вылечить

Во всех ошибках виноваты разработчики? 

Не всегда. Баги могут возникать на стороне сервиса, с которым интегрировано приложение и разработчик просто не сможет повлиять на них. К примеру, все еком-приложения связаны с работой платёжных систем – пользователь переходит на страницу банка и вводит свои данные для оплаты. И если в работе платежного шлюза случится ошибка, оплата не пройдет.

Не во всех багах виноваты разработчики мобильного приложения

Разработчик приложения не виноват. Виноват банк. Все, что может сделать разработчик – сообщить в технический отдел банка и ждать решения проблемы. 

Разве нельзя найти все баги автоматическим тестированием? 

Можно, но чтобы покрыть весь код автотестами, нужно написать фактически два кода – код для приложения и код для тестирования. Это двойная работа с двойной оплатой. Возможно, «Сбер» с его бюджетами и может себе позвонить, но не обычный крупный и тем более средний бизнес. 

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

Крашлитикс как один из инструментов отлова багов

Программа/платформа показывает, на каких устройствах и при каких действиях приложение аварийно закрывается (происходит краш). Очень полезный инструмент, который подключается к процессу перед выпуском приложения в продакшн, при обновлении системы, появлении новых устройств. 

Тестировщик нашёл баги в приложении, а разработчик их исправил. Почему ошибки на этом не заканчиваются?

Баги появляются и после тестов, и после выпуска приложения в магазины App Store и Google Play. Тестировщик не в силах предугадать все возможные сценарии поведения пользователя в приложении и сразу же их проверить. В мире тысячи моделей смартфонов плюс тысячи возможных действий, которые будет совершать человек в приложении. К тому же магазины приложений регулярно обновляют сертификаты, добавляют новые сервисы, так что приложения должны хорошо работать и с ними. 

Все это приводит к появлению тех или иных багов после релиза. И к этому надо быть готовым. В багах нет ничего страшного. Главное оперативно исправлять отказы и доверять это техническим специалистам. 

Как баги влияют на работу приложения 

Все зависит от того серьёзная это ошибка или нет. Если мы говорим об уровне бага, довольно условно делим ошибки на 3 группы:

  1. Незначительные – мелкие ошибки, чаще остаются незамеченными пользователями приложений. Задержка загрузки на 1-2 секунды, временные перебои с приемом сети.
  2. Значительные – не мешают достижению главных функций приложений, но доставляют неудобства пользователям. Это когда залипают или неправильно отображаются шрифты, смещаются кнопки.
  3. Критические – ограничивают основные функции приложений и не дают пользователям воспользоваться предложением. К примеру, если в приложении кнопка «Оплатить» не откликается на нажатие – баг критический. 

Какие баги в приложении исправляются в первую очередь 

Приоритет ошибок определяет влияние ошибки на бизнес. Так что у критических ошибок далеко не всегда высокий приоритет. 

Допустим, в мобильном приложении интернет-магазина пропала кнопка «Добавить в корзину» в категории шампуней. Это критическая ошибка, ведь пользователь не сможет купить товар. Если это единственная ошибка, ее исправят первой. Но когда одновременно с этой ошибкой обнаруживается смещение виджетов на главной, исправляют сначала виджеты. Баг, который бросается в глаза, снижает конверсию и портит имидж бизнеса, исправляется первыми. Ведь до шампуня доберутся не все, а вот проблему с главной увидит каждый. 

Не каждый баг - проблема

Как исправлять чужие баги 

Если приложение сделано плохо, после правки первых багов вылезают следующие, потом следующие и еще за ними. Со временем владельцу надоедает работать исключительно на исправление ошибок и он передает продукт на поддержку другой команде…Вернее, хочет передать. Потому что не каждая команда согласится поддерживать продукт, который дольше исправлять, чем сделать заново.

Исправлять чужие баги в приложении не любит никто. Иногда, чтобы поправить один баг, разработчикам приходится раскапывать несколько слоев кода и лечить десятки костылей. И не факт, что при следующем обновлении iOS или Android из-под оставшихся костылей не появится еще с десяток багов. Это неблагодарная, плохо оплачиваемая работа – «сизифов труд». 

Что делать владельцу приложения, если обнаружил баг

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

Опыт показывает, что ошибки встречаются даже в хорошо написанном приложении. Баг – не катастрофа. Большую часть критичных багов отлавливают на этапе тестирования, а мелкие и несущественные убирают в плановом режиме. Это нормальная практика. 


Полезные ссылки

Добавить комментарий

Ваш адрес email не будет опубликован.