Как клиенту принимать приложение у разработчиков

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

Основные функции, которые нужно проверить в первую очередь

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

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

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

Примеры: Добавление товара в корзину, Оплата заказа, Просмотр каталога товаров (для интернет-магазина). Если в критичном функционале возникает ошибка, то это негативно влияет на пользовательский опыт и потенциальный клиент никогда не совершит целевое действие и не принесет прибыль компании-заказчику.

4. Интеграция со сторонними сервисами. Важно проверить, что взаимодействие между системами работает корректно, в соответствие с документацией и требованиями. Здесь возникает очень большое количество багов, особенно если сервисы пишут разные команды разработчиков в разных компаниях. Поэтому данные моменты следует проверять с особой тщательность.

Проверяем второстепенный функционал приложения

Теперь рассмотрим тестирование второстепенной функциональности, которую можно отложить на потом. Второстепенная функциональность - эта та, которая напрямую не влияет на работоспособность приложения, это дополнительная функция, которая может быть полезна, но не является существенной для основной ценности.

1. Адаптация WEB версии для мобильных телефонов. Актуально, если большинство пользователей будут пользоваться приложением с компьютеров и если заранее не были зафиксированы четкие требования к адаптивности. В ином случае адаптивность очень важна и ее стоит проверять.
2. Переводы и локализация. Актуально, если приложение первоначально предназначено для пользователей на одном конкретном языке.
3. Второстепенный функционал: добавление в избранное, заметки, визуальные “плюшки” - смена цветовой темы, размера шрифта. В целом, проверку мелких UI-моментов можно оставить на потом.

Основные возможные проблемы

1. Разработка приложения занимает обычно 3-4 месяца. Дизайн и техническое задание (далее. ТЗ) создаются и согласовываются с Заказчиком на самых первых этапах.

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

Решение: Перед началом приемки/тестированием приложения просмотреть ТЗ и дизайн. Все что не входит в основное ТЗ нужно внести в отдельный список и согласовать стоимость и сроки доработок отдельно.

2. Обсуждение изменений на этапе активной разработки.

Проблема: Часто бывает, что на созвонах или в личных переписках обсуждаются изменения требований. При этом эти изменения не фиксируются и не доносятся до всех участников проекта. Из-за этого, об этих изменениях могут забыть Заказчики и/или не знать команда разработки. Следовательно, при приемке могут быть следующие варианты: 1. Изменения не будут реализованы 2. При приемке приложения Заказчик обратит внимание, что были сделаны изменения, которые не зафиксированы в ТЗ/дизайне/документе с изменениями.

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

3. Проекты с интеграцией готовой базы Заказчика (1С, Битрикс и тд)

Проблема: Команда разработки работает либо вообще без каких-либо данных для проверки интеграции, либо с данными в тестовой базе, которые не являются актуальными. Отсутствуют требуемые для правильной разработки поля, ответ приходит в некорректном виде. Часто бывает, что с тестовыми данными приложение полностью протестировано и работает правильно. Но при подключении реальной базы Заказчика возникают многочисленные трудности, и из-за этого разработчикам приходится разрабатывать “костыльные решения”, чтобы интегрироваться. В результате становится невозможно реализовать некоторые доработки приложения, появляется неожиданные баги.

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

4. Заказчик увидел ошибку в работе приложения и передает ее команде разработки.

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

Решение: Когда Заказчик увидел ошибку в работе приложения, описывать ее максимально подробно. Можно дополнительно приложить скрины/видео с шагами воспроизведения ошибки. Это максимально сократит время на тестирование и исправление.

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