Привет! Мы тестировщики платформы «Свое Родное» от Россельхозбанка. В статье расскажем о нашем проекте, как проводят релизы и регрессы, а также затронем актуальную тему работы приложений — обработку ошибок, а именно ошибку «Что-то пошло не так», которая встречается повсеместно.

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

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

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

Методология маркетплейса

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

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

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

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

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

Проблема ошибок

Как часто пользователю встречаются непонятные реакции приложений на сбои или недоступность сети?

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

Принято использовать следующие шаги для развития в этом направлении:

1.         Внедрение логирования ошибок (какое было сообщение об ошибке, дата, время, IP пользователя, дополнительные данные);

2.         И мы, и пользователь должны быть оповещены об ошибке: понятное сообщение с описанием проблемы (win-win для всех участников);

3.         Что делать с этой ошибкой — предоставлять альтернативное решение. Если приложение не работает — предложить перейти в веб версию или же оформить заказ частично и с записью логов;

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

5.         Повторное тестирование и использование предыдущего опыта по возникновению ошибок в регрессе.

Поподробнее разберем второй шаг — оповещение пользователя об ошибках в приложении.

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

У меня всего лишь был включен авиарежим
У меня всего лишь был включен авиарежим
Ещё один вариант отображения ошибки при включенном авиарежиме
Ещё один вариант отображения ошибки при включенном авиарежиме

Что было раньше? Если не функционировал какой-то незначительный модуль/пакет данных, то блокировалась работа всего приложения и на экране появлялось оповещение «Что-то пошло не так».

И как пользователь мог понять, что именно пошло не так?
И как пользователь мог понять, что именно пошло не так?

Что сейчас? Благодаря плотной работе со стороны разработчиков, аналитиков и нашей команды QA-инженеров, спустя 3 месяца удалось поставить на поток грамотный обработчик ошибок. Концепция выглядит следующим образом: добавляется фича — тестируется внедрение — проверяем реакцию приложения, когда эта фича недоступна.

 Разберем на примере. Чаще всего в этом помогает сниффер Charles. Блокируем запрос через breakpoints и запускаем приложение, после чего наблюдаем за реакцией.

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

Обвал запроса к сторис
Обвал запроса к сторис
Обвал запроса на просмотр списка фермеров в блоке «Наши фермеры»
Обвал запроса на просмотр списка фермеров в блоке «Наши фермеры»
Обвал запроса на просмотр вопросов и ответов фермеру
Обвал запроса на просмотр вопросов и ответов фермеру
Обвал запроса на отправку вопроса фермеру
Обвал запроса на отправку вопроса фермеру

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

Подход Graceful degradation

Существует подход, известный как Graceful degradation. Заключается он в том, чтобы при возникновении каких-либо проблем (на стороне сервера или клиента), приложение продолжало работать, но с ограниченной функциональностью. Благодаря этому подходу улучшается пользовательский опыт и уменьшается негативное воздействие на работу приложения.

Точки роста для развития нашего приложения по подходу Graceful degradation:

1) внедрение иных способов выполнения различных функций (отправка обратной связи, отзыва о продавце, оформления заказа). Если на сервере присутствует проблема, то на момент оформления заказа пользователь перенаправляется на страницу с ограниченным функционалом, где работа сервера не задействована;

2) определение критических функций, в которых необходим подход graceful degradation. Это поможет установить пороговые значения, при достижении которых функциональность приложения может быть ограничена;

3) тщательное тестирование и отладка данной реализации. Включает не только регресс в части работы приложения, но и API тестирование;

4) предупреждение пользователей о возможных проблемах и ограничениях, что повысит уровень доверия;

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

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

 

 

Комментарии (0)