Функциональное тестирование на мобиле
Замерил на экране 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, остальные разбираются в тренажёре.
- Что проверяют в офлайн-режиме приложения?A)Что при отсутствии сети приложение немедленно закрываетсяB)Что офлайн-режим нужен только играм, а рабочим приложениям он не требуетсяC)Доступ к кэшу, сообщение об офлайне и синхронизацию при возврате сетиD)Что без сети приложение переустанавливается само собой
показать ответ и разбор
+C)Доступ к кэшу, сообщение об офлайне и синхронизацию при возврате сети// разбор: Многие приложения должны быть полезны без сети: показывать закэшированные данные, давать работать с локальными черновиками, копить действия в очередь. Проверяют: приложение не падает и не зависает офлайн, честно сообщает о состоянии, отдаёт кэш, а при возврате сети синхронизирует накопленное без потерь и дублей. Важно и поведение на «мигающей» сети. Полностью повторить онлайн офлайн не может — часть функций закрыта, и это нормально.
- Что входит в тестирование push-уведомлений?A)Только внешний вид иконки и цвет самого уведомления в шторкеB)Что пуши приходят строго раз в минуту в течение сессииC)Что уведомления работают лишь при уже открытом приложенииD)Доставка в разных состояниях, тап с переходом на нужный экран (deep link), группировка
показать ответ и разбор
+D)Доставка в разных состояниях, тап с переходом на нужный экран (deep link), группировка// разбор: Push-тестирование шире «пришло/не пришло»: доставка при разных состояниях (приложение закрыто/в фоне/открыто), тап по пушу открывает правильный экран (через deep link) с нужными данными, поведение при отключённых уведомлениях в настройках, группировка и не-дублирование, тихие/фоновые пуши, локализация текста, реакция на просроченный пуш. Часть проверок требует реального устройства и боевых пуш-сервисов (APNs/FCM), а не эмулятора.
- Что проверяют при локализации мобильного приложения на разные языки?A)Влезает ли перевод в элементы, формат дат/чисел, направление письма (RTL)B)Что перевод текста выполняется полностью автоматически прямо в приложении на летуC)Что при каждой смене языка приложение приходится переустанавливатьD)Что длина текста на всех поддерживаемых языках получается одинаковой
показать ответ и разбор
+A)Влезает ли перевод в элементы, формат дат/чисел, направление письма (RTL)// разбор: При локализации ломается вёрстка: немецкий/русский длиннее английского и не влезает в кнопки, обрезается или наезжает; арабский/иврит требуют зеркального интерфейса (RTL); меняются форматы дат, чисел, валют, разделителей; шрифт может не поддерживать символы. Проверяют каждую локаль на реальной раскладке, псевдолокализацию для ранней ловли, переключение языка на лету и подстановку переменных в переводах (порядок слов). Автоперевод — не про это.
- Что проверяет тестирование доступности (accessibility) мобильного приложения?A)Скорость запуска и отзывчивость приложения на слабых бюджетных устройствахB)Работу со screen reader (VoiceOver/TalkBack), контраст, размер шрифта, зоны нажатияC)Что приложение доступно для скачивания во всех странах мираD)Доступность серверов приложения по сети в разное время суток
показать ответ и разбор
+B)Работу со screen reader (VoiceOver/TalkBack), контраст, размер шрифта, зоны нажатия// разбор: Доступность — можно ли пользоваться приложением людям с ограничениями. Проверяют: озвучивание экрана screen reader'ом (VoiceOver на iOS, TalkBack на Android) — у элементов понятные подписи и порядок обхода; достаточный контраст; масштаб системного шрифта не ломает вёрстку; крупные зоны нажатия; отсутствие ловушек фокуса; альтернативы жестам. Это требование сторов/законов и расширение аудитории. Слово accessibility ещё используют как ID для автотестов.
- Офлайн на двух устройствах изменили одну запись. Что проверить при синхронизации?A)Что побеждает то устройство, которое синхронизировалось самым первымB)Что оба изменения молча перезапишут друг друга, не оставив следаC)Разрешение конфликта: правило слияния/последней записи и что данные не теряются молчаD)Что синхронизация в такой ситуации не выходит и её следует запретить
показать ответ и разбор
+C)Разрешение конфликта: правило слияния/последней записи и что данные не теряются молча// разбор: Одновременная офлайн-правка одной записи с разных устройств рождает конфликт при синхронизации. Проверяют выбранную стратегию: last-write-wins, слияние по полям, версионирование или явный вопрос пользователю — и главное, что изменения не пропадают молча (потеря данных — тяжёлый баг). Тестировщик воспроизводит: офлайн-правки на двух устройствах, затем возврат сети, и смотрит итог и сообщения. Здесь тесно связаны клиент, бэкенд и продуктовое решение о том, чей результат правильный.
дальше
Теорию прочитали. Навык ставится повторением
В Сеньорчике эта подтема идёт в ежедневных сессиях: движок возвращает её, пока ответы не станут уверенными, и ведёт прогресс отдельно по каждой подтеме. Теория внутри тоже бесплатна, лимит только на количество вопросов в день.