Тестирование мобильного приложения перед релизом: что проверить бизнесу

Приложение открывается, экраны похожи на макеты, основные кнопки работают — значит, можно выпускать? Не обязательно. Ошибка может проявиться после обновления старой версии, при переключении Wi-Fi на мобильную сеть или после возвращения из банковского приложения. На демонстрации эти условия часто не возникают, а у настоящих пользователей встречаются постоянно. Тестирование перед релизом помогает не доказать отсутствие любых ошибок, а снизить понятные риски и принять осознанное решение о запуске. Для бизнеса полезен не отчёт «проверено 300 экранов», а ответ на вопросы: какие сценарии надёжны, что ещё ограничено, что произойдёт при сбое и кто будет реагировать. Ниже — практический порядок проверки мобильного приложения.

Составьте несколько сквозных сценариев на языке клиента. Не «проверить кнопку оплаты», а «выбрать услугу, оплатить её и увидеть подтверждённый заказ». Не «проверить календарь», а «найти свободное время, записаться, перенести занятие и убедиться, что новое время сохранено». Так обнаруживаются ошибки между экранами и системами, которые не видны при отдельной проверке элементов. Для каждого сценария определите результат, допустимое время ожидания и восстановление после неудачи. Что пользователь увидит, если товара уже нет? Можно ли продолжить оформление после закрытия приложения? Какие данные должны появиться у менеджера? Эти ответы становятся критериями приёмки, а не дополнительными пожеланиями после запуска. В кейсе автошколы РЕАЛ показаны обучение, запись на практику и оплата. На таком наборе удобно увидеть разницу между готовыми экранами и завершённым процессом. Проверять нужно не только мобильный клиент, но и связанные данные, ограничения расписания и изменение статусов. Такой подход закладывают ещё на этапе мобильной разработки.

Невозможно проверить каждую комбинацию модели, версии системы, разрешений и состояния сети. Поэтому устройства выбирают по аудитории и техническим рискам. Для уже работающего приложения помогают данные об используемых моделях и версиях ОС; для нового — целевой рынок, поддерживаемые платформы и ограничения продукта. В наборе полезны не только новый флагман, но и доступный Android с меньшим объёмом памяти, небольшой экран, устройство с крупным системным шрифтом. Если поддерживаются планшеты или складные устройства, они должны присутствовать в плане явно. Эмуляторы удобны для широкого набора конфигураций, но реальные телефоны нужны для проверки производительности, камеры, уведомлений и поведения в обычной среде. Список проверок можно сопоставить с рекомендациями Android по качеству приложений. Это хорошая отправная точка, но не готовое тестовое задание для любого бизнеса. В отчёте должны быть перечислены фактически проверенные устройства, сборки и ограничения охвата, чтобы «работает на Android» не означало один телефон разработчика.

Проверьте запуск без интернета, медленное соединение, обрыв во время запроса и восстановление связи. Затем переключите сеть, пока пользователь загружает файл, сохраняет профиль или оформляет заказ. Приложение должно объяснять состояние, не очищать заполненные поля без причины и не превращать временную ошибку в бесконечный индикатор загрузки. Особенно опасны действия с побочным эффектом. Сервер мог принять заказ, но клиент не получил ответ. Автоматический повтор не должен создавать второй заказ или повторное списание. Это задача совместной логики клиента и сервера: идентификаторов операций, проверки статуса и безопасных повторов. Подробнее такой обмен разобран в материале об интеграции с CRM и 1С. Не обещайте полноценную работу офлайн, если она не спроектирована. Честное сообщение о недоступности операции лучше ложного успеха. Если офлайн-режим есть, отдельно проверяют, какие данные сохранены локально, как разрешаются конфликты после подключения и что происходит с устаревшими ценами, расписанием или доступными остатками.

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

Введите длинное имя, вставьте телефон из буфера, используйте нестандартные символы, поменяйте системный язык и размер текста. Откройте клавиатуру на нижнем поле формы. Кнопка продолжения должна оставаться достижимой, ошибка — объяснять проблему, а введённые данные — сохраняться после исправления одного поля. Разрешения проверяют в нескольких состояниях: пользователь согласился, отказался, затем изменил решение в настройках. Камера, геолокация и уведомления не должны запрашиваться без понятной причины. Отказ от необязательной функции не должен блокировать остальное приложение. Если разрешение действительно необходимо, интерфейс объясняет зачем и предлагает следующий шаг. Для доступности проверьте подписи элементов в экранном дикторе, порядок фокуса, контраст и различимость состояний без опоры только на цвет. Кнопка может быть технически нажимаемой, но неудобной для человека с крупным шрифтом или ограниченной моторикой. Такие проблемы редко выявляются сравнением двух статичных макетов, поэтому ручная проверка остаётся важной даже при хорошем наборе автотестов.

Для платежа пройдите успех, отказ, отмену, задержку ответа и возвращение из внешнего приложения. После каждого варианта сравните статус на устройстве и сервере. Экран «Оплачено» не должен появляться только потому, что пользователь вернулся по ссылке: подтверждение операции определяется доверенным серверным процессом и данными платёжной системы. В аккаунте проверьте истечение сессии, смену пароля, выход на общем устройстве и доступ к объектам другого пользователя. Скрытая кнопка не является защитой: сервер обязан проверять права независимо от интерфейса. Вложения, история заказов и сохранённые адреса не должны становиться доступными по простому изменению идентификатора запроса. Для системной проверки безопасности используют, например, OWASP MASVS. Он задаёт группы требований к мобильной безопасности, но ссылка на стандарт сама по себе не означает пройденный аудит. В практическом плане фиксируют конкретные проверки хранения токенов, сетевого обмена, журналов и зависимости от сторонних SDK. Тестовые секреты и диагностические данные не должны попасть в релиз.

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

Отладочная сборка может использовать другую конфигурацию, тестовый сервер, более подробные журналы и иной режим оптимизации. Поэтому финальную приёмку проводят на сборке, максимально близкой к публикуемой, с проверенными адресами API, сертификатами и настройками внешних сервисов. Номер версии в отчёте должен однозначно указывать, что именно проверено. Для iOS TestFlight позволяет передавать бета-версию тестировщикам и собирать обратную связь до публикации. Для других каналов используют предусмотренные ими тестовые треки и механизмы распространения. Важно проверить не только установку, но и покупку в допустимой тестовой среде, вход через стороннего провайдера, push-уведомления и ссылки на конкретные экраны. Откройте политику конфиденциальности, поддержку и все внешние ссылки прямо из приложения. Убедитесь, что описание в магазине соответствует доступным функциям. Проверка магазином не заменяет собственный QA: её цель и охват отличаются от бизнес-приёмки. При изменении требований канала публикации их сверяют с актуальной официальной документацией перед отправкой.

До финального созвона договоритесь, какие дефекты блокируют выпуск. Потеря данных, неверное списание, доступ к чужому аккаунту и невозможность завершить основную операцию обычно требуют исправления до запуска. Незначительная визуальная проблема может быть допустима, если известны её границы, назначен ответственный и согласован срок исправления. Не сводите решение к общему числу ошибок. Одна проблема, которая затрагивает оплату у части клиентов, может быть важнее двадцати небольших несоответствий. Обсудите охват, вероятность, ущерб и возможность обхода. Для каждого принятого риска оставьте понятную запись, а не устное «потом поправим». На примере записи в приложении РЕАЛ видно, зачем нужен такой разбор: неправильный отступ и потерянное занятие — принципиально разные дефекты. Изображение ниже показывает пользовательский сценарий из опубликованного кейса, а не отчёт о его тестировании. Для вашего продукта аналогичная карта помогает определить, какие проверки обязательны перед каждой версией.

Первые пользователи принесут сочетания условий, которых не было в лаборатории. Поэтому заранее настройте наблюдение за ошибками, зависаниями и завершением ключевых действий. Сравнивайте не только общий процент сбоев, но и версии приложения, устройства и конкретные сценарии. Рост ошибок после релиза должен иметь понятного получателя, а не оставаться графиком без владельца. Постепенное распространение версии может уменьшить масштаб проблемы, но не исправляет уже установленную сборку. Нужен план остановки дальнейшего распространения, отключения рискованной серверной функции, если это предусмотрено архитектурой, и выпуска исправления. Совместимость API со старой версией тоже важна: пользователи обновляются не одновременно. Передайте команде сопровождения продукта список известных ограничений, контакты ответственных и правила реакции. Хороший релиз — не обещание, что ошибок больше никогда не будет. Это проверенный основной путь пользователя, прозрачные оставшиеся риски и готовность быстро разобраться в реальной проблеме. Такой результат полезнее формального акта, подписанного потому, что все экраны однажды открылись.

Материал проверен и уточнён 7 сентября 2026 года. Обложка — редакционная иллюстрация; технические источники приведены в соответствующих разделах.