Home

Автор: Хилке де Йонг (Hylke de Jong)
Оригинал статьи
Перевод: Ольга Алифанова

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

Учитывать приходится множество мобильных устройств, браузеров и операционных систем. Но такое обилие возможностей вызывает один довольно важный вопрос: как узнать, на каких браузерах и устройствах тестировать?

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

Ключевые факторы

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

Начнем с устройств. Нужно определить, чем они на самом деле отличаются.

Размер экрана кажется очевидным кандидатом, но на самом деле он не так уж и важен. Ваше приложение будет одинаково смотреться на экранах в 5, 5,5 и 6 дюймов, если эти экраны используют одинаковое разрешение (к примеру, 1920 на 1080). Элементы просто будут чуть крупнее илимельче.

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

Почему мы смотрим только на ширину, а не на высоту? Наше приложение работает только в портретной ориентации. Экран длиннее или короче просто покажет больше или меньше вертикально расположенной информации, но не повлияет, в отличие от ширины экрана, на рендер всего приложения. Не особо запыхавшись, мы сократили наш список устройств с 9 до 3. Едем дальше: версии Android.

Версии Android в самом низу, отмеченные красным, слишком пожилые, чтобы их поддерживать, и не входят в наши задачи. Остается пять версий.

Их я тоже сгруппировал. На этот раз я исходил из мажорных релизов. Это может прозвучать нелогично для многих, но я пока не сталкивался с ситуацией, когда что-то работает на Android 8.0 и не работает на Android 8.1.

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

Имея эту информацию, остается только смешать и сопоставить. Комбинируя устройства (или ширину экрана) с версиями Android, мы уложимся в три прогона тестов.

Кто-то может решить тестировать каждое мобильное устройство со всеми версиями Android (9 прогонов), но как по мне, это уже перебор. Не особенно привязывайтесь и к маркам устройств. Если какое-то из них вам недоступно, возьмите другое с тем же разрешением экрана (не размером!), потому что это ваш ключевой фактор.

Меняйте, если необходимо

Конечно, нужно всегда следить за данными аналитики. Со временем какие-то версии Android подскочат в популярности, или же популярность внезапно наберет новое устройство. Опять-таки, подходите к этому с умом. Боритесь с соблазном добавлять все больше и больше версий и устройств под прикрытием "покрытия".

Выгода от каждого последующего теста склонна сокращаться. Подумайте о ценности еще одного теста – действительно ли он повышает вашу уверенность перед релизом?

Помните, что пример выше применим только к Android. Для iOS можно легко повторить всю процедуру. Держите в уме, что наше приложение работает только в портретной ориентации, и поэтому мы исключили из уравнения высоту экрана. Если ваше приложение  поддерживает все ориентации, то высота экрана может стать важным фактором в вашем случае.

В web-тестировании в игру вступает еще ряд факторов: различные операционные системы, браузеры, более широкий спектр разрешений. Ключевой момент – внимательно посмотреть на масштабы фрагментации и скомбинировать ее с данными аналитики, чтобы выявить ключевые факторы. К примеру, действительно ли последняя версия Chrome так сильно различается на Windows и macOs, или же ведет себя одинаково вне зависимости от операционной системы?

Неочевидные факторы

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

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

Во-первых, почему приложение случайным образом падает для ряда пользователей, хотя мы не выпускали никаких обновлений?

Во-вторых, наши мобильные приложения – это гибриды: 90% из них нативно построены под Android и iOS, а для оставшихся 10% мы используем WebView, перенаправляющий на наш мобильный сайт.

Завершение оформление заказа входит в эти 10%. Быстрая консультация с соответствующей командой подтвердила, что они тоже ничего не меняли. Откуда же взялись проблемы? Покопавшись в логах, мы выявили виновника: Android WebView.

Раньше, до Android 5, Android WebView был системным компонентом Android. Если Google хотел обновить или исправить WebView, нужно было выпускать обновление для Android целиком.

Из-за этого этот компонент отделили от Android и выпустили в PlayStore отдельно, чтобы обновлять его независимо от версии Android.

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

Автоматические обновления

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

Но у них есть и минусы. Они не всегда ведут себя так, как повело бы себя реальное устройство, и они не обновляются автоматически. Именно из-за отсутствия автоматического обновления мы и не нашли эту проблему раньше. Эмуляторы создаются с самой последней на этот момент версией Android WebView. Чтобы обновить эмулятор, нужно заводить SDK-инструменты Android Studio, что муторно, и поэтому мы нерегулярно этим занимаемся.

У реальных устройств нет такой проблемы – у них есть Google Play, и они отлично обновляют WebView этим способом. Это одна из вещей, которая не сразу приходит в голову, когда речь заходит о преимуществах тестирования на реальных устройствах. Ценить их начинаешь, когда сталкиваешься с проблемой.

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

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

С умом анализируйте вашу статистику использования, и не бойтесь ничего менять. Возможно, в какой-то момент вы что-то упустите (см. пример с Android WebView), и это нормально. Извлеките урок, адаптируйтесь, и подстройте вашу стратегию соответственно.

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

Поэтому нет верного ответа на вопрос "Как узнать, на каких устройствах или браузерах тестировать?". Ответ сильно зависит от контекста. Но я надеюсь, что мои советы помогут вам дать приемлемый ответ.

Обсудить в форуме