Приложение работает, пока есть интернет. Что тестировать, когда его нет

С сентября 2025 года в России действует «белый список» Минцифры — перечень сервисов, которые остаются доступны, когда в регионе ограничивают мобильный интернет. Список обновлялся в ноябре и декабре 2025-го, в феврале и апреле 2026-го. В Москве он частично заработал в марте 2026 года — после недели ограничений, начавшихся 6 марта.

 

Параллельно случаются аварии другой природы. 18 августа 2026 года отказ питания на подстанции, обслуживающей ММТС-9 — одну из ключевых точек обмена трафиком, — на полтора часа уронил десятки сервисов: Steam, Discord, VK, Ozon, личные кабинеты операторов связи. Резервные дизели нагрузку не закрыли.

 

Для пользователя все эти ситуации выглядят одинаково: приложение не работает. Для команды разработки это три разных класса дефектов — и почти ни один из них не ловится обычным регрессом на офисном Wi-Fi.

Фраза «проверили в авиарежиме» закрывает один сценарий из трёх. Остальные два — те, где ломается по-настоящему.

 

Сети нет совсем. Самый безобидный случай: системный API честно возвращает «нет соединения», приложение это видит и может отреагировать. Именно этот сценарий обычно и проверяют.

 

Сеть формально есть, но соединение рвётся. Ограничения реализуются через DPI-фильтры, которые определяют домен по TLS SNI или заголовку Host. Соединение при этом устанавливается: DNS резолвится, запрос уходит, ответ начинает приходить — и обрывается. По наблюдениям проекта Cheburcheck, разрыв часто происходит после первых 16–20 килобайт, поэтому HTML-каркас, JS-бандлы, стили и ответы API не проходят целиком. Индикатор сети на телефоне горит, а страница не догружается. Для приложения это не «нет сети», а «сервер отвечает странно» — и в этом состоянии большинство продуктов ведут себя хуже всего.

 

Сеть есть, но только до части адресов. Белый список — это около тысячи доменов с маской на поддомены. Ваш домен может быть в нём, а шрифты, капча, карта, платёжный виджет, чат поддержки и аналитика — нет. Сервис открывается наполовину. «Ресурсы из белого списка могут оказаться недоступны из-за зависимости от сторонних CDN и API», — отмечал в «Коммерсанте» один из экспертов, добавляя, что при ограничениях «часть функций у банков, такси, доставки и корпоративных сервисов просто перестаёт работать».

 

Это не что-то эксклюзивное для одного региона. Сильнее всего сбоят именно те сценарии, на которых у среднего и крупного бизнеса держится выручка: оформление заказа, вызов машины, оплата на кассе, авторизация курьера, подтверждение операции в банковском приложении и т.д.

1. Обрыв в середине операции

Самый дорогой дефект возникает не тогда, когда запрос не ушёл, а когда он ушёл, сервер его обработал, а ответ до клиента не дошёл. Пользователь видит ошибку и нажимает «Повторить». Если операция не идемпотентна — получаете второе списание, второй заказ, второе бронирование.

Что проверять: у каждой изменяющей состояние операции есть ключ идемпотентности (Idempotency-Key или его аналог); повторная отправка с тем же ключом возвращает результат первой, а не создаёт новую сущность; ключ живёт достаточно долго, чтобы пережить повтор через минуту, а не только через секунду.

 

2. Таймауты на каждом сетевом вызове

Бесконечный спиннер — это отсутствие верхней границы ожидания. Проверять нужно три вещи: таймаут задан для каждого вызова, а не только для «основных»; по его истечении пользователь видит конкретное сообщение, а не пустой экран; действие можно повторить, не начиная сценарий с нуля.

 

3. Что интерфейс показывает вместо данных

«Что-то пошло не так» — это не сообщение об ошибке, а отказ от диагностики. Здесь две отдельные проверки, и вторую обычно пропускают.

Текст. Он написан для пользователя, а не для разработчика: без кодов ответа, стектрейсов и слова «сервер». Пользователь должен различать три состояния — у него нет сети, сервис не отвечает, операция отклонена. От этого зависит, что он сделает дальше: подождёт, перезайдёт или пойдёт в поддержку.

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

 

4. Инвентаризация внешних доменов

Отдельная задача: составить список всех внешних адресов, без которых главный сценарий не доходит до конца. Сторонние ресурсы есть практически везде — по данным HTTP Archive Web Almanac за 2025 год, их подключают 90–92% страниц, а медианная страница на мобильных делает 79 сторонних запросов (у топ-1000 сайтов — 106). Обычно в списке оказываются шрифты, CDN со статикой, капча, карты, платёжный виджет, SDK пушей, аналитика, сборщик ошибок, виджет чата, система A/B-тестов.

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

 

5. Каналы доставки одноразовых кодов

Если единственный канал подтверждения — push-уведомление, человек без мобильного интернета не войдёт в приложение. Тест-кейс формулируется буквально так: мобильный интернет отключён, голосовая связь и SMS работают — может ли пользователь авторизоваться и подтвердить операцию.

 

6. Кэш и устаревшие данные

Показывать сохранённые данные в офлайне нормально. Показывать их молча — нет. Цены, остатки, балансы, статусы заказов и расписания должны быть помечены временем последнего обновления. Отдельно проверяется, что при возврате сети кэш инвалидируется, а не остаётся до перезапуска приложения.

 

7. Очередь отправки и фоновая синхронизация

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

 

8. Момент восстановления связи

Возврат сети — отдельный сценарий, а не автоматический хеппи-энд. Проверяется переподключение WebSocket, повторная авторизация по истёкшему токену, восстановление подписок и то, что все клиенты не ломятся на сервер одновременно, добивая его после аварии.

Инструменты давно есть, вопрос только в том, чтобы завести под них тест-кейсы:

 

• Chrome DevTools — режимы Offline и throttling для веба.

• Network Link Conditioner на iOS и профили сети в Android-эмуляторе, adb shell svc data disable — для мобильных приложений.

• Charles или Proxyman — ограничение скорости, обрыв конкретного домена, подмена ответа.

• WireMock — эмуляция сервера, который отвечает через 30 секунд или не отвечает вовсе.

• toxiproxy и tc netem — потери пакетов и задержки на серверной стороне.

 

Главное здесь не инструмент, а форма. Пункт «проверить в плохой сети» в конце чек-листа не работает: он выполняется последним, руками и по-разному. Работает матрица в TMS — сценарий × состояние сети, с фиксированным набором состояний (полный офлайн, обрыв на середине ответа, доступен только основной домен, высокая задержка, потеря пакетов) и понятным ожидаемым результатом в каждой ячейке.

• Есть ли список внешних доменов, без которых главный сценарий не завершается? Кто его ведёт и когда обновлял?

• Что произойдёт при обрыве между отправкой платежа и получением ответа — повтор безопасен технически, а не «по договорённости»?

• Задан ли таймаут на каждом сетевом вызове и что именно видит пользователь по его истечении?

• Может ли пользователь войти в приложение и подтвердить операцию, если push не приходят?

• Есть ли в тест-плане состояния деградации сети — или только «сеть есть» и «сети нет»?

 

Если на большую часть вопросов ответ звучит как «надо посмотреть» — этих тест-кейсов не существует. И проверять их будет не QA, а пользователи в тот день, когда в регионе в очередной раз ограничат мобильный интернет.