Как клиенту принимать приложение у разработчиков
Аналитика
12.04.2023
В данной статье мы расскажем о важных моментах, на которые нужно обратить внимание, перед тем как принять приложение у команды разработки, а также о проблемах, которые могут возникнуть на финальных этапах.
Основные функции, которые нужно проверить в первую очередь
-
Оплата товаров и услуг через платежные сервисы - важный функционал, напрямую связанный с деньгами заказчика и пользователей приложения. Если не будет работать оплата, то основная цель бизнеса не будет выполнена. Сюда же относится реализация подписок на сервис (списаний денег с карты клиента с определенной периодичностью).
-
Работающая регистрация нового пользователя и корректная авторизация уже существующих. Важно, чтобы пользователи имели возможность пользоваться расширенными возможностями приложения, которые дает роль “авторизованный пользователь”, а у заказчика была реальная отслеживаемая статистика количества лояльных пользователей приложения.
-
Основные пользовательские сценарии использования. Один/несколько базовых сценариев, состоящих из шагов, которые будут проходить большинство пользователей приложения. Это самый критичный и ожидаемый заказчиком функционал, который приносит прибыль компании.
Примеры: Добавление товара в корзину, Оплата заказа, Просмотр каталога товаров (для интернет-магазина). Если в критичном функционале возникает ошибка, то это негативно влияет на пользовательский опыт и потенциальный клиент никогда не совершит целевое действие и не принесет прибыль компании-заказчику.
- Интеграция со сторонними сервисами. Важно проверить, что взаимодействие между системами работает корректно, в соответствие с документацией и требованиями. Здесь возникает очень большое количество багов, особенно если сервисы пишут разные команды разработчиков в разных компаниях. Поэтому данные моменты следует проверять с особой тщательность.
Проверяем второстепенный функционал приложения
Теперь рассмотрим тестирование второстепенной функциональности, которую можно отложить на потом. Второстепенная функциональность - эта та, которая напрямую не влияет на работоспособность приложения, это дополнительная функция, которая может быть полезна, но не является существенной для основной ценности.
- Адаптация WEB версии для мобильных телефонов. Актуально, если большинство пользователей будут пользоваться приложением с компьютеров и если заранее не были зафиксированы четкие требования к адаптивности. В ином случае адаптивность очень важна и ее стоит проверять.
- Переводы и локализация. Актуально, если приложение первоначально предназначено для пользователей на одном конкретном языке.
- Второстепенный функционал: добавление в избранное, заметки, визуальные “плюшки” - смена цветовой темы, размера шрифта. В целом, проверку мелких UI-моментов можно оставить на потом.
Основные возможные проблемы
- Разработка приложения занимает обычно 3-4 месяца. Дизайн и техническое задание (далее. ТЗ) создаются и согласовываются с Заказчиком на самых первых этапах.
Проблема: При тестировании Заказчик зачастую пишет список ошибок, которые на самом деле являются доработками. Основное отличие доработок от ошибок в том, что доработки не были обсуждены и согласованы на этапе формирования ТЗ и дизайна, а также не нарушают работу приложения. И при создании приложения, доработки не описаны и не переданы в разработку, следовательно их в приложении не будет.
Решение: Перед началом приемки/тестированием приложения просмотреть ТЗ и дизайн. Все что не входит в основное ТЗ нужно внести в отдельный список и согласовать стоимость и сроки доработок отдельно.
- Обсуждение изменений на этапе активной разработки.
Проблема: Часто бывает, что на созвонах или в личных переписках обсуждаются изменения требований. При этом эти изменения не фиксируются и не доносятся до всех участников проекта. Из-за этого, об этих изменениях могут забыть Заказчики и/или не знать команда разработки. Следовательно, при приемке могут быть следующие варианты: 1. Изменения не будут реализованы 2. При приемке приложения Заказчик обратит внимание, что были сделаны изменения, которые не зафиксированы в ТЗ/дизайне/документе с изменениями.
Решение: Создать общий документ, в котором будут фиксироваться все изменения требований с датой данного требования. При этом Заказчик как и команда разработки на всех этапах проекта регулярно просматривает данный документ, актуализирует его и отмечает выполненные изменения.
- Проекты с интеграцией готовой базы Заказчика (1С, Битрикс и тд)
Проблема: Команда разработки работает либо вообще без каких-либо данных для проверки интеграции, либо с данными в тестовой базе, которые не являются актуальными. Отсутствуют требуемые для правильной разработки поля, ответ приходит в некорректном виде. Часто бывает, что с тестовыми данными приложение полностью протестировано и работает правильно. Но при подключении реальной базы Заказчика возникают многочисленные трудности, и из-за этого разработчикам приходится разрабатывать “костыльные решения”, чтобы интегрироваться. В результате становится невозможно реализовать некоторые доработки приложения, появляется неожиданные баги.
Решение: При работах с интеграцией следует сделать свежий бекап реальной/актуальной базы, заранее предусмотреть возможность и удобство интегрирования, не оттягивать интеграцию на последний момент. Лучше всего тестировать на данных, максимально приближенных к реальным, тогда и количество пропущенных багов сократиться в разы.
- Заказчик увидел ошибку в работе приложения и передает ее команде разработки.
Проблема: Найденная ошибка описывается не полностью, часто не понятно, какой ожидаемый результат. Из-за этого увеличивается время на анализ и отлов ошибки, что увеличивает стоимость проекта.
Решение: Когда Заказчик увидел ошибку в работе приложения, описывать ее максимально подробно. Можно дополнительно приложить скрины/видео с шагами воспроизведения ошибки. Это максимально сократит время на тестирование и исправление.
В целом, разработка мобильного приложения или сложного сайта - это длительный и трудоемкий процесс, который необходимо контролировать на всех этапах работы. Опытные команды имеют тестировщиков, для своевременного выявления возможных проблем. Однако, клиенту лучше иметь представление, о сложностях, которые могут возникнуть. Надеемся, что этот материал был полезен для вас, еще больше полезных статей читайте в нашем блоге.