Цифровые продукты ·
Приложение проверяют до того, как магазин проверит сборку
Проверка магазина приложений не заменяет проверку продукта. До публикации команда должна убедиться, что человек может пройти основной сценарий на реальном устройстве, пережить ошибку сети и безопасно вернуться к работе.
Начать с обещания приложения
Список экранов плохо описывает готовность. Нужны сквозные сценарии: установить приложение, войти, выполнить ключевое действие, получить подтверждение, закрыть приложение и продолжить позже. Каждый сценарий должен иметь ожидаемый результат и понятную точку отказа.
Сначала проверяют самое важное обещание продукта. Если приложение создано для заказа услуги, критичен завершённый заказ, а не идеальная анимация второстепенной настройки. Приоритет тестов следует цене ошибки и частоте действия.
Реальные устройства раскрывают контекст
Симулятор ускоряет разработку, но не показывает весь физический контекст: нехватку памяти, поворот экрана, системные диалоги, биометрию, камеру, уведомления и поведение после долгой паузы. Основные сценарии нужно пройти хотя бы на нескольких реальных устройствах и версиях системы, которые соответствуют аудитории.
Не требуется бесконечная лаборатория. Матрицу собирают по риску: минимальная поддерживаемая версия, распространённый размер экрана, слабое устройство и актуальная система. Особые функции — NFC, Bluetooth, геолокация или фоновая работа — расширяют набор целенаправленно.
Сеть должна быть плохой намеренно
Мобильное соединение пропадает между отправкой и ответом, меняется с Wi-Fi на сотовую сеть и возвращается спустя минуту. Нужно проверить медленный канал, отсутствие связи, тайм-аут и повторное открытие приложения. Пользователь должен понимать, что произошло с его действием.
Особенно опасны повторные операции. После неясного ответа человек нажимает кнопку ещё раз, и система может создать второй заказ или списание. Интерфейс, сервер и локальное состояние должны вместе предотвращать дубли и позволять безопасно продолжить.
Разрешения получают в нужный момент
Запрос доступа к камере, фотографиям, геолокации или уведомлениям должен появляться тогда, когда понятна его польза. Отказ нельзя считать тупиком: приложение объясняет альтернативу и позволяет открыть системные настройки, если функция действительно необходима.
Проверяют первый запрос, повторный отказ, ограниченный доступ и изменение разрешения вне приложения. Важно увидеть, как интерфейс ведёт себя после возвращения из настроек и не сохраняет ли он ошибочное представление о доступе.
Данные и аккаунт требуют аварийных сценариев
Вход проверяют с неверным кодом, истёкшей ссылкой, сменой контакта и восстановлением доступа. Если приложение хранит документы или черновики, нужно определить, что останется после выхода, переустановки и входа на другом устройстве.
Для покупок и подписок проверяют успешную оплату, отмену, ожидание подтверждения, восстановление покупки и повторную доставку события от магазина. Состояние доступа должно опираться на подтверждённую операцию, а не только на локальный экран успеха.
Доступность и локализация проверяются руками
Увеличенный текст, экранный диктор, контраст и порядок фокуса могут изменить привычный сценарий. Автоматическая проверка находит часть проблем, но не отвечает, можно ли понять экран без изображения и выполнить действие без точного касания.
Другой язык меняет длину строк, формат дат, валют и чисел. Нужно пройти интерфейс с длинными переводами и правдоподобными данными, проверить обрезание текста и сообщения об ошибках. Заглушки редко показывают эти слабые места.
Аналитика тоже проходит приёмку
Событие должно отправляться один раз, в нужный момент и без лишних персональных данных. Проверяют не только появление события в отладчике, но и связь с версией приложения, экраном и результатом операции. Иначе после запуска команда увидит числа, которым нельзя доверять.
Ошибки и падения должны содержать достаточно контекста для разбора без раскрытия секретов. Полезно заранее определить порог, при котором выпуск останавливается: например, сбой основного сценария или рост критических ошибок в пробной группе.
Пробный выпуск завершает проверку
Перед широкой публикацией сборку передают ограниченной группе через доступный тестовый канал. Участники получают конкретные задания и способ сообщить о проблеме. Их задача — проверить реальные устройства, аккаунты и условия, а не просто открыть приложение.
В рамках Метода я связываю критерии приёмки с архитектурой приложения ещё до разработки. Перед выпуском сквозные сценарии, телеметрия и план восстановления проходят вместе. Тогда публикация становится управляемым этапом продукта, а не последней надеждой на проверку магазина.
От сценария к приложению
Если вам нужно приложение, разберём ключевой сценарий, роли, первую версию и ограничения до начала разработки.