Как найти ошибку в приложении за 2-3 минуты: ускоряем отладку с помощью LogScope

Привет! На связи Creonit. Разрабатываем цифровые сервисы. 

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

Мы в Creonit специализируемся на автоматизации и оптимизации процессов, в том числе собственных.Сегодня рассказываем, как запустили LogScope — инструмент, который помогает находить проблемы в работе мобильного приложения без привлечения тестировщиков и разработчиков.

Что такое LogScope и для чего он нужен

LogScope — это система анализа работы мобильного приложения и пользовательского опыта в реальном времени. Она отслеживает все события в программном продукте — как на этапе разработки, так и в продакшене. 

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

С помощью сервиса любой участник команды разработки может найти проблему в цифровом продукте за 2-3 минуты без привлечения тестировщиков и разработчиков. У LogScope нет аналогов на российском рынке.

Чем LogScope полезен команде продукта и бизнесу

Используя LogScope на проекте:

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

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

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

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

Как обычно происходит отладка приложений

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

Обычно логи смотрят в IDE (Integrated Development Environment) — среде, где разработчики пишут код. Но они неструктурированные и содержат много информации, в которой сложно разобраться. Если человек не знает языков программирования, то данные в текстовых файлах ему ничего не скажут.

Пример лога из IDE

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

1. Развернуть проект.
2. Запустить его на эмуляторе.
3. Воспроизвести ошибку.

Поэтому классическая отладка происходит по следующей схеме: 

У этого сценария несколько ограничений:

1. Ошибка может не воспроизводиться у тестировщика или разработчика.
2. Команда тратит большое количество времени на всю цепочку действий — от 18 часов.

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

Возможности LogScope

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

1. С помощью номера телефона, email или логина юзера, сервис идентифицирует его проблему

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

Рассмотрим на примере, как это работает. 

Кейс

Проблема: в приложении интернет-магазина не работает функция «Добавить в избранное» — иконка не меняет цвет при нажатии. 

Решение: менеджер проекта открывает в LogScope сессию и смотрит, откуда идёт проблема — со стороны бэкенда или фронтенда. В событии видно, что пользователь нажимает на иконку, и в это время бэкенд не меняет значение поля. При этом фронтенд отправляет серверу запрос поменять значение. Значит, проблема на стороне бэкенда. 

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

2. Сервис показывает контекст взаимодействия пользователя с продуктом — его навигацию и выполняемые жесты

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

Кейс

Ситуация: по логам в LogScope видно, что пользователи, открывая приложение, делают нетипичные действия:

1. переподключаются с Wi-Fi на мобильный интернет;
2. повторно нажимают одни и те же кнопки;
3. заново открывают экраны.

Проблема: очевидно, что сервис не работает.

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

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

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

3. Обнаружение уникальных инцидентов, с которым столкнулся только один пользователь

Кейс

Проблема: пользователь оставляет приложению плохой отзыв в App Store с текстом, что не может открыть бонусную карту. 

Решение: с помощью номера телефона пользователя ищем его сессии в LogScope, изучаем их и находим причину ошибки. 

Итого: быстро нашли проблему у конкретного пользователя. После исправления ошибки клиенту можно отправить смс по номеру телефона с оповещением, что его запрос решён. Это повысит его лояльность.

Отладка с LogScope в два раза быстрее и дешевле классического подхода

Возможности LogScope ускоряют отладку в разы — больше не требуется привлекать несколько человек для решения одной проблемы.

Как итог — поиск и устранение ошибок становятся дешевле.

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

Как работает LogScope

После подключения LogScope собирает данные о работе приложения и группирует их на типы:

1. события;
2. ошибки;
3. пользовательские действия: нажатия кнопок, смену экранов, жесты;
4. сетевые запросы;
5. изменения переменных.

Благодаря этому информация о работе программы не выглядит как кусок непонятного текста — все данные структурированы и их можно фильтровать. 

В административной панели из логов собираются дашборды, в которых видны:

1. все устройства, на которых открывают приложение;
2. пользователи и их идентификационная информация;
3. сессии;
4. события;
5. проблемы.

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

Итого

LogScope в 2 раза снижает стоимость и сроки отладки приложения. С его помощью тестировщикам больше не нужно воспроизводить проблемы, а разработчикам искать исключения в коде. Менеджер проекта сам может найти ошибку и поставить задачу решить её. 

Ещё раз кратко о возможностях сервиса:

1. быстрое обнаружение ошибок любым специалистом продуктовой команды;
2. поиск уникальных проблем пользователей, даже если ошибка произошла всего на одном устройстве;
3. анализ поведения пользователей, с помощью которого можно заподозрить проблему, даже если в коде нет исключений.

В этой статье мы рассмотрели только часть преимуществ LogScope. В новых материалах расскажем о других функциях и планах на развитие инструмента.