Когда что-то пошло не так: что расскажут экраны тестировщику
Привет! Мы тестировщики платформы «Свое Родное» от Россельхозбанка. В статье расскажем о нашем проекте, как проводят релизы и регрессы, а также затронем актуальную тему работы приложений — обработку ошибок, а именно ошибку «Что-то пошло не так», которая встречается повсеместно.
Маркетплейсы продуктов становятся популярными среди покупателей, поэтому перед нашей командой стоит серьезная задача — неустанно улучшать нашу платформу для того, чтобы покупки совершались с удовольствием, а пользователи возвращались вновь и вновь.
Свое Родное — это маркетплейс натуральных фермерских продуктов, позволяющий приобретать продукцию по всей России. Платформа существует с 2020 года, на текущий момент её ежедневно посещают более 200 новых пользователей и оформляют 2000 заказов.
Историю создания платформы можно посмотреть в первом документальном выпуске. Узнайте об идеях, технологиях и сложностях, с которыми столкнулась команда при создании и тестировании продукта.
Пользоваться нашим маркетплейсом можно как через сайт, так и через мобильное приложение, а все фичи внедряются синхронно.
Методология маркетплейса
Мы используем 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) непрестанный анализ и мониторинг работы приложения и работа с логами. Безусловно, это сможет помочь оперативно выявлять и устранять проблемы и развивать гибкую и устойчивую систему работы.
Нами был пройден долгий путь построения грамотного отклика приложения на заблокированные запросы. Впереди у нашей команды ещё длинный и интересный путь. От всплывающих экранов «Что-то пошло не так» однозначно нужно уходить, чтобы дать пользователям более приятный опыт в работе с приложением.
