Разработка
Android-приложение: требования к устройствам, сети и выпуску
Как подготовить ТЗ на Android-приложение: рабочие сценарии, устройства, офлайн-режим, разрешения, жизненный цикл, испытания и передача сборки.
Опишите мобильную задачу и границы первой версии
ТЗ на Android-приложение начинается с действия, которое человеку нужно выполнить в конкретных условиях. Перенос разделов сайта в мобильное меню ещё не объясняет пользу отдельного приложения. Зафиксируйте основную задачу: принять выездное задание, оформить повторный заказ, работать с документом или получить доступ к данным на месте. Укажите, почему обычной веб-страницы недостаточно и какие возможности устройства действительно нужны. Это помогает выбрать объём первой версии без обязательства заранее реализовать все функции существующей информационной системы.
Определите пользователей через рабочее поведение. Сотрудник с корпоративным устройством, покупатель со старым телефоном и специалист на выезде сталкиваются с разными ограничениями. Нужны данные о версиях Android, размерах экрана, качестве связи и способе установки. Если такой статистики нет, запишите гипотезу и способ её проверки. Не объявляйте поддержку «всех Android» без границ: приложение зависит от возможностей системы, устройства и выбранного канала распространения, а их сочетания необходимо осознанно включить в план испытаний.
Составьте один сквозной сценарий первой версии и список исключений. Учебный пример: техник открывает назначенное задание, фотографирует результат, сохраняет комментарий и передаёт отчёт. Исключения — отсутствие связи, отказ разрешения камеры, нехватка места и изменение задания диспетчером. Именно эти ситуации определяют требования к данным и интерфейсу. Функции, не влияющие на основной путь, вынесите в следующую очередь с отдельной оценкой. Такой подход позволяет принять небольшой законченный продукт, а не большой набор частично работающих экранов.
Согласуйте устройства, распространение и обновления
Зафиксируйте минимальную поддерживаемую версию, целевые классы устройств и особенности корпоративного окружения. Для сканера, планшета, складского терминала и обычного телефона могут потребоваться разные проверки. Не выбирайте версии только по привычке команды: сравните аудиторию, требования зависимостей и стоимость поддержки. В официальных рекомендациях Android по качеству предлагается проверять приложение на представительных версиях целевой аудитории и на актуальной версии системы. Конкретную матрицу для проекта следует сохранить как часть приёмочных условий.
Определите канал установки и владельца учётной записи издателя. Публичный магазин, корпоративное распространение и контролируемая установка внутри компании имеют разные процессы подготовки. Актуальные правила выбранного канала проверяются перед выпуском; не закрепляйте в ТЗ неподтверждённые обещания модерации или сроков публикации. Укажите, кто готовит описание, изображения, сведения о данных и контакт поддержки. Публикация должна выполняться от имени владельца продукта, чтобы дальнейшие обновления не зависели от личного аккаунта временного исполнителя.
Опишите обновление приложения и совместимость с сервером. Пользователи не устанавливают новую версию одновременно, поэтому несколько клиентских версий могут работать параллельно. Укажите срок поддержки старого контракта, поведение при обязательном обновлении и сохранение незавершённых данных. Нельзя блокировать вход до синхронизации локального отчёта, если этим можно потерять работу сотрудника. На приёмке проверьте обновление с предыдущей версии и восстановление после прерванной установки в пределах возможностей выбранной среды распространения.
Разделите локальные данные и серверное подтверждение
Для каждой операции решите, возможна ли она без сети. Чтение сохранённого задания, создание черновика и окончательное подтверждение заказа могут иметь разные правила. Руководство Android по offline-first описывает работу с локальным и сетевым источниками и подчёркивает необходимость локальных данных для чтения без соединения. Для заказчика важен наблюдаемый результат: человек видит доступную информацию и понимает её актуальность. Наличие кеша само по себе не гарантирует, что весь бизнес-процесс можно безопасно выполнять автономно.
В интерфейсе различайте сохранение на устройстве, ожидание отправки и подтверждение сервера. Если отчёт записан локально, это ещё не означает, что диспетчер его получил. У каждой операции нужен устойчивый идентификатор и состояние, сохраняющееся после закрытия приложения. Опишите, что происходит при повторном нажатии, перезапуске телефона и восстановлении сети. Не допускайте ситуации, когда пользователь видит успех только из-за анимации, а после перезапуска обнаруживает исчезнувший документ и не понимает, можно ли безопасно отправить его снова.
Согласуйте разрешение конфликтов. Пока сотрудник работал без сети, задание могли отменить или передать другому. Автоматическая перезапись последним временем не всегда соответствует бизнес-правилу. Для каждого важного поля определите источник, версию и допустимое слияние. При конфликте покажите понятный выбор или передайте разбор ответственному, сохранив локальный результат. Учебный тест должен воспроизводить обе версии данных и подтверждать, что ни одна не исчезает молча только потому, что соединение восстановилось позже обычного.
Опишите разрешения и возможности устройства
Запрашивайте разрешение в момент, когда человеку понятна его необходимость. Камера нужна для фотографии, геолокация — для конкретной функции, уведомления — для согласованного события. Не собирайте доступы заранее «на будущее». В ТЗ укажите альтернативный путь при отказе, если основной процесс может продолжаться без этой возможности. Для обязательного разрешения интерфейс должен объяснять ограничение и способ вернуться к настройке, не создавая бесконечный цикл одинаковых запросов и непонятных сообщений об ошибке.
Для фото и файлов задайте форматы, размеры, сжатие и сохранение исходника. Уточните, когда можно удалить локальную копию и как подтвердить успешную передачу. Большой файл может загружаться долго, поэтому нужны видимый прогресс, отмена и безопасное продолжение в поддерживаемых условиях. Не блокируйте весь экран приложения одной передачей, если пользователь может работать с другими заданиями. Проверьте поворот экрана, сворачивание, нехватку места и попытку открыть вложение сразу после его сохранения.
Если используются сканер, Bluetooth, печать или другие устройства, приложите точные модели и рабочие примеры. Общая фраза «поддержка оборудования» не даёт возможности оценить совместимость. Определите, кто предоставляет тестовые экземпляры и документацию, как обрабатывается потеря соединения и где находится граница ответственности поставщика оборудования. При отсутствии устройства на проверке результат следует обозначить как непроверенный. Демонстрация с имитацией данных не подтверждает работу конкретного физического устройства в реальных условиях эксплуатации.
Проверьте жизненный цикл и мобильный интерфейс
Android может остановить процесс приложения, когда оно находится в фоне. Поэтому важное состояние нельзя хранить только в открытом экране. Опишите восстановление черновика, выбранного объекта и незавершённой операции после повторного запуска. Проверяйте не только обычное нажатие кнопки назад, но и возвращение из камеры, файла, уведомления и внешней ссылки. Пользователь должен понимать, где он находится, а приложение — сохранять связь между выполненным действием и исходной задачей, даже если последовательность переходов отличается от демонстрационной.
Для каждого экрана согласуйте загрузку, пустое состояние, ошибку и ограничение доступа. Размеры элементов и расположение действий должны оставаться удобными при увеличенном шрифте и открытой клавиатуре. Не переносите широкую административную таблицу без адаптации. В мобильном сценарии важны возможность быстро найти основное действие и отсутствие случайного подтверждения. Приложите примеры длинного текста, большого количества записей и нескольких языков, если они входят в продукт. Эти данные позволяют проверить макет до дорогой доработки готовых экранов.
Уведомление должно вести к актуальному объекту с повторной проверкой доступа. За время между отправкой и открытием задание может измениться, завершиться или перейти другому сотруднику. Не выполняйте действие только на основании старого содержимого уведомления. Определите, что видит пользователь при отсутствии объекта или истёкшей сессии и как возвращается к своему списку. Повторная доставка одного события не должна создавать несколько одинаковых действий, хотя сами уведомления могут требовать отдельного управления на уровне платформы и продукта.
Согласуйте безопасность и наблюдение
Опишите данные, доступные каждой роли, и ограничения серверного API. Локально скрытый раздел не заменяет проверку полномочий на сервере. Для корпоративных сценариев укажите последствия увольнения, смены подразделения и утраты устройства. Важно определить, что можно отозвать удалённо и какие данные уже сохранены на телефоне. Не обещайте невозможное стирание любой копии без подходящей управляемой среды. В ТЗ должны быть реальные механизмы и ограничения, согласованные с владельцем инфраструктуры и политикой организации.
Диагностика должна помогать воспроизвести ошибку без ненужного сбора личных данных. Согласуйте события, идентификаторы операций, версии приложения и параметры устройства, необходимые поддержке. Тексты сообщений, документы и секреты не следует автоматически отправлять в общий журнал. Для сбоя полезны стадия операции и связь с серверным событием. Укажите срок хранения, доступ к диагностике и способ обращения пользователя. Поддержка должна различать ошибку приложения, отсутствие сети, отказ сервера и неподдерживаемую конфигурацию устройства.
Для производительности задайте конкретные задачи и условия: запуск, открытие списка, поиск, сохранение черновика, загрузка вложения. Измеряйте их на представительных устройствах с реалистичным объёмом данных. Успешная работа на одном новом телефоне не подтверждает качество для всей аудитории. Дополнительно проверяйте потребление памяти, батареи и трафика в длительном сценарии. Фоновая синхронизация не должна бесконтрольно повторять тяжёлые действия при нестабильной сети и превращать приложение в источник постоянного расхода ресурсов устройства.
Соберите приёмочный набор с отказами
Испытания должны включать обычный путь, отсутствие сети, медленную связь, повтор события, истёкшую сессию и изменение данных на сервере. Для каждого сценария подготовьте исходное состояние и ожидаемый результат. Отдельно проверьте сохранение при закрытии приложения и восстановление после обновления. Список моделей и версий системы прикладывается к отчёту. Формулировка «проверено на Android» слишком широка: принимающая сторона должна видеть, какие сочетания действительно проверялись и какие пока остаются за границами подтверждённой поддержки.
Для интеграций разделите имитацию и реальное взаимодействие. Тестовый ответ сервера помогает проверить интерфейс, но не подтверждает работу внешнего оборудования или доставки уведомления. Используйте предусмотренные тестовые среды и фиксируйте полученные идентификаторы. При неизвестном результате сохраняйте именно неизвестный статус. На рабочие учётные записи и реальные отправки переходите только в согласованном объёме. Такой порядок позволяет проверить надёжность, не превращая приёмку приложения в неконтролируемое воздействие на сотрудников и клиентов действующего сервиса.
Критические дефекты должны блокировать выпуск независимо от общего количества пройденных тестов. Потеря локального отчёта, повторное бизнес-действие или доступ к чужим данным важнее косметического списка замечаний. Для остальных недочётов согласуйте срок, владельца и способ повторной проверки. Храните номер сборки, конфигурацию сервера и набор данных. После изменения синхронизации или авторизации повторяйте связанные сценарии, поскольку успешная проверка прошлой версии не доказывает корректность нового поведения приложения.
Передайте приложение вместе с эксплуатацией
Комплект передачи включает исходники, инструкции сборки, описание API, конфигурации сред, материалы публикации и порядок выпуска обновлений. Доступы и ключи оформляются на владельца продукта и передаются отдельно от общего отчёта. Уточните, кто отвечает за совместимость с новыми версиями Android и изменениями внешних сервисов. Даже небольшое приложение требует дальнейшей поддержки. Если эта работа не включена в договорённости, её границы и порядок заказа должны быть понятны до публикации первой версии.
После запуска наблюдайте не только установки, но и завершение основных задач, ошибки синхронизации, возраст очереди и обращения поддержки. Установка не равна активному использованию, а открытие экрана — успешному выполнению операции. Сопоставляйте показатели с версиями приложения и устройствами, сохраняя ограничения выборки. Если новая сборка ухудшила ключевой сценарий, должен существовать план остановки распространения и исправления, учитывающий уже установленные версии и данные, созданные пользователями после обновления продукта.
Заполняемый бриф в источниках статьи помогает собрать мобильный контекст, модель данных, разрешения и приёмочные проверки. Приложите к нему реальные рабочие сценарии и перечень устройств, а не только изображения желаемых экранов. Хорошее ТЗ объясняет, что человек сможет сделать, когда связь нестабильна, действие прервано или данные изменились. Именно эти правила превращают демонстрацию в пригодное к повседневной работе приложение и позволяют оценивать результат по наблюдаемому поведению, а не по количеству реализованных пунктов меню.
Источники
- Core app quality
Android Developers / доступ 2026-10-18
Первичный источник для соответствующих принципов и технических свойств. Структура требований и учебные примеры подготовлены редакцией; конкретная конфигурация проверяется отдельно.
- Build an offline-first app
Android Developers / доступ 2026-10-18
Первичный источник для соответствующих принципов и технических свойств. Структура требований и учебные примеры подготовлены редакцией; конкретная конфигурация проверяется отдельно.
- Скачать заполняемый бриф / ТЗ (.txt)
Малевич — практическое приложение / доступ 2026-10-18
Сохраните файл и заполните данные проекта, открытые решения и критерии приёмки.
FAQ
Нужно ли обещать работу Android-приложения полностью без интернета?
Только если это соответствует реальным сценариям и техническим ограничениям. В ТЗ лучше перечислить конкретные доступные офлайн-действия, состояние синхронизации и операции, требующие подтверждения сервера.
Почему теста на одном телефоне недостаточно?
Устройства отличаются версией системы, размером экрана, ресурсами и поведением фоновых процессов. Матрицу испытаний выбирают по целевой аудитории и риску, отдельно фиксируя непроверенные сочетания.
Что передать заказчику кроме установочного файла?
Исходники, инструкции сборки и выпуска, согласованные доступы, правила владения ключами, описание окружений, результаты испытаний и порядок обновления. Состав передачи нужно определить до начала разработки.
