Почему в вашем приложении баги — и почему это нормальнее, чем вы думаете

Недавно один из заказчиков позвонил мне в субботу вечером. «Дмитрий, у нас баги, ничего не работает!» — сказал он так, будто сообщал о пожаре в серверной.

Баг оказался косметическим: кнопка "Выйти из профиля" нае срабатывала, если тапнуть на текст в кнопке. Но сам разговор натолкнул меня на мысль, которую я давно хотел проговорить вслух.

Почему в приложениях есть баги — и почему в IT-индустрии к этому относятся совсем иначе, чем заказчики?

Давайте начнём с неудобной правды: в любом программном продукте есть баги. В iOS есть баги. В Android есть баги. У Google, Apple и Microsoft есть баги, и они выпускают обновления каждые пару недель именно поэтому.

Это не вопрос компетенции разработчиков — это природа сложных систем.

Мы в Else Digital за последние годы выпустили десятки мобильных приложений, чат-ботов, веб-порталов. И я могу сказать прямо: не было ни одного проекта, где на этапе тестирования не нашлось бы ни одного бага. Ни одного.

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

Почему в приложениях есть баги — вопрос, который звучит просто, но ответ на него многослойный. Вот основные причины, которые я вижу в реальных проектах.

Первое — сложность взаимодействий. Даже среднее мобильное приложение содержит 20–40 экранов, каждый из которых может находиться в нескольких состояниях. Умножьте это на разные версии ОС, размеры экранов, скорость интернета, и получите тысячи комбинаций, которые невозможно проверить вручную.

Второе — человеческий фактор. Код пишут люди. Даже лучший разработчик с 10-летним опытом допускает ошибки. В одном нашем проекте для логистической компании senior-разработчик случайно перепутал координаты широты и долготы в одной функции. Результат? Курьеры на карте «телепортировались» в океан. Мы поймали это на ревью кода за 10 минут, но баг моб бы уйти в прод. В Umed приложения ходят в старый Битрикс через отдельный API-слой: так изменения на сайте не ломают мобильные сценарии, а починка одной части не задевает другую.

Третье — меняющиеся требования. Заказчик просит одно, потом уточняет, потом меняет. Это нормально — бизнес живой. Но каждое изменение может затронуть уже работающий функционал. Это классическая проблема регрессии.

Я раньше думал, что клиентам нужно просто объяснить, что баги бывают. Но со временем понял — проблема в том, что люди воспринимают любой баг как катастрофу, хотя в IT мы делим их на категории.

Критический баг — приложение падает, данные теряются, платёж не проходит. Такое должно фикситься в часы. В нашей практике критические баги составляют менее 5% от всех найденных проблем, и мы закрываем их максимально быстро.

Серьёзный баг — функция работает, но не так, как ожидалось. Например, фильтр товаров не учитывает одну категорию. Это неприятно, но не блокирует пользователя.

Косметический баг — тот самый сдвиг кнопки на два пикселя. На работу приложения не влияет, но перфекционистов раздражает.

Когда один наш заказчик из медицинской сферы запускал приложение для записи пациентов, мы нашли на тестировании 47 багов. Звучит страшно? Из них критических было два, серьёзных — восемь, остальные 37 — косметика и мелкие нестыковки в текстах.

Всё критичное починили до релиза, остальное — в первом обновлении через неделю.

Раз уж почему в приложениях есть баги — вопрос без простого ответа, расскажу, что реально работает на практике.

Код-ревью. Каждый кусок кода проходит проверку другим разработчиком. Это ловит около 60–70% ошибок ещё до тестирования. Тот баг с координатами из логистического проекта — классический пример.

Автоматические тесты. Мы пишем unit-тесты на критичную бизнес-логику. Не на каждую строчку — это дорого и часто бессмысленно, — а на то, что ломать нельзя: платежи, авторизацию, работу с данными.

QA-тестирование на реальных устройствах. Эмуляторы хороши, но не идеальны. У нас в офисе набор из 6 устройств разных производителей, на которых мы проверяем каждый релиз.

Бета-тестирование. Перед публичным запуском мы раскатываем приложение на ограниченную аудиторию — обычно 50–100 человек. Они находят то, что пропустили тестировщики, просто потому что используют приложение «по-своему».

Мониторинг после релиза. Мы подключаем системы аналитики крашей и следим за ними первые две недели после запуска особенно внимательно. Если что-то летит — реагируем сразу.

Признаюсь: лет пять назад я и сам считал, что можно довести продукт до идеала перед релизом, если просто побольше тестировать. Сейчас я знаю, что это ловушка.

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

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

С тех пор моя позиция: лучше запустить быстрее с хорошим качеством и быстро реагировать, чем гнаться за иллюзией совершенства.

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

Профессионализм разработчика проявляется не в отсутствии багов, а в том, как он с ними работает: как быстро находит, как приоритизирует, как общается с заказчиком.

Когда вы выбираете команду для разработки, спросите не «будут ли баги», а «что вы делаете, чтобы их было меньше, и как быстро вы их чините».

Если вам ответят «у нас багов не бывает» — бегите. Это либо ложь, либо некомпетентность.

Если хотите обсудить ваш проект с командой, которая честно говорит о рисках и умеет с ними работать — напишите нам в Else Digital. Мы не обещаем идеальный код, но обещаем прозрачный процесс и быструю реакцию.