Названия Native, Hybrid, Mobile Web и PWA описывают разные способы доставки интерфейса и связи с платформой. Для QA это не соревнование технологий, а подсказка о том, где искать риски. Одинаковая форма заказа может жить в браузере, встроенном web-компоненте или отдельном клиенте и ломаться по разным причинам.
Начинать нужно с реального устройства приложения. Наличие иконки на экране и публикация в магазине не доказывают, что весь интерфейс нативный. А приложение с общим кодом для двух платформ не обязательно является hybrid в смысле WebView.
Native: клиент на платформенных механизмах
Нативное приложение использует возможности и программные интерфейсы целевой платформы. Для QA особенно важны установка, обновление, жизненный цикл, локальные данные, разрешения, системная навигация и взаимодействие с устройством.
Нативный подход не гарантирует быстродействие, доступность и отсутствие сетевых проблем. Длительная операция в UI, неверная миграция базы или потеря незавершённой формы возможны при любой технологии. Проверки привязывают к функции и реализации, а не к репутации подхода.
Hybrid: web-интерфейс внутри приложения
В распространённом значении hybrid — установленная оболочка с HTML, CSS и JavaScript во встроенном WebView и доступом к платформе через мост или плагины. Мост передаёт действия между web-кодом и нативной частью, например запрос камеры и результат выбора изображения.
Здесь нужно проверить обе стороны и их границу. Web-форма может работать в обычном браузере, но терять cookie внутри оболочки. Плагин может вернуть результат после закрытия экрана, а JavaScript — обработать его в устаревшем состоянии. Уточняйте версии оболочки, web-ресурсов и плагинов.
Cross-platform не всегда означает hybrid
Flutter и React Native часто упоминают рядом с hybrid, но их интерфейс не следует автоматически считать HTML-страницей в WebView. Разные инструменты используют разные способы рендеринга и интеграции с ОС.
Для стратегии полезнее спросить: где выполняется логика, чем рисуется экран, как устроено хранение и какие части общие. Если экран содержит отдельный WebView для оплаты, hybrid-риски относятся к этому участку, даже если остальная часть приложения построена иначе. Одна этикетка для всего продукта может скрыть смешанную архитектуру.
Mobile Web: приложение в браузере
Mobile Web — сайт или web-приложение, которым пользуются на мобильном устройстве через браузер. Для него важны адаптивность, адреса и переходы, cookie, хранилище, браузерные разрешения и различия движков.
Пользователь может открыть несколько вкладок, перейти по прямой ссылке и обновить вложенную страницу. Эти действия должны сохранять согласованное поведение. Простое сужение настольного окна помогает проверить layout, но не подтверждает системную клавиатуру, touch-взаимодействие и реальные особенности мобильного браузера.
PWA: web с дополнительными возможностями
Progressive Web App строится на web-технологиях и может предоставлять опыт установленного приложения. В поддерживаемых окружениях она устанавливается и запускается в отдельном окне. Возможности и критерии установки зависят от браузера и платформы.
Manifest описывает приложение, например имя, иконки и способ запуска. Service worker — механизм, который может участвовать в обработке запросов и кэшировании. Наличие этих файлов само по себе не доказывает полноценную работу без сети. Offline, уведомления и синхронизацию проверяют как конкретные реализованные функции в нужном окружении.
Как архитектура меняет тестовую матрицу
- →Native: версии ОС, устройства, сборки клиента, системные настройки и используемые интеграции.
- →Hybrid: тот же мобильный контекст плюс версии web-слоя, WebView и совместимость моста.
- →Mobile Web: браузер, версия, ОС, viewport, состояние вкладки и browser storage.
- →PWA: web-матрица плюс установленный режим, запуск по иконке, обновления кэша и обещанные дополнительные функции.
Матрица может включать несколько режимов одного продукта. Установка PWA не отменяет проверку сайта в обычной вкладке, если пользовательский путь через браузер поддерживается.
Обновления и рассогласование версий
У установленного клиента обновление может включать миграцию локальных данных. У web-приложения новая версия может появиться при загрузке ресурсов. В hybrid и PWA дополнительно возможны разные версии оболочки, страницы, кэша и backend в одной пользовательской цепочке.
Подготовьте сценарий: пользователь держит старую сессию, команда выпускает новую версию, затем пользователь продолжает работу. Ожидается поддерживаемое сочетание или понятное предложение обновиться, а не внезапное исчезновение данных. При service worker проверяйте фактический цикл обновления и уже открытые окна; наличие нового файла на сервере не означает, что каждый клиент немедленно перешёл на него.
Практический пример: каталог с offline-режимом
Пусть продукт обещает просмотр недавно открытых товаров без сети. Один и тот же результат можно реализовать в разных архитектурах, поэтому проверка начинается с контракта, а не технологии.
- 1.Откройте несколько товаров онлайн и сохраните их идентификаторы. Ожидается доступ к полному согласованному набору данных для offline-просмотра.
- 2.Отключите сеть и откройте приложение заново предусмотренным способом. Ожидается доступность ранее загруженных карточек и явное сообщение об актуальности данных.
- 3.Откройте незагруженный товар. Ожидается понятное объяснение ограничения вместо пустого экрана или ложных данных.
- 4.Обновите версию клиента либо web-ресурсов и повторите сценарий. Ожидается совместимое чтение сохранённого состояния по требованиям.
- 5.Восстановите сеть и обновите карточку. Ожидается согласованное получение актуальной цены; показанная offline-цена не должна молча считаться подтверждённой стоимостью заказа.
Что уточнить до начала тестирования
Спросите команду, какие экраны web, где хранятся данные, какие функции требуют сети, как обновляются ресурсы и кто отвечает за системные интеграции. Уточните поддерживаемые режимы установки и запуска, а также поведение при отказе возможности.
Типичные ошибки — считать PWA гарантированно автономной, относить любой общий код к WebView и переносить результат браузерной проверки на установленную оболочку. Архитектура помогает выбрать риски, но итоговое качество подтверждается воспроизводимыми пользовательскими сценариями.