Мобильное тестирование: вопросы для собеседования QA

В мобильном тестировании учитываю матрицу устройств, версии ОС, разрешения, качество сети и системные прерывания.

Проверяю сценарии установки, обновления, работу в фоне, push-уведомления и поведение при смене ориентации.

Из практики: большинство «неуловимых» дефектов появляется на старых устройствах и нестабильной сети.

Сценарии установки: чистая установка, установка при нехватке места, обновление через Store с сохранением данных, даунгрейд на предыдущую версию.

Миграция данных: сохранность пользовательских настроек и локального кэша при обновлении, совместимость форматов внутренней БД приложения между версиями.

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

Проверяю сценарии: медленная сеть (3G/Edge), кратковременная потеря соединения, переключение между Wi-Fi и мобильным интернетом в процессе операции.

Смотрю, как приложение сообщает пользователю о проблеме, можно ли безопасно повторить действие и не создаст ли повтор дублей (например, двойная оплата).

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

Я проверяю, сохраняется ли состояние экрана и данные, если сценарий прервался звонком или уведомлением.

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

Из практики: критично проверить, что после возврата не рвется транзакция и не дублируется действие.

Проверяю поведение при разрешении доступа, при отказе и при повторном запросе: к камере, геолокации, микрофону, уведомлениям и контактам.

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

Из практики: при отказе в разрешении приложение должно объяснить, зачем оно нужно, и предложить путь в настройки — проверяю, что этот флоу работает и не ведёт в тупик.

Проверяю, остаётся ли пользователь в системе после перезапуска и корректно ли восстанавливается состояние экрана.

Отдельно тестирую просроченную сессию и сценарий, когда токен нужно обновить.

Из практики: ошибки с сессией чаще всего проявляются после обновления приложения или смены сети.

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

Смотрю поведение при неустановленном приложении, неверной ссылке и устаревшей версии.

Из практики: чаще всего ломается переход в нужный экран после авторизации.

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

Проверю переход по нажатию, корректность данных и отсутствие дублей.

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

Appium — это фреймворк для автоматизации мобильных, веб- и гибридных приложений на iOS и Android по протоколу WebDriver. Он реализует тот же интерфейс, что и Selenium, поэтому опыт UI-автоматизации легко переносится.

Под капотом Appium общается с системными драйверами: на Android это UiAutomator2 (или Espresso), на iOS — XCUITest. На сервере Appium собирает команды и проксирует их.

Из практики: один и тот же тест-код можно прогнать против Android и iOS, поменяв только capabilities. Это снижает порог входа для команд, которые уже знают Selenium.

Capabilities — это набор параметров, который клиент передаёт серверу при создании сессии. Они описывают, на каком устройстве и приложении тестировать.

Обязательные обычно: platformName (Android/iOS), automationName (UiAutomator2, XCUITest), deviceName, и либо app (путь к APK/IPA), либо bundle/package + activity для уже установленного приложения.

Из практики: capabilities передают через JSON или билдер. На реальных устройствах добавляют udid; на эмуляторах — platformVersion и avd. В команде их часто выносят в фабрику окружений.

Общие: id, xpath, class name, css selector (для web). Платформенные: accessibility id (универсально и стабильно), -android uiautomator (UiAutomator-выражения), -ios predicate string / -ios class chain (для iOS).

Самые стабильные — accessibility id (если разработчики проставляют) и id ресурса (resource-id на Android, name/id на iOS).

Из практики: XPath на мобильных особенно медленный — иерархия большая. Использовать только когда других вариантов нет. Готовое требование к разработчикам: проставлять accessibility-метки.

Нативное — это приложение, написанное под конкретную платформу (iOS/Android). UI рендерится нативными компонентами, доступ через UiAutomator2 или XCUITest.

Веб-приложение запускается в обычном мобильном браузере, тестируется как обычный сайт через chromedriver/safaridriver.

Гибридное — нативный контейнер с WebView внутри. Чтобы тестировать UI внутри WebView, нужно переключить контекст: driver.context('WEBVIEW_...'). Из практики: для гибридов часто половина теста — в NATIVE_APP, половина — в WEBVIEW.

Appium Inspector — это GUI-инструмент, который подключается к запущенной сессии Appium и показывает дерево элементов приложения, их атрибуты и предлагает локаторы.

Также позволяет «прокликивать» приложение и записывать действия, по аналогии с Selenium IDE.

Из практики: основной инструмент, чтобы найти подходящий локатор для элемента. Запускают Appium сервер, потом Inspector, указывают capabilities, открывают приложение и кликают на элементы.

Современный путь — W3C Actions: создаётся последовательность с PointerInput, можно описать тап, долгое нажатие, свайп, drag-and-drop, мульти-тач.

Для удобства есть готовые мобильные команды: driver.executeScript('mobile: swipe', {...}) или 'mobile: tap', 'mobile: longClickGesture'. Они обёртки над платформенными жестами и работают быстрее, чем синтез на низком уровне.

Из практики: для типичных свайпов и тапов используют mobile: команды — они компактнее и стабильнее. Многошаговые жесты пишут через W3C Actions.

Эмулятор/симулятор быстрее запускать, проще автоматизировать, удобно в CI. Реальное устройство показывает поведение под нагрузкой, проблемы с разными производителями, реальную работу с камерой/Bluetooth/жестами системы.

Различия: на эмуляторе нет настоящей сети мобильного оператора, разный набор API, иногда отличается рендеринг. На устройстве — настройка USB-отладки (Android) или provisioning profile (iOS).

Из практики: smoke и регрессии чаще гоняют на эмуляторах для скорости, перед релизом — на парке реальных устройств (фермы устройств: BrowserStack, Sauce Labs, или собственные).

resource-id — это уникальный идентификатор элемента в XML-разметке Android-приложения, формат com.example.app:id/login_button. Видно через Layout Inspector или Appium Inspector.

Локатор устойчив к изменениям текста и положения на экране, потому что задаётся разработчиком как часть кода.

Из практики: если у разработчиков нет accessibility id, resource-id — следующий по приоритету выбор. Внутри Appium ищется через стратегию id.

Accessibility id — это идентификатор для функций доступности (скринридеры, кнопки голоса). На Android это content-desc, на iOS — accessibilityIdentifier. В Appium ищется единой стратегией accessibility id.

Преимущество: один и тот же ключ работает на iOS и Android — кросс-платформенные тесты получают универсальный локатор. Заодно улучшается доступность приложения для пользователей.

Из практики: лучшая инвестиция в автоматизацию — договориться с разработчиками проставлять accessibility id на все интерактивные элементы. Тесты становятся радикально стабильнее.

UiAutomator2 — это драйвер Google для автоматизации Android UI. XCUITest — драйвер Apple для iOS. Оба — фреймворки нативного уровня, идущие в комплекте с SDK.

Appium общается с ними через свои adapter-серверы (например, appium-uiautomator2-driver), которые ставят на устройство специальный helper-сервис и переводят WebDriver-команды в native-команды.

Из практики: на современных Appium 2.x драйверы устанавливаются как плагины через appium driver install. Для большинства задач хватает UiAutomator2 на Android и XCUITest на iOS.

Ориентация: driver.rotation = ScreenOrientation.LANDSCAPE. Работает на эмуляторах и (с ограничениями) на реальных устройствах.

Системные диалоги (разрешения, push) перехватывают через mobile:команды: 'mobile: acceptAlert', 'mobile: dismissAlert'. Часто проще выдать разрешения через capabilities: autoGrantPermissions: true (Android) или autoAcceptAlerts (iOS).

Из практики: разрешения, всплывающие в первый запуск приложения, мешают тестам — лучше включать автоприём в capabilities. Для системных уведомлений и звонков иногда нужен переключатель контекста на NATIVE_APP.

Тест-код (на любом языке с WebDriver-клиентом) обращается к Appium-серверу по HTTP. Сервер парсит запрос, выбирает подходящий драйвер (UiAutomator2, XCUITest, Espresso, Mac, Windows) и проксирует команды этому драйверу.

Драйвер общается с устройством через свой канал: ADB и UiAutomator2-сервер на Android, WebDriverAgent на iOS. Устройство выполняет действие и возвращает результат.

Из практики: эта слоёная архитектура объясняет задержки. Каждый шаг (тест → Appium → driver → device) добавляет миллисекунды, поэтому мобильные тесты ощутимо медленнее десктоп-веб.

По умолчанию (noReset=false, fullReset=false) Appium сбрасывает состояние приложения — на Android очищает его данные (pm clear), не удаляя само приложение. noReset=true оставляет прежнее состояние и ничего не чистит.

fullReset=true — полная очистка: приложение удаляется и переустанавливается (Android — uninstall перед сессией и после неё, iOS — глубокая очистка). noReset быстрее, fullReset дольше, но гарантирует чистоту.

Из практики: для большинства проектов оптимально дать сценарию свою подготовку (логин, очистка) и не делать fullReset на каждом тесте. Полная переустановка — для smoke первого запуска.

Скриншот: driver.getScreenshotAs(...). Простая команда, доступная всегда. Имеет смысл прикладывать к отчёту падения.

Видео: driver.startRecordingScreen() в начале, driver.stopRecordingScreen() в конце — возвращает Base64 mp4. На Android и iOS работает с разными ограничениями (на iOS Simulator до недавнего времени видео не записывалось из коробки).

Из практики: для упавших тестов автоматическое сохранение скриншота и видео сильно облегчает разбор. В фреймворках вроде JUnit/TestNG это вешают на @AfterEach с проверкой статуса.

На Android запускают приложение по URL через adb или через mobile-команду: driver.executeScript('mobile: deepLink', { url: 'myapp://path' }). На iOS — аналогично mobile: deepLink или через Safari.openUrl.

Это позволяет проверить, что приложение правильно открывается из ссылок (email-письма, share, push), и сразу попасть в нужный экран.

Из практики: deep linking тесты заменяют долгие сценарии «свайп-свайп-кнопка». Каждое появление новой ссылки — отдельная проверка.

В Appium 2.x ядро сервера отделено от драйверов. Драйвер для каждой платформы (uiautomator2, xcuitest, espresso, mac2, windows) устанавливается отдельной командой: appium driver install uiautomator2.

Плагины (appium plugin install ...) добавляют функциональность: relaxed-caps (мягкая валидация), images (поиск по изображению), execute-driver (chains команд).

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

Запуск возможен только на macOS — нужны Xcode и WebDriverAgent. Сборка приложения требует подписи (developer profile, simulator-сертификат).

Симулятор и реальное устройство имеют разные ограничения: на симуляторе нет камеры, Bluetooth, push с APNS работает условно. Контроль доступа к фото/контактам отличается.

Из практики: для iOS-автоматизации обязательно нужен Mac в CI (или фарма). Установка WebDriverAgent на реальное устройство требует доступа к Apple Developer и иногда танцев с подписью.

Использовать явные ожидания (WebDriverWait/FluentWait) с понятными условиями: ExpectedConditions.elementToBeClickable, visibilityOfElementLocated, presenceOfElementLocated.

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

Из практики: типовая ошибка — pageObjects тонут в фиксированных sleep. Когда тестов становится много, прогон растёт на минуты. Замена на ожидания по состоянию сразу даёт +30-50% скорости.

Базовая схема: установить Node и Appium, поставить нужные драйверы, запустить эмулятор (или подключиться к фарме устройств), стартовать Appium-сервер в фоне, запустить тесты, собрать артефакты (логи Appium, скриншоты, видео).

На Linux можно поднимать Android-эмулятор (с KVM). Для iOS нужен раннер на macOS. Альтернатива — использовать облачные фермы (BrowserStack, Sauce Labs, AWS Device Farm).

Из практики: первое, что стоит автоматизировать — установка зависимостей и запуск Appium-сервера. Дальше — управление эмулятором через скрипты (avdmanager, emulator -avd). Каждый прогон в чистой среде.

Espresso (Android) и XCUITest (iOS) — нативные фреймворки разработчиков. Они быстрее и стабильнее Appium, но пишутся отдельно под каждую платформу.

Detox — фреймворк для React Native, ориентированный на синхронизацию с приложением. Maestro — современный кроссплатформенный фреймворк на YAML с упрощённым синтаксисом.

Из практики: если команда — нативные разработчики, часто выбирают Espresso/XCUITest. Если есть QA-инженеры и кросс-платформа важна — Appium или Maestro. Detox — типичный выбор для React Native.

Главные отличия: огромная фрагментация устройств и версий ОС, особенности интерфейса (тачи, жесты, разные экраны), особые сценарии (звонки, разряд батареи, потеря сети), магазины (Google Play, App Store) с их правилами, требования к производительности и батарее.

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

Из практики: помимо UI и API, в чек-листы добавляют сценарии перехода в фон, прерываний (входящий звонок, push, выключение экрана), работы в офлайн, разных уровней яркости/доступности.

Включают авиарежим, отключают Wi-Fi, ослабляют сигнал (через эмулятор или сетевую утилиту), имитируют медленную сеть (Charles, Network Link Conditioner, эмулятор Android).

Проверяют: понятное сообщение пользователю, повтор запроса при возврате сети, корректное состояние UI (нет вечного спиннера), сохранение черновика данных.

Из практики: типовые баги — приложение «зависает» в загрузке, теряет введённые данные при попытке отправки, не повторяет автоматически и требует ручного действия. Тесты на офлайн — обязательная часть приёмки.

Прерывание — это любое событие, отвлекающее приложение: входящий звонок, push, будильник, низкий заряд, потеря сети, переход в фон по нажатию Home.

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

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

Используют набор устройств с разными разрешениями и плотностями (DPI), от компактного 4-дюймового до 6.7" и планшетов. На iOS — iPhone SE, обычный, Pro, iPad. На Android — несколько производителей и версий.

Проверяют: не обрезаются ли тексты, не наезжают ли элементы, корректно ли работают модальные окна, как ведёт себя ландшафтная ориентация.

Из практики: больше всего вытекает текст у длинных языковых вариантов (немецкий, русский, языки RTL), у мелких экранов или системного крупного шрифта (Dynamic Type на iOS).

Ручное тестирование — прокликивание всех ключевых жестов на разных устройствах. Особое внимание системным жестам (свайп с края на iOS, gesture-навигация на Android) и их конфликту с приложением.

В автотестах — Appium W3C Actions, Espresso GeneralSwipeAction, XCUITest swipeLeft/swipeRight, hold/longTap.

Из практики: типовые баги — приложение перехватывает системный свайп назад, неправильно реагирует на «pinch to zoom», long press открывает не то меню. Чек-лист жестов фиксируют в тест-плане.

Сценарии: первый запуск без разрешения, отказ, отзыв в настройках, повторный запрос. Проверяют, что приложение корректно ведёт себя в каждом случае: показывает понятное объяснение, не падает, предлагает путь в настройки.

На Android разрешения runtime появились с API 23. На iOS встроенный диалог появляется при первом обращении, далее — только через настройки.

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

Сценарии: получение в активном/фоновом/убитом приложении, открытие уведомления (deep link в нужный экран), badge counter, поведение при отказе от разрешения, при отсутствии сети.

Для отправки тестовых push используют админку проекта, Firebase Cloud Messaging Console, инструменты под APNs.

Из практики: типовые баги — открытие push не ведёт в нужный экран в холодном старте, badge не сбрасывается, push приходит с задержкой и пользователь успевает совершить дублирующее действие.

Холодный старт — процесс приложения не запущен, ОС поднимает его с нуля, инициализирует, загружает данные. Самый долгий.

Тёплый старт — процесс был, но активити/контроллер пересоздаются. Быстрее.

Горячий старт — приложение в памяти и возвращается из фона без пересоздания. Самый быстрый.

Из практики: метрика time-to-interactive холодного старта — ключевая для пользовательского опыта. Цель — обычно 1-2 секунды на флагмане, 3-4 на бюджетке.

Проверяют все поддерживаемые языки: переводы корректны, не обрезаются, влезают в кнопки, корректные форматы дат, чисел, валюты. Для RTL-языков (арабский, иврит) проверяют разворот раскладки и иконок.

На iOS меняют язык приложения отдельно от системы (с iOS 13). На Android — системный язык, дублированные ресурсы по локалям.

Из практики: типовые баги — обрезание длинных строк (немецкий), пропущенные переводы (показывают ключ), неправильные плюрализации (1 файл / 5 файлов), кривой RTL.

Доступность — это возможность пользоваться приложением для людей с ограничениями зрения, слуха, моторики. Главное на мобильных: совместимость со скринридерами (VoiceOver на iOS, TalkBack на Android), управление крупным шрифтом, контрастные цвета.

Проверяют: каждый интерактивный элемент имеет осмысленное название (accessibility label), порядок чтения логичен, есть фокус и кнопка не «глотает» содержимое.

Из практики: чек-лист — пройти основные сценарии включённым VoiceOver/TalkBack, включить «крупный текст», «увеличение контраста», «уменьшить движение».

Меняют системный размер шрифта на максимальный (Dynamic Type на iOS, размер шрифта в Android Accessibility) и проходят основные сценарии. Также часто есть «масштаб экрана» — увеличивает все элементы.

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

Из практики: типовые баги — фиксированная высота строк, обрезание заголовка, налезание на другие элементы. Лучше делать раскладку с учётом наибольшего размера.

Помимо функциональности проверяют соответствие правилам: возрастной рейтинг, обработка персональных данных, корректные разрешения, требования к промо-материалам (скриншоты, описание).

Дополнительные сценарии: установка через магазин (а не sideload), обновление с предыдущей версии (миграции данных), in-app покупки в sandbox-режиме.

Из практики: ревью магазина может занимать дни. Отказ из-за мелочи (слишком приватный текст в скриншоте, нечёткая иконка) — обычное дело. Тестировщик отвечает не только за код, но и за метаданные.

На iOS используют Sandbox-аккаунты в App Store Connect: создают тестового пользователя, входят в Sandbox в настройках устройства, проводят покупку без реальной оплаты.

На Android — тестовые аккаунты в Google Play Console, тестовые карты Google Pay, режимы test для подписок.

Из практики: критичные сценарии — успешная покупка, отмена, восстановление покупок, истечение подписки, повторная попытка после сетевой ошибки. Также проверяют локализованные цены.

Базовые: вход по логину/паролю, восстановление, регистрация, выход. Дополнительно: соцсети (OAuth), Apple ID (требование iOS), Google Sign-In, биометрия (Face ID, Touch ID, отпечаток).

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

Из практики: важна проверка биометрии (а если её сменили на другую — отозвался ли доступ), и того, что приложение не показывает чувствительные данные в task switcher (скриншот превью).

Сценарии: съёмка фото и видео, выбор из галереи, переключение камер, флеш, отмена, сжатие, EXIF (геопозиция, ориентация), поведение без разрешения.

Проверяют корректность вращения (часто фото с iPhone приходят повёрнутыми), размер, что превью совпадает с итоговым файлом.

Из практики: типовые баги — фото вверх ногами, потеря данных при переходе в галерею и обратно, OOM при больших файлах, неверная обработка отмены пользователем.

Утечка — это память, которая занята объектами, на которые сохранились ненужные ссылки, и они не освобождаются сборщиком мусора (Android) или ARC (iOS). Потенциальные источники: статические ссылки на контекст, забытые слушатели, замыкания, удерживающие view.

Инструменты: Android Studio Memory Profiler + LeakCanary, Xcode Instruments (Allocations, Leaks). Открывают сценарий, переходят туда-обратно, смотрят, растёт ли использование памяти.

Из практики: типовая ситуация — листая ленту, видишь рост памяти на сотни МБ. Поиск виновника — снимки кучи в двух точках и сравнение dominator tree.

Сценарии: первый ввод и сохранение в keystore/keychain, успешная биометрия, отказ (неверный отпечаток), отсутствие настроенной биометрии, отзыв (добавлен/удалён отпечаток), переход к запасному способу (пароль).

Эмуляторы поддерживают эмуляцию биометрии. На iOS Simulator — Features → Face ID. На Android — adb команды или меню эмулятора.

Из практики: критично проверить, что при добавлении нового отпечатка приложение требует повторной аутентификации (защита от подмены). Это требование банков и любых чувствительных приложений.

Android: высокая фрагментация устройств и версий, разные оболочки производителей (One UI, MIUI, HyperOS), кнопка/жест «назад», runtime-permissions, sideload APK для теста.

iOS: меньше устройств, но строже правила Apple, единый магазин, нет кнопки «назад» (свайп), кардинально иной механизм фоновой работы, требование подписи и provisioning profile.

Из практики: на Android больше комбинаторного покрытия по устройствам/прошивкам. На iOS — больше внимания к деталям UI и правилам ревью. Подход к автоматизации тоже отличается.

Создают набор ссылок для каждого важного сценария (открытие профиля, оплата, акция) и проверяют: открываются при тапе в почте/чате, ведут в нужный экран и в холодном, и в горячем старте, не теряют параметры.

На iOS Universal Links требуют файл apple-app-site-association на домене. На Android — App Links через assetlinks.json. Без них откроется браузер, а не приложение.

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

Тестируют: установка с нуля, обновление с предыдущей версии (миграция данных в локальной БД, новые таблицы, переезд настроек), обновление с очень старой версии (несколько шагов миграций подряд).

Также проверяют сценарии in-app update (forced update / soft update на Android) и поведение при отказе пользователя обновляться.

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

На Android есть режим энергосбережения, который ограничивает фоновую работу, GPS, push, синхронизацию. На iOS — Low Power Mode, отключающий фоновые задачи и снижающий частоту обновлений.

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

Из практики: типовые баги — приложение продолжает потреблять много энергии в фоне, не уважает Doze/App Standby, push приходит с задержкой. Battery Historian для Android помогает анализу.

К стандартным функциональным/нефункциональным добавляются: тестирование на разных устройствах (device coverage), на разных версиях ОС, на разной плотности экрана, тестирование жестов, прерываний, фоновой работы, push, deep links, in-app покупок.

Также есть пилотное распространение через TestFlight / Internal Testing, бета-тесты, проверка в Sandbox для покупок.

Из практики: тест-план для мобильного приложения обычно длиннее, чем для веб-приложения той же сложности, именно из-за платформенной специфики.

ProGuard (старое имя) и R8 (актуальный) — это утилиты, которые в release-сборке Android урезают неиспользуемый код и обфусцируют имена классов/методов. Уменьшают размер APK и затрудняют реверс-инженеринг.

Минус для тестирования: после обфускации reflection и сериализация могут сломаться. Названия классов в логах превращаются в a, b, c.

Из практики: release-сборку обязательно прогоняют через smoke-тесты — обфускация может что-то сломать, что не видно в debug. Для отладки крашей используют mapping.txt для разобфускации стектрейса.

Тестируют: специально воспроизводят сценарий, который должен крашить приложение (или используют тестовую кнопку «Force crash»). Проверяют, что отчёт о краше появился в выбранной системе мониторинга (Crashlytics, Sentry, App Center).

Также проверяют группировку (одинаковые краши не плодят дубли), наличие стектрейса, переменных, breadcrumbs.

Из практики: «тестовая кнопка краш» — стандарт. Тестировщик в новой сборке нажимает её и убеждается, что краш виден в админке системы мониторинга через 1-2 минуты.

ANR (Application Not Responding) — это ситуация, когда главный поток приложения заблокирован дольше определённого времени (обычно 5 секунд для input). Система предлагает пользователю закрыть приложение.

Причины: тяжёлая работа на UI-потоке, ожидание ответа от сети без таймаута, дедлоки, синхронные операции с диском.

Из практики: для отладки используют strict mode, traces.txt в /data/anr, Firebase Crashlytics ANR reports. Тестируют намеренно — открывают приложение на медленной сети и проверяют, что не зависает.

Responsive — одна вёрстка, которая плавно подстраивается под любую ширину экрана через CSS-медиа-запросы и гибкие сетки. Adaptive — несколько фиксированных макетов для конкретных breakpoint'ов (mobile, tablet, desktop).

Responsive гибче, adaptive проще оптимизировать под конкретные размеры.

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

Типовая шкала: 320 (старые iPhone SE), 375 (обычные iPhone), 414 (Pro Max), 768 (iPad портрет), 1024 (iPad ландшафт), 1280+ (desktop).

Также бывает плотность: 1x, 2x, 3x — для retina-экранов. Изображения могут показываться по-разному.

Из практики: 320 — самая «узкая» норма, ниже редко тестируют. 768 — критическая точка перехода телефон/планшет.

В DevTools браузера есть переключатель Offline в Network. Также можно эмулировать «slow 3G» или вообще «no throttling».

Для PWA проверяют: грузится ли offline shell, работают ли кеш и Service Worker, корректно ли восстанавливается после возврата сети.

Из практики: типовые баги — отсутствие fallback-страницы, бесконечный спиннер, потеря введённых данных при восстановлении.

Gesture handler — компонент, обрабатывающий жесты (свайп, drag, pinch). На Android часто свайп слева — системный «назад», что конфликтует с приложением.

Также есть конфликт между несколькими жестами в одном экране (карусель внутри прокручиваемой страницы).

Из практики: типовые баги — свайп срабатывает только в части экрана, конфликт с системным жестом, проблема с прокруткой внутри карусели.

Safe area — область экрана, свободная от системных элементов: нотча (челки), индикатора Home, статус-бара. На iPhone X+ и многих Android-устройствах эта область отличается от полного экрана.

В CSS — env(safe-area-inset-top), в SwiftUI/UIKit — встроенные API.

Из практики: типовые баги — кнопка под Home-индикатором, текст за нотчем, фон не доходит до краёв. Проверяют на устройствах с разной формой экрана.

Сценарии: open/close клавиатуры, перекрывание полей (поле должно проскроллиться), переключение между input через next, типы клавиатур (numeric, email, url), autocorrect/autocapitalize.

Также проверяют интеграции: автозаполнение из менеджера паролей, подсказки браузера.

Из практики: типовые баги — кнопка submit под клавиатурой, autocomplete заполняет не те поля, неправильный тип клавиатуры (буквы вместо цифр).

App size — размер итогового пакета. Большие приложения теряют пользователей при установке (особенно в развивающихся регионах).

Оптимизации: code splitting (Android App Bundle, iOS app thinning), удаление неиспользуемых ассетов, сжатие изображений, ProGuard/R8, отказ от неиспользуемых SDK.

Из практики: 100-150 МБ — норма, 200+ — повод оптимизировать. Также важен initial download — сколько грузится при первом запуске.

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

Особое внимание — кастомным компонентам, картинкам (иногда нужны варианты для каждой темы), графикам.

Из практики: типовые баги — белый текст на белом фоне в тёмной теме, иконки только для одной темы, диалоги не наследуют тему.

С Android 10 есть gesture navigation — нет кнопок «назад», «домой», «обзор». Жесты с краёв экрана выполняют эти функции.

Это создаёт конфликты с приложениями, использующими свайп с края: списки с действиями свайпом, drawer-меню.

Из практики: тестировать обязательно — на устройствах с gesture navigation поведение может отличаться. Решение в коде — exclude rects из системных жестов.

Сценарии: показ уведомления в нужное время, при разных состояниях приложения (активное, фон, убито), переход в нужный экран по клику, корректное отображение текста/иконки/действий.

Также проверяют: badge, звук, вибрация, поведение при отказе от разрешения.

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

В Appium 2.x ядро отделено от драйверов. Драйвер устанавливается отдельно: appium driver install uiautomator2. Плагины добавляют функциональность поверх (images, execute-driver).

Это упрощает обновление: можно обновить только драйвер без сервера и наоборот.

Из практики: при настройке CI явно укажите версии драйверов — иначе при обновлении приедет несовместимая.

Это специальные команды, вызываемые через driver.executeScript('mobile: <name>', args). Они дают доступ к платформенным фичам, не входящим в WebDriver-протокол.

Примеры: 'mobile: deepLink', 'mobile: shell' (Android adb shell), 'mobile: scrollGesture', 'mobile: terminateApp'.

Из практики: значительно упрощают сценарии — вместо длинных серий swipe можно одной командой проскроллить до элемента.

Несколько Appium-серверов на разных портах + по одному устройству/эмулятору каждому. Тесты распределяются между серверами через свои capabilities (udid, systemPort).

Альтернатива — облачные фермы (BrowserStack, Sauce Labs), где параллелизация настроена на их стороне.

Из практики: главное — не путать systemPort у UiAutomator2 — каждой инстанции свой, иначе конфликт.

Espresso — фреймворк автотестов Google для Android. Appium Espresso Driver проксирует WebDriver-команды в Espresso API, давая более глубокий доступ к внутренностям приложения и стабильность.

Минус — нужно встраивать в APK тестовый apk Espresso. UiAutomator2 не требует.

Из практики: Espresso выбирают, когда нужна максимальная стабильность и доступ к внутренностям. UiAutomator2 — когда тестируют чужой APK.

Готовые образы (например, appium/appium) содержат Appium и Android SDK. Подключаются к запущенному эмулятору на хосте или к удалённой ферме.

Если эмулятор тоже в Docker — нужна поддержка KVM (для x86 эмулятора) и проброс /dev/kvm.

Из практики: в CI часто запускают Appium-сервер в контейнере, а сами тесты — рядом. iOS-тесты в Docker не запустить (нужен macOS-раннер).

Через adb (Android) reboot или специальные mobile-команды. После ребута нужно дождаться, пока система прогрузится, и проверить сценарии: запускается ли приложение, восстанавливаются ли данные, приходят ли push.

Также проверяют автозапуск, если он есть, и поведение фоновых сервисов.

Из практики: после ребута часто всплывают баги с инициализацией — приложение падает, теряет состояние, забывает токен.

WebDriverAgent (WDA) — нативное iOS-приложение от Facebook (теперь Meta), реализующее WebDriver-протокол на iOS. Appium iOS-драйвер ставит WDA на устройство и общается с ним.

WDA нужно подписать сертификатом для установки на реальное устройство (development или enterprise).

Из практики: проблемы с WDA — типичная причина неработающих iOS-тестов. Версия WDA должна быть совместима с Xcode и iOS.

На Android: autoGrantPermissions: true в capabilities. На iOS: autoAcceptAlerts: true или autoDismissAlerts: true. Точечно — driver.switchTo().alert().accept().

Также есть mobile-команды: 'mobile: acceptAlert', 'mobile: dismissAlert'.

Из практики: лучше выдавать разрешения через capabilities, а не реагировать на каждый pop-up в тесте — тесты стабильнее.

Тесты на iOS требуют macOS (Xcode, signing). WebDriverAgent нужно подписать. Реальные устройства требуют developer profile. Симулятор не поддерживает камеру, push с APNs работает условно.

Также: задержки запуска WDA на холодном старте, отличия simulator vs real device, ограничения accessibility.

Из практики: бюджет на iOS-инфраструктуру обычно больше, чем на Android. Это нужно закладывать заранее.

Приоритет: accessibility id (кросс-платформенно), resource-id (Android), name/id (iOS). XPath — последнее средство, медленный и хрупкий.

Договариваться с разработчиками о расстановке accessibility-меток. Это инвестиция, окупающаяся стабильностью тестов.

Из практики: проект с правильно расставленными accessibility id — radically стабильные тесты. Без них — постоянная борьба с локаторами.

Облачные сервисы, предоставляющие парк реальных и эмулированных устройств. Тесты запускаются на их инфраструктуре через стандартный WebDriver/Appium endpoint.

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

Из практики: для команд без большого количества устройств — практически обязательно. Особенно ценно для пред-релизных регрессий на разнообразных устройствах.

На симуляторе iOS можно дать приложению доступ к фейковой галерее через настройки. На Android — adb push изображения в /sdcard/Pictures.

Для самой камеры — на симуляторе она «фейковая». На реальном устройстве полный тест возможен.

Из практики: для CI часто настраивают фикстуру — подсунуть фото в галерею, открыть приложение, проверить выбор. Сама съёмка тестируется руками на реальных устройствах.

element.getScreenshotAs(...) делает скриншот области конкретного элемента — поддерживается в большинстве драйверов.

Альтернатива — сделать скриншот всей страницы и обрезать по координатам элемента (element.getLocation() и getSize()).

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

Гибридное приложение — нативный контейнер с WebView внутри. Контексты: NATIVE_APP и WEBVIEW_*. driver.getContextHandles() — список доступных. driver.context('WEBVIEW_...') — переключение.

Внутри WebView работают обычные веб-локаторы. В нативной части — мобильные.

Из практики: типовые сценарии — нативные кнопки, потом форма в WebView, потом обратно нативная навигация. Важно вовремя переключать контекст.

Под одну платформу — меньше комбинаторики, можно глубже копать платформо-специфичные сценарии. Под обе — двойной объём, но похожая логика, отличия в UI/UX.

Стратегии: общие чек-листы + платформенные дополнения; общая команда vs специализация по платформам.

Из практики: для кросс-платформенных приложений (React Native, Flutter) часть тестов общая, но UI всегда разный. Полностью идентичных тестов почти не бывает.

Создать состояние на старой версии (зайти, добавить данные, накопить настройки), обновить на новую, проверить, что данные на месте и работают новые фичи.

Также тестируют downgrade (если такая ситуация возможна), миграцию через несколько версий (пользователь не обновлялся год).

Из практики: подготовленные снимки старых версий — основная инвестиция. Без них каждое тестирование миграций — кошмар.

Сценарии: поделиться текстом/ссылкой/изображением в разные приложения (Telegram, WhatsApp, Mail, копирование), приём share из других приложений.

Также проверяют ограничения: размер файла, типы контента, поведение при отсутствии целевого приложения.

Из практики: типовые баги — share не работает при отсутствии текста, странное форматирование в разных приёмниках, потеря метаданных.

Widget на iOS и Android — отдельный компонент на главном экране. Тестируют установку, отображение, обновление, deep link при клике, разные размеры.

Live Activity (iOS 16.1+) — обновляемое уведомление в Dynamic Island. Тестируют запуск, обновление через push, корректность UI.

Из практики: виджеты ограничены по обновлению (Android — 30 мин минимум, iOS — система решает). Тесты учитывают эти ограничения.

Сценарии: разрыв сети в середине запроса, медленная сеть, неверный ответ сервера (5xx, 4xx), таймаут, неверный формат JSON.

Инструменты: Charles Proxy / Burp для замены ответов, эмулятор Android для throttling, Apple Network Link Conditioner.

Из практики: типовые баги — приложение зависает на спиннере без таймаута, нет retry-логики, теряет данные при разрыве.

На Android есть WorkManager, JobScheduler, AlarmManager. На iOS — BackgroundTasks framework. Все они работают в условиях Doze, App Standby и системных ограничений.

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

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

A/B-тест — показать разным группам пользователей разные варианты, измерить разницу в поведении/конверсии. Реализуется через feature flag сервисы (Firebase Remote Config, Optimizely).

QA проверяет: корректность распределения пользователей, отображение каждого варианта, отслеживание метрик, фолбэк при отказе сервиса.

Из практики: часто QA должен войти под разные user_id и подтвердить, что каждый получает свой вариант. Используются override-механизмы в debug-сборке.

iPad с клавиатурой поддерживает hardware shortcuts: Command+N для новой записи и т.п. Тестируют наличие, корректность, обнаружение через долгое нажатие Command.

Также проверяют VoiceOver (включается в Settings → Accessibility), Switch Control, Dynamic Type, Smart Invert.

Из практики: для серьёзных приложений iPad — полный аналог desktop. Без поддержки клавиатуры пользователи воспринимают приложение как «недоделанное».

Размер APK/IPA смотрят в Play Console / App Store Connect. Также инструменты: Android Studio APK Analyzer, Xcode size report — анализируют, что занимает место (ассеты, библиотеки, код).

Размер обновления через App Bundle / app thinning часто меньше, чем при первой установке.

Из практики: на iOS приложения крупнее ~200 МБ не качаются по сотовой сети без Wi-Fi (пользователь может разрешить вручную). На Android 150 МБ — это максимальный размер загрузки при доставке через App Bundle, а не лимит сотовой сети; крупные загрузки Google Play просто предупреждает.

Feature flags позволяют включать/выключать функции без выпуска новой версии в магазин. Тестировщикам нужно проверять как состояние «ON», так и «OFF».

Особенно важно: что приложение корректно работает при отсутствии remote config (например, кеш или дефолтное значение).

Из практики: для мобильных flags имеют ещё одну особенность — после выпуска версия живёт долго (пользователи обновляются медленно), и flag должен поддерживаться месяцами.

Сценарии: восстановление аккаунта на новом устройстве (логин), перенос данных через iCloud/Google Backup, перенос покупок.

Проверяют: что доступ к контенту восстанавливается, локальные данные либо переносятся (если есть backup), либо корректно отсутствуют.

Из практики: типовые баги — потеря доступа к контенту, дублирование purchases, неправильное состояние после restore.

На iOS — Screen Time / Family Sharing с restrictions. На Android — Family Link. Эти системы могут блокировать установку, покупки, доступ к контенту.

Сценарии: попытка покупки с ребёнка → запрос родителю, ограничение контента по возрасту, блокировка приложения по расписанию.

Из практики: для приложений, ориентированных на детей или семьи, обязательная проверка. Также для apps с in-app purchases.

Сценарии: открыть ссылку в Telegram, WhatsApp, SMS, email. Каждый мессенджер по-своему обрабатывает ссылки (свой in-app browser, прямое открытие).

Также проверяют: parameters не теряются, universal link корректно открывает приложение, fallback на сайт работает.

Из практики: типовые баги — Telegram открывает ссылку в своём браузере вместо приложения, потеря utm-параметров, deep link в холодном старте не открывает нужный экран.

Silent crash — это краш или зависание (ANR), которое не показывается пользователю явно (или приложение «возвращается» само), но логируется в системе.

Признаки: пропали данные за период, метрики «session length» резко падают, негативные отзывы «зависает». Ищут в crashlytics, ANR reports, ratings.

Из практики: silent crashes часто более вредны, чем явные — пользователь не понимает, что произошло, и просто удаляет приложение.

Декларативные UI-фреймворки имеют свои подводные камни: проблемы с re-композициями (производительность), state management, navigation, accessibility, фокус.

Часто баги связаны с порядком rerender, missed updates, утечками в @Composable / @ViewBuilder.

Из практики: тестировщик должен понимать, что compose/SwiftUI — относительно новые технологии, и баги в них возникают чаще, чем в классических UIKit/Android Views.

Когда несколько жестов в одном экране срабатывают одновременно или мешают друг другу: вертикальный скролл vs горизонтальная карусель, swipe-back vs кнопка с swipe-action.

Тестируют: проверяют все возможные комбинации жестов на экране, особенно с границами и углами.

Из практики: типовые конфликты — карусель внутри скроллящейся страницы, swipe-to-delete возле края экрана с системным swipe-back.

Cold — процесс с нуля, инициализация Application, ContentProvider, основной Activity. Самый долгий.

Warm — процесс был, Activity пересоздаётся. Hot — Activity вернулся из фона без пересоздания.

Из практики: оптимизируют cold start больше всего — первое впечатление пользователя. Цель — 1-2 секунды на флагмане.

iOS 14+ показывает индикатор, когда приложение читает clipboard. Это сделано для защиты приватности. Android 13+ — то же.

Тестируют: не читает ли приложение clipboard без необходимости, нет ли утечек, корректное поведение при отказе.

Из практики: чтение clipboard на старте — анти-паттерн (был у TikTok, скандал). Чтение должно быть по явному действию пользователя.

ATT (с iOS 14.5) требует у пользователя разрешения отслеживать его между приложениями через IDFA.

Тестируют: показывает ли приложение запрос, корректно ли обрабатывает отказ, не запрашивает ли тогда, когда не должно.

Из практики: после отказа пользователя приложение получает обнулённый IDFA. Маркетинговые SDK должны это учитывать.

Геолокация в фоне — особый случай. На iOS требует Always permission, на Android — ACCESS_BACKGROUND_LOCATION (с 10).

Сценарии: разрешение When in Use vs Always, обновления в фоне, точность (precise vs approximate, iOS 14+).

Из практики: операционные системы агрессивно ограничивают background location ради батареи. Приложение должно корректно обрабатывать отказ или редкие обновления.

Pull-to-refresh — жест: потянуть вниз, чтобы обновить. Стандартный на iOS и Android, у большинства списочных экранов.

Тестируют: индикатор показывается, контент обновляется, корректное поведение при медленной/нет сети, не конфликтует ли со scroll, работает ли на пустом списке.

Из практики: типовые баги — индикатор не пропадает, обновляется не то, что показывает экран, дублирование данных.

Skeleton — placeholder в форме контента, показывающий примерную раскладку. Spinner — крутящийся индикатор без указания формы.

Skeleton ощущается как «уже что-то загружается», улучшает воспринимаемую производительность.

Из практики: для основных экранов — skeleton. Для коротких операций — spinner. Иногда комбинируют: skeleton + spinner внутри.

Edge-to-edge — приложение рисует под statusBar и navigationBar, давая иммерсивное ощущение. Системные элементы становятся полупрозрачными.

Требуется от Android 15 (target SDK 35). Без этого приложение может выглядеть «старомодным».

Из практики: при переходе на edge-to-edge нужно учитывать insets — чтобы кнопки не оказались под навигацией. Compose имеет API для этого.

Подробный документ с правилами публикации в App Store. Категории: безопасность, производительность, бизнес, дизайн, легальность. Часто меняется.

Типовые блокеры: in-app purchases только через Apple, неработающие функции в скриншотах, неподходящий контент, sensitive permissions без объяснения.

Из практики: перед сабмитом смотрят на актуальные правила. Отказ может задержать релиз на несколько дней.

Manifest.json — описание PWA: имя, иконки, цвета, start_url, display mode (standalone, fullscreen). На основе этого браузер предлагает «Install» и показывает приложение как нативное.

Тестируют: установка работает, иконки показываются, splash screen корректный, оффлайн доступ через Service Worker.

Из практики: PWA — компромисс между web и нативом. На iOS поддержка ограничена, на Android полноценная.

Контекстные действия из домашнего экрана при долгом нажатии на иконку приложения. На Android — App Shortcuts, на iOS — 3D Touch / Haptic Touch Quick Actions.

Тестируют: правильные действия в shortcut, корректный deep link на нужный экран, поведение, если приложение не запущено.

Из практики: shortcut'ы — отличный shortcut для частых действий (например, начать новый чат, открыть избранное).