Баги — это норма: как в приложениях возникают ошибки и почему их не нужно бояться

1. А что такое баг? Объясните понятно.

В своей основе мобильное приложение — это код. Баг — это ошибка в коде. Из-за неё приложение ведёт себя некорректно, например зависает, вылетает или не откликается на действия пользователя.

Неправильное поведение — закономерный ответ на ошибку. Представьте, что вы написали сложную инструкцию с большим количеством шагов, и в шаге № 404 непонятно объяснили, что делать. Из-за этого человек, который будет следовать инструкции, никогда не придёт к правильному результату. Так же и приложение. Оно не поймёт, как себя вести, если в его «инструкции» есть ошибка.

2. Ну, а разве нельзя сразу писать код без ошибок?

Это возможно только в идеальном мире. А в нашем — нет. Приложение — сложная комплексная система, разработка которой делается долго и стоит дорого. С каждым новым элементом взаимодействие её частей усложняется, и это приводит к возникновению ошибок в мобильном приложении. Всё как в общении: чем больше людей, тем сложнее договориться. Разработчик «соединяет» разные элементы в единый код. Если элемент неизвестный (сторонняя библиотека или сервер, с которым на проекте ещё не работали), разработчик не сможет предвидеть, получится ли у этого элемента найти «общий язык» с существующими частями кода.

К тому же ошибки могут появляться из-за банальных «опечаток» в коде мобильного приложения. Написание кода можно сравнить с набором сообщения. Мы делаем это каждый день, но всё равно ошибаемся. По десять раз перечитываем текст и замечаем опечатку, только когда отправили сообщение собеседнику. От этого не страхует ни проверка орфографии, ни Т9. Все мы люди и не можем быть сконцентрированы 24/7.

Вот и разработчик может не заметить свою ошибку. Тем более, что обычно в коде мобильного приложения около 150-ти тысяч строк, и уследить за всеми знаками невозможно.

3. Получается, что ошибки возникают из-за разработчика?

Это не так. Ошибка в приложении может произойти и на стороне интегратора — стороннего сервиса, с которым приложение «сотрудничает». Разработчик не сможет её предотвратить, потому что она находится вне зоны его влияния.

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

Ориентируясь на ответ банка, приложение скажет пользователю: «Поздравляем! Покупка завершена» или «Упс, что-то пошло не так». Если что-то не так, то значит проблема на стороне интегратора. Единственное, что могут сделать мобильные разработчики в этом случае — «постучаться» в отдел техподдержки шлюза и предупредить о сбое.

Появление ошибок — естественный и закономерный процесс в разработке приложений. И разработчик к этому готов. За свои баги он отвечает сам: не только знает, что ошибки будут, но и знает, как их искать. Для этого разработчик пишет автотесты — части кода, которые имитируют взаимодействие пользователя и приложения. Разработчик проверяет написанный код с помощью автотестов, исправляет очевидные ошибки и продолжает работу.

4. Так если разработчик всё проверяет, то почему мы вообще об этом говорим?

Автотестов недостаточно для полной проверки. Они покрывают только формальный алгоритм работы, но не могут воспроизвести поведение и мотивацию «живого» пользователя. Это может сделать только человек. Поэтому проверкой пользовательских кейсов в команде занимается другой специалист — QA-инженер, или тестировщик.

Проверяя приложение, тестировщик находится в роли пользователя: открывает приложение и совершает те же шаги, которые, предположительно, должен проделать человек, установивший приложение.

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

5. Отлично! Тестировщик нашёл все баги, разработчик их починил — можно расслабиться.

Подождите, не всё так просто. Нужно быть готовым к тому, что баги будут обнаружены не только во время разработки приложения, но и после релиза, то есть когда приложение появится в сторе — магазине приложений, например в App Store или Google Play.

Такое происходит потому, что мы не можем покрыть все пользовательские сценарии, как бы ни старались. Мобильных устройств — очень много. Действий, которых человек совершает в приложении, тоже. Количество смартфонов, умноженное на количество действий, даёт безграничное пространство для возникновения ошибки. И нет героя, который смог бы разобрать все эти кейсы. Поэтому лучше заранее подготовить себя к тому, что в мобильном приложении будут возникать ошибки, и позволить студии разработки их исправить.

6. А как баг может повлиять на работу приложения?

Зависит от такого, насколько этот баг серьёзен. Условно ошибки, которые выдаёт приложение, можно разделить на три вида: критические, значительные и несущественные.

Критические баги мешают человеку использовать приложение. Они блокируют основную функцию приложения и не дают ему работать на бизнес-цель клиента. Значительные баги для бизнес-цели не опасны, но они могут доставлять человеку неудобства в использовании приложения. А несущественные баги — это мелкие нарушения, которые пользователь не может заметить. Вот так это выглядит на примере приложения-магазина:

• Если кнопка «Оплатить» не работает — это критический баг: он мешает приложению продавать, то есть выполнять функцию, ради которой приложение разработали.
• Если кнопка «Оплатить» располагается не по центру, как должна, а слева, и её край некрасиво выходит за рамки экрана, но пользователь всё ещё может на неё нажать — это значительный баг.
• Если на экране заказа кнопка «Оплатить» серого цвета, а не чёрного, как задумывали дизайнеры, — это несущественный баг.

7. И что делать, если в моём приложении произошла ошибка?

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

8. Хорошо, значит критический баг починят первым?

Не совсем так. Чтобы понять, какую ошибку приложения удалять в первую очередь, нужно определить не только серьёзность бага, но и его приоритет: средний низкий или высокий.

У критического бага не всегда будет высокий приоритет. Представим, что пользователь не может добавить в корзину штаны, потому что у этой категории товаров сломалась кнопка «В корзину». Если пользователь не может добавить штаны в корзину, значит, он не может их купить. Это критический баг, который нужно чинить. Но в то же время на главном экране приложения есть другая проблема — название магазина написано с опечаткой. Это значительный баг, но приоритет у него выше. Сейчас объясним почему.

Не всем прямо сейчас надо покупать штаны, поэтому до этой категории товаров доберутся не все пользователи. Да, баг снизит продажи, но не убьёт их полностью. Значит, у разработчиков будет временной буфер для решения этой проблемы. А вот опечатку в имени бренда на главном экране заметят все. Это сильный удар по имиджу компании. Он повлияет на отношения покупателей к магазину и отобьёт у многих желание пользоваться приложением. В итоге конверсия в приложении упадёт.

9. Значит я могу не бояться багов?

Именно так. К разработчику баги приходят как данность. Мы ожидаем их и знаем, как их исправить. И рассказываем об этом клиентам. Иногда они тоже могут побыть в роли тестировщика — мы отдаём им готовую сборку перед релизом, чтобы они сами убедились, что приложение в порядке.

10. А если я передам приложение на поддержку другой команде?

Чинить чужие баги сложнее. Дело в том, что чем дольше разработчики работают на конкретном проекте, тем глубже они погружены в его контекст и тем быстрее сориентируются, если обнаружат ошибку. Новым разработчикам придётся изучать всё с нуля. Но опытная команда, в которой налажена коммуникация и рабочие процессы, может быстро понять новый проект. Если вы ищете студию мобильной разработки на поддержку — звоните +7 495 204-35-03 или пишите нам. Спасать ваше приложение от ошибок — наша работа.