сеньорчикОткрыть в Telegram
← вся теориятеория к собесу · Мобильное тестирование

Функциональное тестирование на мобиле

Функциональные мобильные баги

Замерил на экране 320 на 568 точек - точка тут условная единица вёрстки, не зависящая от плотности пикселей. Кнопка «Оплатить» начинается на 436-й точке по вертикали. Экранная клавиатура съедает снизу около 300 точек - остаётся видимой высота 268. То есть в момент, когда человек заполняет поле, кнопка оплаты физически недоступна. На большом мониторе разработчика этой проблемы не существует.

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

// Формулировки: «какие мобильные функциональные баги частые?», «что не так с клавиатурой?», «как тестировать офлайн?».

Клавиатура и попадание пальцем

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

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

// Второй замер на том же экране - размеры того, куда надо попасть пальцем. Кнопка оплаты получилась 107 на 46 точек, а ссылка «условия» - 53 на 18. Рекомендованный минимум для пальца - примерно 44 на 44 точки (у Android ориентир 48). То есть по ссылке промахиваются, и человек несколько раз тыкает мимо, прежде чем попасть. Мышью такое незаметно, пальцем - раздражает сразу.

перекрытие клавиатурой
экранная клавиатура забирает нижнюю половину экрана вместе с кнопками
размер цели
минимум около 44 точек по каждой стороне, иначе пальцем не попасть

Локализация и размер шрифта

Замер на том же узком экране: ряд из двух кнопок, «Отмена» и основная. По-английски «Sign up» - правый край на 208-й точке из 320, всё хорошо. По-русски «Зарегистрироваться» - 305 из 320, впритык. По-немецки «Jetzt kostenlos registrieren» - 344 из 320, кнопка вылезла за экран. По-французски - 321, тоже не поместилась.

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

// Второй замер - системное увеличение шрифта, которым пользуются очень многие. При обычном размере кнопка занимает 187 точек, при увеличении в полтора раза - 263, при удвоении - 339 из 320 доступных, то есть вылезает. Проверка бесплатная (переключатель в настройках телефона), а находит она сломанную вёрстку у заметной части аудитории - в первую очередь у тех, кто постарше.

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

Офлайн, платежи, системные окна

Офлайн проверял на настоящем движке браузера: с выключенной сетью запрос падает с ошибкой «не удалось получить», а состояние сети доступно приложению отдельным признаком. Значит, у приложения есть всё, чтобы вести себя осмысленно - показать понятное сообщение и предложить повтор, а не крутить бесконечный индикатор.

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

// Платежи - зона повышенного риска, потому что путь уходит из приложения и должен вернуться: подтверждение операции открывается во внешнем окне банка, человек вводит код, и приложение обязано корректно принять возврат. Проверять надо все ветки: успех, отмену, закрытие окна, потерю сети посередине, возврат назад системным жестом. Та же логика с системными окнами - камерой, выбором файла, контактами: человек нажмёт «отмена», и приложение не должно на этом падать.

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

Как отвечать: «Какие мобильные функциональные баги ищешь первыми?»

Начинаю с того, что ломается почти везде. Первое - клавиатура. Я мерил: на экране высотой 568 точек она забирает около трёхсот, а кнопка оплаты стояла на 436-й точке, то есть в момент ввода до неё просто не дотянуться. Поэтому смотрю, перекрывает ли она поля и кнопки, прокручивается ли экран, скрывается ли по нажатию вне поля, и проверяю обязательно на устройстве, а не на компьютере, где экранной клавиатуры нет. Второе - локализация. На узком экране английское «Sign up» занимает двести восемь точек из трёхсот двадцати, русское «Зарегистрироваться» триста пять, а немецкий вариант уже триста сорок четыре, то есть вылезает. Значит, проверяю самым длинным языком, а не родным. Третье - системное увеличение шрифта: при удвоении та же кнопка требует триста тридцать девять точек вместо ста восьмидесяти семи и ломает вёрстку. Дальше офлайн: что работает без сети и, главное, как разрешаются конфликты при отправке накопленного, чтобы не затереть более свежие данные. И платежи с уходом во внешнее окно банка - проверяю возврат при успехе, отмене и потере сети, потому что незакрытый возврат оставляет заказ в подвешенном состоянии.

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

На чём валят

  • Проверять формы на компьютере: экранной клавиатуры там нет, а она забирает больше половины экрана.
  • Верстать по английскому макету: немецкий вариант кнопки вылез за экран на 24 точки.
  • Не включить увеличенный системный шрифт - при удвоении кнопка требует 339 точек из 320.
  • Мелкие ссылки и иконки: 53 на 18 точек против рекомендованных 44 - пальцем не попасть.
  • Отправлять накопленное офлайн без разрешения конфликтов - затираются более свежие данные.

Проверьте себя

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

  1. #mobile_functional1 / 5
    Что проверяют в офлайн-режиме приложения?
    A)Что при отсутствии сети приложение немедленно закрывается
    B)Что офлайн-режим нужен только играм, а рабочим приложениям он не требуется
    C)Доступ к кэшу, сообщение об офлайне и синхронизацию при возврате сети
    D)Что без сети приложение переустанавливается само собой
    показать ответ и разбор
    +C)Доступ к кэшу, сообщение об офлайне и синхронизацию при возврате сети

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

  2. #mobile_functional2 / 5
    Что входит в тестирование push-уведомлений?
    A)Только внешний вид иконки и цвет самого уведомления в шторке
    B)Что пуши приходят строго раз в минуту в течение сессии
    C)Что уведомления работают лишь при уже открытом приложении
    D)Доставка в разных состояниях, тап с переходом на нужный экран (deep link), группировка
    показать ответ и разбор
    +D)Доставка в разных состояниях, тап с переходом на нужный экран (deep link), группировка

    // разбор: Push-тестирование шире «пришло/не пришло»: доставка при разных состояниях (приложение закрыто/в фоне/открыто), тап по пушу открывает правильный экран (через deep link) с нужными данными, поведение при отключённых уведомлениях в настройках, группировка и не-дублирование, тихие/фоновые пуши, локализация текста, реакция на просроченный пуш. Часть проверок требует реального устройства и боевых пуш-сервисов (APNs/FCM), а не эмулятора.

  3. #mobile_functional3 / 5
    Что проверяют при локализации мобильного приложения на разные языки?
    A)Влезает ли перевод в элементы, формат дат/чисел, направление письма (RTL)
    B)Что перевод текста выполняется полностью автоматически прямо в приложении на лету
    C)Что при каждой смене языка приложение приходится переустанавливать
    D)Что длина текста на всех поддерживаемых языках получается одинаковой
    показать ответ и разбор
    +A)Влезает ли перевод в элементы, формат дат/чисел, направление письма (RTL)

    // разбор: При локализации ломается вёрстка: немецкий/русский длиннее английского и не влезает в кнопки, обрезается или наезжает; арабский/иврит требуют зеркального интерфейса (RTL); меняются форматы дат, чисел, валют, разделителей; шрифт может не поддерживать символы. Проверяют каждую локаль на реальной раскладке, псевдолокализацию для ранней ловли, переключение языка на лету и подстановку переменных в переводах (порядок слов). Автоперевод — не про это.

  4. #mobile_functional4 / 5
    Что проверяет тестирование доступности (accessibility) мобильного приложения?
    A)Скорость запуска и отзывчивость приложения на слабых бюджетных устройствах
    B)Работу со screen reader (VoiceOver/TalkBack), контраст, размер шрифта, зоны нажатия
    C)Что приложение доступно для скачивания во всех странах мира
    D)Доступность серверов приложения по сети в разное время суток
    показать ответ и разбор
    +B)Работу со screen reader (VoiceOver/TalkBack), контраст, размер шрифта, зоны нажатия

    // разбор: Доступность — можно ли пользоваться приложением людям с ограничениями. Проверяют: озвучивание экрана screen reader'ом (VoiceOver на iOS, TalkBack на Android) — у элементов понятные подписи и порядок обхода; достаточный контраст; масштаб системного шрифта не ломает вёрстку; крупные зоны нажатия; отсутствие ловушек фокуса; альтернативы жестам. Это требование сторов/законов и расширение аудитории. Слово accessibility ещё используют как ID для автотестов.

  5. #mobile_functional5 / 5
    Офлайн на двух устройствах изменили одну запись. Что проверить при синхронизации?
    A)Что побеждает то устройство, которое синхронизировалось самым первым
    B)Что оба изменения молча перезапишут друг друга, не оставив следа
    C)Разрешение конфликта: правило слияния/последней записи и что данные не теряются молча
    D)Что синхронизация в такой ситуации не выходит и её следует запретить
    показать ответ и разбор
    +C)Разрешение конфликта: правило слияния/последней записи и что данные не теряются молча

    // разбор: Одновременная офлайн-правка одной записи с разных устройств рождает конфликт при синхронизации. Проверяют выбранную стратегию: last-write-wins, слияние по полям, версионирование или явный вопрос пользователю — и главное, что изменения не пропадают молча (потеря данных — тяжёлый баг). Тестировщик воспроизводит: офлайн-правки на двух устройствах, затем возврат сети, и смотрит итог и сообщения. Здесь тесно связаны клиент, бэкенд и продуктовое решение о том, чей результат правильный.

дальше

Теорию прочитали. Навык ставится повторением

В Сеньорчике эта подтема идёт в ежедневных сессиях: движок возвращает её, пока ответы не станут уверенными, и ведёт прогресс отдельно по каждой подтеме. Теория внутри тоже бесплатна, лимит только на количество вопросов в день.