Мобильный чек-лист нужен, чтобы перед релизом не потерять важные риски среди десятков экранов и устройств. Он связывает проверку с конкретным действием и наблюдаемым результатом. Строка «проверить сеть» слишком общая; «отключить сеть после отправки заказа и убедиться, что повтор не создаёт второй заказ» уже помогает найти дефект.
Этот материал — основа для адаптации. Банковскому приложению, медиаплееру и трекеру привычек нужны разные глубина и акценты. Хороший чек-лист растёт из продукта, аналитики, изменений релиза и предыдущих инцидентов.
Зафиксировать границы прогона
До проверки запиши версию и номер сборки, окружение API, способ установки, feature flags и тестовые аккаунты. Составь короткую матрицу устройств: ключевая версия ОС, минимально поддерживаемая конфигурация, популярный экран и устройство с ограниченными ресурсами. Выбор обоснуй пользователями и рисками, а пропуски обозначь явно.
Раздели smoke и расширенный регресс. Smoke отвечает, пригодна ли сборка для дальнейшей работы и проходят ли жизненно важные маршруты. Он не заменяет проверку миграции данных или поведения после нескольких часов использования.
Установка, обновление и первый запуск
Проверь чистую установку и обновление с поддерживаемой предыдущей версии. В обновляемом приложении заранее создай реалистичные данные: черновик, настройки, офлайн-объекты. После обновления они должны сохраниться или мигрировать согласно требованиям.
На первом запуске проверь onboarding, выбор языка, обязательные согласия и доступность основного экрана при отказе от необязательных разрешений. После удаления и повторной установки проверь поведение восстановления данных по правилам платформы и продукта; не считай любой оставшийся серверный аккаунт признаком неудачного удаления приложения.
Критические пользовательские маршруты
Выдели несколько действий, ради которых человек открывает продукт: вход, поиск, создание заказа, отправка сообщения, просмотр билета. Для каждого проверь успешный результат и хотя бы одно состояние отказа.
- →Действие действительно меняет данные на сервере, а повторный вход показывает сохранённое состояние.
- →Пустой список объясняет следующий шаг, ошибки дают возможность продолжить работу.
- →Двойной тап и повторная отправка не создают недопустимые дубликаты.
- →Клавиатура, длинный текст и системные панели не перекрывают обязательное действие.
Проверка результата важнее количества открытых экранов. Один успешно нарисованный toast ещё не означает сохранённую заявку.
Сеть и offline-состояния
Проверь запуск без сети, потерю соединения во время чтения и записи, медленный ответ, восстановление подключения и переключение Wi-Fi на мобильную сеть. Уточни ожидаемое поведение очереди локальных операций и правила разрешения конфликтов.
Для операции с побочным эффектом выясни, что произойдёт, если сервер успел выполнить запрос, а клиент не получил ответ. Экран не должен выдавать неподтверждённый успех или заставлять пользователя бесконечно повторять действие. После восстановления сравни локальное состояние с серверным и проверь отсутствие дублирования.
Жизненный цикл и системные прерывания
Сверни приложение на форме, открой снова, заблокируй устройство и вернись после истечения сессии. Проверь пересоздание экрана и уничтожение процесса отдельно от обычного перехода в фон: это разные условия восстановления.
Черновик может сохраняться, а чувствительные данные — скрываться согласно требованиям. Важно, чтобы система не теряла подтверждённую операцию и не продолжала её с устаревшими правами. Дополнительно проверь входящий вызов или системный диалог во время записи аудио, оплаты либо загрузки файла, если такой сценарий есть в продукте.
Разрешения, уведомления и внешние переходы
Проверь выдачу, отказ и последующий отзыв используемых разрешений. У приложения должна быть понятная реакция на отсутствие доступа к камере, геолокации или уведомлениям. Неиспользуемые разрешения не стоит добавлять в чек-лист ради полноты.
Для push проверь foreground, background и запуск по уведомлению. Для deeplink — установленное приложение, истёкшую сессию, недоступный объект и повторное открытие ссылки. Уведомление не должно показывать чужие данные после смены аккаунта, а переход не должен обходить проверку доступа.
Данные, безопасность и совместимость
На двух тестовых аккаунтах проверь смену пользователя, logout и доступ к ранее открытым приватным экранам. Сверь, что кэш, поиск и push больше не показывают данные предыдущего пользователя. В диагностических логах и отчёте не должно быть настоящих токенов и пользовательских секретов.
Проверь поддерживаемые локали, часовые пояса и форматы дат в значимых сценариях. Переход через полночь особенно полезен для бронирования, расписаний и суточных лимитов. На дополнительных устройствах повторяй наиболее рискованные сценарии, учитывая конкретное изменение релиза.
Доступность, скорость и устойчивость
Пройди основной маршрут с TalkBack или VoiceOver, увеличенным текстом и согласованными системными настройками. Оцени достижимость кнопок, порядок фокуса и сообщения об ошибках. Автоматический сканер дополняет ручную проверку.
Для производительности сравни холодный запуск и выполнение основной операции с принятой базовой версией в одинаковом окружении. Запиши метод измерения и несколько повторов. Проверяй зависания, crashes, рост памяти после повторяющихся действий и активность после ухода в фон; субъективного «вроде быстро» недостаточно.
Практический пример: smoke доставки
Предположим, команда согласовала пять обязательных проверок для новой сборки: обновление, вход, корзина, подтверждение заказа и открытие заказа из уведомления. На основном устройстве обнови предыдущую версию с сохранённым адресом, войди, добавь один товар, создай тестовый заказ и открой его уведомление.
Ожидаемый результат: адрес сохранён, сумма одинакова на всех шагах, создан ровно один заказ, уведомление открывает этот заказ, crash не возникает. Отдельно повтори подтверждение с потерей ответа и восстановлением сети. На втором устройстве проверь вход и завершение заказа. Такой прогон имеет ясные границы; число прошедших пунктов не превращает его в полный регресс.
Как оформить результат
Для каждого пункта используй Passed, Failed, Blocked или Not Run, добавляй окружение и ссылку на дефект. Blocked означает отсутствие возможности проверить, а не успешный результат. В отчёте перечисли блокирующие проблемы и непокрытые риски: например, обновление на минимальной ОС ещё не проверено.
Чек-лист полезен, когда помогает принять решение о сборке. Поддерживай его после инцидентов и изменений продукта, убирай дубли и превращай устойчивые повторяемые проверки в автоматизацию. Каждый пункт должен объяснять, что именно наблюдать и почему это имеет значение.
Что ещё почитать
Матрица «функция × платформа × состояние» вместо общего списка
Выбирайте устройства по поддерживаемым версиям ОС, реальной статистике продукта при её наличии и рискам памяти, маленьких экранов и аппаратных функций. Без аналитики набор из трёх устройств — гипотеза по рискам, а не измеренное покрытие рынка: Android на старшей по возрасту поддерживаемой конфигурации, актуальный Android другого производителя и поддерживаемый iPhone. Добавляйте версии iPhone/ОС и размеры экранов, когда этого требует диапазон поддержки или риск функции.
Функция Платформа/состояние Действие Наблюдаемое ожидание Доказательства
Черновик формы Android: фон/возврат Ввести текст, сменить приложение, вернуться Состояние соответствует правилу сохранения; нет двойной отправки Сборка + видео
Черновик формы iOS: inactive/фон/возврат Прервать редактирование и вернуться Состояние соответствует правилу сохранения Сборка + видео
Камера Обе платформы: отказ в разрешении Вызвать функцию и отказать Рабочий запасной сценарий; понятное объяснение; нет падения Разрешения + видео
Список Обе платформы: offline/reconnect Загрузить, отключить сеть, обновить, вернуть сеть Кэш и повтор соответствуют требованиям Сеть + UI
Deep link Обе платформы: cold/warm start Открыть ссылку с входом и без входа Нужный экран или безопасный сценарий входа Ссылка + сессия
Обновление Каждый поддерживаемый переход Установить сборку поверх подготовленной старой Нужные данные сохранены и мигрированы Сборки + сравнение данныхНе считайте callbacks Android Activity и переходы iOS Scene одинаковыми. Android Activity может пересоздаваться; поведение iOS при переходе в фон определяется жизненным циклом сцены или приложения. Фиксируйте конкретную ОС, действие и восстановление. Отказ при запросе разрешения проверяйте отдельно от отзыва в настройках: доступные варианты зависят от версии ОС и типа разрешения.
Для каждой строки сохраняйте Pass/Fail/Blocked/Not run, точные устройство и ОС, сборку, исходное состояние и обезличенное доказательство. Один прогон на симуляторе не подтверждает поведение реальной камеры, доставки уведомлений, смены сети или нехватки памяти. Выбирайте реальные устройства по риску функции, не объявляя все конфигурации покрытыми.