БЛОК 12. Мобильное тестирование — 29. Основы mobile testing

🧭 Введение: почему мобильное тестирование отличается от веба

В мобильных приложениях баги часто проявляются не только в логике экрана, но и в поведении устройства.
Один и тот же сценарий может пройти на эмуляторе и упасть на реальном телефоне из-за сети, памяти, жестов или прерываний.
Поэтому mobile testing требует отдельного подхода и дисциплины.

💡 Совет:

Проверяй мобильный сценарий не только «внутри приложения», но и в контексте устройства и окружения.

✅ Вывод:

Базовое mobile testing — это проверка приложения вместе с реальным поведением телефона.

⚠️ Проблема -> решение

Проблема: junior QA часто проверяет мобильную фичу как обычный web-flow и пропускает дефекты, связанные с устройством.

Решение: строить проверку по семи обязательным зонам:

устройство (эмулятор + реальное);
installation/update/uninstall;
permissions;
ориентация;
жесты и системная навигация;
прерывания (звонок/уведомления/сворачивание);
сеть (медленная, нестабильная, потеря соединения).

🟢 Если совсем просто:

В mobile важно не только «что делает приложение», но и «что в этот момент делает телефон».

🎯 Как понять, что этап прошел успешно:

Сценарий стабильно проходит на нескольких устройствах и не ломается при типичных мобильных сбоях.

🛠️ Чем помогает и как работает

Системный mobile-подход снижает риск сюрпризов после релиза.

Как это работает:

Шаг 1: фиксируем device matrix (ОС, версия, тип устройства, экран).
Шаг 2: прогоняем базовый happy path на эмуляторе для быстрой обратной связи.
Шаг 3: подтверждаем критичные потоки на реальном устройстве.
Шаг 4: проверяем installation/update/uninstall сценарии.
Шаг 5: проверяем permissions (allow/deny/settings).
Шаг 6: тестируем ориентацию, жесты, прерывания и сеть.
Шаг 7: фиксируем результат в QA summary с device/context.

✅ Вывод:

Mobile testing — это не один прогон на «удобном телефоне», а контролируемая проверка в разных мобильных условиях.

📚 Ключевые термины (простыми словами)

Эмулятор — программная модель устройства на компьютере.
Реальное устройство — физический телефон/планшет, где видны реальные аппаратные эффекты.
Device matrix — список устройств/ОС, на которых обязательна проверка.
Orientation — ориентация экрана (portrait/landscape).
Gesture — жест (tap, long press, swipe, pinch, back swipe).
Interruption — внешнее прерывание сценария (звонок, уведомление, блокировка экрана).
Network loss — потеря или деградация сети во время действия пользователя.
Permission — системное разрешение на доступ к функциям устройства (camera/location/microphone и т.д.).
Clean install — первая установка «с нуля».
Update path — обновление приложения с предыдущей версии.
Uninstall/Reinstall — удаление и повторная установка приложения.

1. Эмулятор vs реальное устройство

Эмулятор очень полезен для скорости, но не заменяет реальный телефон на критичных сценариях.

🟢 Если совсем просто:

Эмулятор — для быстрых проверок, реальный девайс — для финального подтверждения качества.

🎯 Как понять, что этап прошел успешно:

Критичный поток проверен и на эмуляторе, и на реальном устройстве.

Назначение:

Баланс скорости тестирования и реалистичности результатов.

Простыми словами:

Эмулятор помогает работать быстро, реальное устройство показывает, как это будет у пользователя.

Для новичка:

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

Аналогия:

Как тренировка на симуляторе и реальный выезд на дорогу.

Пример: На эмуляторе камера работает стабильно, а на реальном устройстве при первом открытии неправильно отрабатывает permission flow.

🔎 Как это происходит на практике:

QA делает быстрый smoke на эмуляторе, затем критичные сценарии подтверждает на 1–2 реальных устройствах из device matrix.

Характеристики:

эмулятор: быстро, удобно, автоматизируемо;
реальное устройство: ближе к прод-реальности;
вместе дают лучший результат.

Когда использовать:

Эмулятор — каждый день для быстрых проверок; реальные устройства — на ключевых потоках и перед релизом.

✅ Вывод:

Для mobile QA важна связка двух подходов, а не выбор «или/или».

2. Installation / Update / Uninstall

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

🟢 Если совсем просто:

Нужно проверить, как приложение ведет себя при установке, обновлении и переустановке, а не только «после обычного запуска».

🎯 Как понять, что этап прошел успешно:

Сценарии clean install, update и uninstall/reinstall проходят без потери критичных пользовательских данных.

Назначение:

Проверить жизненный цикл приложения между версиями.

Простыми словами:

Приложение должно стабильно переживать путь «поставили -> обновили -> снова открыли».

Для новичка:

Минимальный набор:

чистая установка,
обновление с предыдущей версии,
первый запуск после update,
удаление и переустановка,
проверка, какие данные должны сохраниться, а какие — нет.

Аналогия:

Как переезд в новую квартиру: важно, что перенеслось корректно, а что должно быть «с нуля».

Пример: После update приложение открывается, но локальные настройки языка сбрасываются, хотя по требованиям должны сохраняться.

🔎 Как это происходит на практике:

QA ставит v1.17, делает пользовательские настройки, обновляет до v1.18, проверяет первый запуск и сверяет expected сохранение данных.

Характеристики:

ловит баги миграции;
важен для релизов с изменением storage/schema;
критичен для user settings и авторизации.

Когда использовать:

В каждом релизе, особенно если менялись локальные данные, авторизация, onboarding, кеш или база приложения.

✅ Вывод:

Installation/update/uninstall — must-have блок даже для базового mobile testing.

3. Permissions: camera, microphone, location, notifications, files

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

🟢 Если совсем просто:

Нужно проверить не только «allow», но и «deny», повторный запрос и возврат через settings.

🎯 Как понять, что этап прошел успешно:

Каждое критичное permission-сценарий обрабатывается предсказуемо: allow/deny/retry/settings.

Назначение:

Проверить корректную работу приложения с системными разрешениями.

Простыми словами:

Если пользователь не дал доступ, приложение должно безопасно объяснить, что делать дальше.

Для новичка:

Для каждого permission проверяй:

первый запрос,
отказ,
повторный запрос (если допустимо),
переход в settings и возврат в приложение.

Аналогия:

Как доступ в здание по пропуску: важно не только «пустили», но и что делать, если пропуск отклонен.

Пример: Пользователь отказал в доступе к геолокации; приложение должно показать fallback и кнопку «Открыть настройки», а не падать.

🔎 Как это происходит на практике:

QA проверяет flow на чистой установке, потом сбрасывает permissions в системе и повторяет сценарий deny -> settings -> allow.

Характеристики:

тесно связано с системными диалогами iOS/Android;
часто ломается на edge-сценариях;
критично для camera/location/notifications.

Когда использовать:

Во всех фичах, где есть доступ к датчикам, файлам, пушам, геоданным и микрофону.

✅ Вывод:

Permission-testing — базовая часть mobile QA, без которой лекция и проверка будут неполными.

4. Ориентация и адаптация интерфейса

Поворот экрана часто ломает состояние формы, позиционирование элементов и доступность кнопок.

🟢 Если совсем просто:

Если приложение не держит поворот экрана, пользователь теряет данные и контекст.

🎯 Как понять, что этап прошел успешно:

После смены ориентации состояние экрана корректно сохраняется и UI остается usable.

Назначение:

Проверить устойчивость интерфейса к смене portrait/landscape.

Простыми словами:

Телефон поворачивается — приложение не должно «ломаться» или сбрасываться без причины.

Для новичка:

Проверяй не только верстку, но и состояние: введенный текст, выбранные фильтры, текущий шаг формы.

Аналогия:

Как держать разговор при смене положения телефона, не начиная всё сначала.

Пример: Пользователь заполняет форму, поворачивает экран, и половина полей очищается — это дефект.

🔎 Как это происходит на практике:

QA делает поворот на каждом критичном шаге: ввод данных, подтверждение, экран успеха/ошибки.

Характеристики:

проверка layout и состояния;
важна на длинных формах и checkout-потоках;
часто ловит скрытые UI-дефекты.

Когда использовать:

Во всех экранах с формами, media, таблицами, картами и длительными пользовательскими потоками.

✅ Вывод:

Ориентация — обязательная часть mobile smoke и regression.

5. Жесты и системная навигация

Мобильный пользователь чаще взаимодействует жестами, чем кнопками интерфейса.

🟢 Если совсем просто:

Если жесты обработаны плохо, пользователь «вылетает» из сценария.

🎯 Как понять, что этап прошел успешно:

Ключевые действия корректно работают при tap/swipe/back и не конфликтуют с системной навигацией.

Назначение:

Проверить корректность пользовательских жестов и переходов.

Простыми словами:

Приложение должно правильно понимать движения пользователя и не путать их с системными жестами.

Для новичка:

Проверяй минимум: tap, long press, swipe list, back gesture, pull-to-refresh.

Аналогия:

Как вежливый диалог: система не должна «перебивать» пользователя его же жестами.

Пример: На экране деталей товара back swipe закрывает весь поток покупки вместо возврата на предыдущий шаг.

🔎 Как это происходит на практике:

QA прогоняет один и тот же шаг разными действиями: кнопкой «Назад», системным жестом, свайпом.

Характеристики:

сильно влияет на UX;
особенно критично на iOS gesture navigation;
частый источник «редких» дефектов.

Когда использовать:

Во всех многошаговых и навигационных сценариях.

✅ Вывод:

Проверка жестов — это не «дополнительно», а базовая часть mobile качества.

6. Прерывания: звонок, уведомления, блокировка, возврат

Реальный пользователь почти всегда сталкивается с прерываниями: уведомление, входящий звонок, переключение в другое приложение.

🟢 Если совсем просто:

После прерывания пользователь должен вернуться в приложение без потери важного состояния.

🎯 Как понять, что этап прошел успешно:

Сценарий корректно продолжается после паузы, без дублирования действий и потери данных.

Назначение:

Проверить устойчивость приложения при переходе в background/foreground.

Простыми словами:

Приложение не должно «забыть», что пользователь делал до прерывания.

Для новичка:

На критичных шагах всегда проверь: свернуть приложение, вернуть, заблокировать экран, открыть снова.

Аналогия:

Как поставить разговор на паузу и продолжить с того же места.

Пример: Во время оплаты приходит звонок; после возврата форма повторно отправляется и создаёт дубликат транзакции.

🔎 Как это происходит на практике:

QA на шаге подтверждения действия делает interruption, потом возвращается и проверяет, что сценарий консистентен.

Характеристики:

критично для платежей и форм;
часто связано с гонками и дубликатами;
требует проверки реальным устройством.

Когда использовать:

На checkout, login, загрузке медиа, отправке форм и всех операциях с риском повторной отправки.

✅ Вывод:

Interruption testing — один из самых практичных способов поймать «дорогие» mobile-баги до релиза.

7. Сеть: slow network, timeout, offline

Мобильная сеть нестабильна по природе: переходы между Wi‑Fi/LTE, слабый сигнал, временная потеря соединения.

🟢 Если совсем просто:

Mobile-приложение должно корректно переживать плохую сеть, а не просто падать.

🎯 Как понять, что этап прошел успешно:

При деградации сети пользователь получает понятный статус и может безопасно продолжить сценарий.

Назначение:

Проверить поведение приложения на нестабильной сети и в offline.

Простыми словами:

Если интернет «прыгает», приложение должно вести себя предсказуемо.

Для новичка:

Проверь минимум: slow 3G, полное отключение сети во время действия, возврат сети и повтор.

Аналогия:

Как разговор по плохой связи: важно не потерять смысл и не повторить важную команду дважды.

Пример: Пользователь отправил форму в момент потери сети, нажал повторно и создал дублирующую заявку.

🔎 Как это происходит на практике:

QA включает network throttling, делает действие, отключает сеть на критичном шаге и проверяет восстановление потока.

Характеристики:

проверка error handling;
проверка retry-логики;
проверка идемпотентности действий.

Когда использовать:

Во всех сетевых сценариях: логин, загрузка, отправка данных, покупки.

✅ Вывод:

Network testing в mobile — это проверка надежности продукта в реальных условиях пользователя.

🆚 Сравнение: веб-подход vs mobile-подход

Аспект	Только web-подход	Mobile-подход
Устройство	Часто один браузер	Device matrix + реальные девайсы
Взаимодействие	Клики/клавиатура	Жесты + системная навигация
Прерывания	Редко критичны	Обязательная зона риска
Сеть	Обычно стабильнее	Нестабильная сеть — норма
Жизненный цикл	Обновление страницы	Install/Update/Uninstall сценарии
Permissions	Редко критичны	Обязательны для camera/location/push

✅ Вывод:

Mobile testing требует отдельной карты рисков, а не простого переноса web-практик.

✅ Must-know факты

Эмулятор не заменяет реальное устройство на критичных сценариях.
Installation/update/uninstall нужно проверять в каждом релизе как отдельный базовый блок.
Первый запуск после update часто ловит миграционные дефекты.
Permission-flow нужно проверять в четырех режимах: first ask, deny, повторный запрос, settings и возврат.
Проверка ориентации должна включать не только верстку, но и сохранение состояния.
Жесты и системная кнопка/жест «назад» часто ведут к разному поведению.
Прерывания (звонок, сворачивание, lock screen) — обязательный тест для ключевых потоков.
Потеря сети и повтор действия — типичный источник дубликатов.
В баг-репорте по mobile всегда указывай устройство, ОС, версию приложения и условия сети.

Частые мифы

❌ Миф: Если на эмуляторе всё работает, значит релиз безопасен.

✅ Как правильно: Ключевые сценарии нужно подтверждать на реальном устройстве.

📎 Почему это важно: Аппаратные и системные особенности часто проявляются только на физическом девайсе.

❌ Миф: Installation/update — это задача разработчика, QA достаточно проверить «с нуля».

✅ Как правильно: QA обязан проверять путь обновления и первый запуск после update.

📎 Почему это важно: Миграционные дефекты чаще всего видны именно между версиями.

❌ Миф: Если permission один раз дали, дальше тестировать нечего.

✅ Как правильно: Нужно проверять deny, повторный запрос и возврат через settings.

📎 Почему это важно: Большая часть permission-багов проявляется не в happy path.

❌ Миф: Прерывания проверять не обязательно, это редкость.

✅ Как правильно: Прерывания — обычная часть мобильного поведения пользователя.

📎 Почему это важно: Именно на прерываниях часто появляются дубли, зависания и потеря контекста.

❌ Миф: Сеть проверяется только на «есть/нет интернета».

✅ Как правильно: Нужно тестировать деградацию: slow network, timeout, обрыв во время действия, восстановление.

📎 Почему это важно: Большая часть mobile-проблем связана именно с нестабильной сетью.

Часто спрашивают на собеседованиях

❓ Вопрос: Чем mobile testing отличается от web testing на базовом уровне? ✅ Ответ: В mobile добавляются обязательные зоны риска: устройства, installation/update/uninstall, permissions, ориентация, жесты, прерывания и нестабильная сеть.

❓ Вопрос: Можно ли тестировать mobile-приложение только на эмуляторе? ✅ Ответ: Нет, эмулятор полезен для скорости, но критичные потоки нужно подтверждать на реальном устройстве.

❓ Вопрос: Что входит в базовую проверку installation/update? ✅ Ответ: Clean install, обновление с предыдущей версии, первый запуск после update, uninstall/reinstall и проверка сохранения пользовательских данных по требованиям.

❓ Вопрос: Как тестировать permissions на базовом уровне? ✅ Ответ: Проверять first ask, deny, повторный запрос, переход в settings и возврат в приложение с новым состоянием разрешения.

❓ Вопрос: Что считается обязательным interruption-сценарием? ✅ Ответ: Как минимум: входящий звонок/уведомление, сворачивание приложения, блокировка экрана и возврат в поток.

🚨 Типичные ошибки

делать выводы по одному устройству;
не фиксировать версию ОС и модель устройства в баге;
не проверять update-путь, ограничиваясь только clean install;
тестировать permissions только в режиме allow;
проверять ориентацию только на стартовом экране;
игнорировать системные жесты;
не проверять прерывания на критичных шагах;
ограничивать сеть только режимом «полностью offline».

🌟 Best Practices

поддерживай минимальный device matrix и обновляй его по аудитории продукта;
в каждом релизе делай короткий install/update/uninstall smoke;
веди permission-checklist по критичным разрешениям (camera, microphone, location, notifications, files);
критичные потоки проверяй на реальном устройстве в каждом релизном цикле;
добавляй в чек-лист mobile: orientation, gestures, interruption, network;
в баг-репортах фиксируй: device, OS, app version, network condition, repro rate;
для действий с риском дублей проверяй поведение на retry после обрыва сети;
разделяй smoke mobile-проверку и расширенный regression по рискам.

🧾 Заключение

Основы mobile testing — это практический фундамент, который сразу влияет на качество релиза.
Когда QA системно проверяет устройство, install/update, permissions, ориентацию, жесты, прерывания и сеть, дефекты ловятся раньше и стоят дешевле.

✅ Вывод:

Для junior QA мобильное тестирование начинается с простого правила: проверяй приложение в реальных мобильных условиях и во всем жизненном цикле версии, а не только в «идеальной лаборатории».

БЛОК 12. Мобильное тестирование — 29. Основы mobile testing

БЛОК 12. Мобильное тестирование — 29. Основы mobile testing

🧭 Введение: почему мобильное тестирование отличается от веба

⚠️ Проблема -> решение

🛠️ Чем помогает и как работает

📚 Ключевые термины (простыми словами)

1. Эмулятор vs реальное устройство

2. Installation / Update / Uninstall

3. Permissions: camera, microphone, location, notifications, files

4. Ориентация и адаптация интерфейса

5. Жесты и системная навигация

6. Прерывания: звонок, уведомления, блокировка, возврат

7. Сеть: slow network, timeout, offline

🆚 Сравнение: веб-подход vs mobile-подход

✅ Must-know факты

Частые мифы

Часто спрашивают на собеседованиях

🚨 Типичные ошибки

🌟 Best Practices

🧾 Заключение

Проверьте знания