В прошлом уроке мы разобрались, чем mobile web отличается от native и как получить «телефон» для тестирования. Но вёрстка (глава 7) и общая специфика мобильных устройств (11.1) — ещё не весь список того, что стоит проверить. У мобильного устройства есть поведение, которого нет у десктопа: его прерывают звонком, у него спрашивают разрешения на доступ к данным, его сеть нестабильна, его можно повернуть, по нему водят пальцем, а не кликают мышью. В этом уроке — рабочий чек-лист по пяти категориям, с пометкой, что из него проверяется на нашей платформе через DevTools, а что требует реального устройства или эмулятора/симулятора ОС.
Чему научишься за этот урок:
— перечислять пять категорий мобильного чек-листа: прерывания, разрешения, сеть, ориентация, жесты;
— различать, какие пункты чек-листа проверяются через DevTools-эмуляцию на нашей платформе, а какие — только на реальном устройстве или эмуляторе/симуляторе ОС;
— применять чек-лист к конкретным местам платформы: оформлению заказа, запросу геолокации, оплате.
Пять категорий мобильного чек-листа
Дефекты вёрстки — не единственное, что ломается именно на мобильном. Ниже — пять категорий поведения, специфичного для телефона, с примерами на нашей платформе.
- Прерывания — входящий звонок, push-уведомление другого приложения, срабатывание будильника. Проверяем, сохраняется ли состояние продукта, когда пользователь на секунды отвлёкся и вернулся: например, не сбрасывается ли форма оформления заказа на нашей платформе, если пользователь на пару секунд свернул вкладку. Реальный звонок или системное уведомление — событие операционной системы, а не браузера, и полноценно проверяется только на реальном устройстве или эмуляторе/симуляторе ОС.
- Разрешения — запрос доступа к геолокации, камере, уведомлениям. Проверяем оба исхода: что происходит, если пользователь разрешил доступ, и что происходит, если отказал. Наша платформа пока разрешений не запрашивает, но если появится, например, определение города по геолокации для отображения цен — сценарий отказа обязателен к проверке: платформа должна вежливо предложить выбрать город вручную, а не сломаться.
- Сеть — переключение между Wi-Fi и мобильной сетью, обрыв связи посреди действия, медленная сеть. Проверяем, например, что видит пользователь, если соединение пропадает в середине оплаты курса на нашей платформе: понятную ошибку или зависшую страницу, и не списываются ли деньги дважды при повторной попытке.
- Ориентация — поворот телефона из вертикального положения (portrait) в горизонтальное (landscape) и обратно. Проверяем два вопроса: не ломается ли вёрстка на новой ориентации и не теряются ли уже введённые данные — например, не исчезает ли промокод из поля, если пользователь повернул телефон посреди оформления заказа.
- Жесты — свайп, долгое нажатие, pinch-to-zoom (сведение и разведение пальцев для масштабирования). Часть из них — общее поведение браузера и ОС (pinch-to-zoom обрабатывается ими самими), часть может быть реализована на конкретной странице mobile web (например, свайп по карусели курсов), а сложные многопальцевые и системные жесты — уже специфика native, на mobile web их попросту нет.
Что проверяемо в DevTools у нас, а что — только на реальном устройстве
Здесь работает та же логика, что и в прошлом уроке: DevTools эмулирует браузер, меняя его заявленную ширину, модель устройства и некоторые параметры окружения, но не подменяет собой целую операционную систему. Поэтому часть чек-листа проверяется прямо на нашей платформе через DevTools: обрыв и замедление сети (throttling), поворот экрана (кнопка в панели устройств), частично — координаты геолокации (панель Sensors). А часть требует реального телефона или эмулятора/симулятора ОС: настоящий входящий звонок, точный вид системного диалога запроса разрешения, вибрация, реальное поведение батареи. Таблица ниже сводит это в одну шпаргалку.
Категория | Что проверяем | Проверка у нас
------------ | ----------------------------------- | ------------------------------
Прерывания | Состояние после возврата | Вкладка - DevTools; звонок,
| к экрану | push, будильник - только
| | реальное устройство/эмулятор ОС
Разрешения | Реакция на разрешение и на отказ | Координаты - панель Sensors;
| | вид диалога - реальное устройство
Сеть | Обрыв и медленная связь | DevTools: Slow 3G / Offline
Ориентация | Вёрстка и данные при повороте | DevTools: кнопка поворота экрана
Жесты | Mobile web против native | Свайп/нажатие - функциональность
| | страницы; сложные жесты - native
Совет: не пытайтесь эмулировать в DevTools то, что физически не может имитировать десктопный браузер, — реальный звонок, вибрацию, настоящую нестабильную сеть, точный вид системных диалогов разрешений. Чек-лист годится и для отчёта: честно укажите «пункт проверен через DevTools» или «пункт требует реального устройства, не проверен доступными инструментами» — это тоже полезная информация для команды.
Итог:
— пять категорий мобильного чек-листа: прерывания, разрешения, сеть, ориентация, жесты;
— обрыв/замедление сети, поворот экрана и частично геолокация проверяются в DevTools прямо на нашей платформе;
— реальный звонок, точный вид системного диалога разрешения и сложные системные жесты — только на реальном устройстве или эмуляторе/симуляторе ОС;
— чек-лист стоит привязывать к конкретным местам продукта: форме заказа, оплате, будущему запросу геолокации.
Контрольный вопрос. Какой пункт мобильного чек-листа проверяет, сохранилось ли состояние приложения после того, как пользователя отвлёк входящий звонок или push-уведомление?
Подсказка: Вспомни, что происходит, когда пользователя ненадолго отвлекли от экрана.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Что именно нужно проверить в категории «Разрешения» мобильного чек-листа?
Подсказка: Речь про системный запрос доступа к данным устройства — камере, геолокации, уведомлениям.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Какой режим DevTools позволяет проверить поведение страницы при медленной или пропавшей сети?
Подсказка: Название функции прямо связано со словом «замедление» сети.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Что нужно проверить при повороте телефона из portrait в landscape, кроме того, не ломается ли вёрстка?
Подсказка: Вспомни пример с промокодом, который вводят перед поворотом экрана.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Какие пункты чек-листа можно полноценно проверить через DevTools-эмуляцию на нашей платформе (выбери все подходящие)?
Выберите все верные варианты.
Подсказка: Два пункта эмулирует именно браузер DevTools, два других — события операционной системы, которых в браузере просто нет.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Жест «сведение и разведение пальцев для масштабирования» контролируется браузером и ОС, а не самим продуктом. Как называется этот жест — ответь термином из урока, как он записан в тексте (через дефис)?
Подсказка: Термин записан в скобках сразу после русского описания жеста, в разделе про жесты.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. Пользователь оформляет заказ на курс на нашей платформе, вводит промокод, а затем сворачивает вкладку браузера, чтобы посмотреть сообщение в мессенджере, и возвращается обратно. Какой пункт мобильного чек-листа отвечает за проверку именно этой ситуации? Ответь одним словом — названием категории из урока.
Подсказка: Вспомни категорию, которая проверяет, что происходит с состоянием после того, как пользователя ненадолго отвлекли.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. Тестировщик хочет проверить, как страница оплаты курса на нашей платформе поведёт себя, если у пользователя посреди оплаты пропадёт интернет-соединение. Какой режим DevTools нужно использовать для этой проверки? Ответь одним словом по-английски — название режима, который эмулирует такую ситуацию без реального обрыва связи.
Подсказка: Вспомни, каким режимом в DevTools можно сымитировать полное отсутствие сети, не выключая реальный Wi-Fi.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. Наша платформа сейчас не запрашивает у пользователя доступ к геолокации, но представим, что в будущем такая функция появится — например, для показа цен в местной валюте. Объясни в 2-3 предложениях, какие два исхода запроса разрешения тестировщик обязан проверить, и почему нельзя проверять только исход «пользователь разрешил доступ».
Критерий приёмки: названы оба исхода — согласие и отказ пользователя; объяснено, что при отказе продукт не должен падать или ломаться, а должен корректно откатиться к резервному поведению (например, к ручному выбору города/валюты); указано, что проверка только «счастливого пути» (согласия) не покрывает реальное поведение части пользователей, которые запрос отклонят.
Подсказка: Вспомни пример из урока с геолокацией и выбором города — что должно произойти, если пользователь нажмёт «Запретить».
✅ Готово, если: программа запускается без ошибок и выводит то, что просят в задании.
Онлайн-проверка ответа появится позже
Задание. Спроектируй мини-план мобильной проверки для новой формы оформления заказа на курс (промокод, способ оплаты, кнопка «Оплатить») на нашей платформе. Опиши, что именно проверишь по трём категориям чек-листа — прерывания, сеть, ориентация — применительно именно к этой форме, и укажи, какие из выбранных проверок доступны через DevTools на нашей платформе, а какие потребуют реального устройства или эмулятора/симулятора ОС.
Критерий приёмки: для каждой из трёх категорий указана конкретная проверка, привязанная именно к форме оформления заказа (не абстрактная); явно разделено, что проверяется через DevTools-эмуляцию (например, throttling сети, поворот экрана), а что требует реального устройства/эмулятора ОС (например, реальный звонок); ни одна из трёх категорий не пропущена.
Подсказка: Пройдись по каждой из трёх категорий по очереди и для каждой сформулируй ОДНУ конкретную проверку именно для формы заказа, а не общую фразу.
✅ Готово, если: программа запускается без ошибок и выводит то, что просят в задании.
Онлайн-проверка ответа появится позже
Что дальше
Мы прошлись по функциональному чек-листу мобильного тестирования. В следующем уроке — глубже про саму мобильную вёрстку: почему одна и та же вёрстка может выглядеть по-разному чёткой на разных экранах, что такое зона безопасности вокруг выреза камеры, почему кнопка может визуально помещаться, но быть слишком маленькой для пальца, а также — обзорно про сборки и специфику сбора доказательств на мобильном.
