Home

Оригинал статьи: https://dojo.ministryoftesting.com/lessons/getting-started-with-cross-browser-testing

Автор: Алекс Лэнгшалл (Alex Langshall)

Перевод: Ольга Алифанова.

Вы, как тестировщик, получили на тестирование юзер-стори, и ответственный за нее разработчик попросил вас провести кросс-браузерное тестирование. Что это значит? Зачем тестировать юзер-стори в разных браузерах? Какие браузеры выбрать для тестирования? На что обращать внимание в процессе?

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

Определение кросс-браузерного тестирования

Кросс-браузерное тестирование – это тестирование фичи в различных релевантных приложению браузерах. Это важная часть тестирования: несмотря на существование веб-стандартов, разные браузеры внедряют их различным образом. На глубоком уровне разные элементы страницы ведут себя по-разному в разных браузерах. Поведение фичи в Safari, к примеру, может сильно отличаться от ее работы в Chrome.

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

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

Выбор браузеров

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

Если у вашего продукта или сайта есть явно задекларированный перечень поддерживаемых браузеров, то именно в них вы и будете регулярно тестировать. Если вы поддерживаете только IE11, Firefox, Safari и Chrome, вы можете ограничить ваше тестирование этой четверкой. Если внятно сформулированной браузерной политики не существует, получите доступ к статистике использования и возьмите для тестирования пять браузеров-лидеров – это неплохой способ получить вполне приличное покрытие кросс-браузерного тестирования приложения.

Если у вас есть доступ к аналитике через Google Analytics, или что-нибудь вроде Kissmetrics, вы можете определить, какие конкретно браузеры используются посетителями вашего сервиса. Это, конечно, поможет вам спланировать выборку браузеров, но это ни в коем случае не серебряная пуля.

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

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

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

Chrome и Firefox относятся к так называемым "вечнозеленым" браузерам – они автоматически обновляются, как только новая версия становится доступной. Обновляются они быстро и часто – примерно раз в месяц. Safari и IE11 обновляются значительно реже, и их обновления завязаны на обновления операционных систем.

За изменениями браузеров можно следить, сравнивая бета-версии этих браузеров, или текущую версию с предыдущей. Chrome Canary и Firefox Developer Version дают возможность посмотреть на новую версию заранее, как и Safari Technology Preview.

Немного об оборудовании

Если у вас есть ограничения по оборудованию, а доступ есть только к одной машине, то, возможно, наилучшим вариантом будет выбрать Mac для тестирования. Это позволит вам установить виртуальную машину с Windows и IE для тестирования. К сожалению, легально обзавестись виртуальной машиной с Mac Os куда тяжелее, если вы тестируете под Windows.

Учитывайте так же, какое оборудование вам понадобится для тестирования в браузерах не для ПК. Safari – стандартный браузер для устройств под iOS. Для Android это Chrome, хотя на обеих платформах существуют и альтернативные браузеры, а "родные" браузеры зависят от типа телефона. К примеру, у Samsung есть собственный предустановленный браузер. Инвестируя в мобильное тестирование, имейте под рукой минимальное и максимальное разрешение экрана мобильного устройства. Если приложение может использоваться в других типах не-десктопных браузеров, то, возможно, хорошей идеей будет приобретение таких устройств, как Xbox, PlayStation, AppleTV или даже Wii U – у всех них есть специфические браузеры для консольной платформы.

Что же именно тестировать в разных браузерах?

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

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

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

С чего начать?

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

• Элементы интерфейса. Начните с них.

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

- Шрифты должны выглядеть единообразно.

• Размер окна. Уменьшите размер окна до минимально возможного (в рамках разумного) и убедитесь, что все элементы можно использовать вне зависимости от размера экрана. При реактивном дизайне элементы должны каким-либо образом схлопываться, когда размер экрана уменьшается. Поищите места, где этого схлопывания не произошло, но элементы дизайна пропали.
• DPI. Убедитесь, что все элементы верно отображаются и на экранах с высоким DPI, и на экранах с низким.
• Курсоры. Если вид курсора должен меняться (на руку, прицел, и т. д.), убедитесь, что изменения происходят верно и вовремя.
• Скролл. Можете ли вы проскроллить экран, верно ли это происходит? Тач-пад, тач-кнопка, указатель мыши, колесо мыши, кнопки вверх/вниз – все, что должно заставлять приложение скроллиться, должно вызывать это действие. Не забудьте проверить и вертикальный, и горизонтальный скролл там, где применимы оба.
• Масштабирование. Изменится ли что-то, если вы увеличите масштаб отображения страницы в браузере? Если используется "отзывчивый" дизайн, элементы должны изменить свои размеры.

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

Советы и рекомендации

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

Версии браузеров:

• В Chrome и Firefox по URL “about:” можно найти информацию о версии и билде браузера. В IE и Edge эта информация находится в пункте меню "О приложении" (последний пункт правого выпадающего меню адресной строки). Для Safari эта информация сидит в меню "О Safari", доступном через меню Apple.

Доступ к инструментам разработчика

• В Chrome, Firefox, IE11 и Edge нажмите клавишу F12, чтобы открыть инструменты разработчика. Если вы разрешили использование этих инструментов в Safari, то они откроются или через Command-Option-C, или через Command-Option-I.
• Некоторые инструменты разработчика позволяют эмулировать мобильные браузеры или представляться приложению как другой браузер. В Chrome меню устройства (Control или Command-Chift-M) дает возможность изменить размер устройства. В IE11 есть выпадающее меню, позволяющее изменить версию IE.

Управление зумом:

• При помощи мыши: не снимая фокус с окна браузера, зажмите Control (или кнопку Command для Mac) и, используя колесо скролла, быстро меняйте масштаб браузера, чтобы найти ошибки разметки страницы. Это работает и с трекпадом при использовании жестов скролла. На трекпадах Mac браузер скроллится при зажатом Command и использовании скролла при помощи двух пальцев.
• При помощи инструментов браузера: Control (или Command) и кнопки + и – позволяют менять масштаб браузера поуровнево. Вернуться к масштабу по умолчанию можно при помощи Control (Command) и кнопки 0.

Очистка кэша и временных файлов браузеров:

• Chrome, Firefox, IE11 и Edge очищают кэш и временные файлы по горячим клавишам Control-Shift-Delete (Command-Shift-Delete для Mac). В Chrome и Firefox это действие убивает кэш и временные файлы только для текущего профиля: другие профили затронуты не будут. IE11 и Edge нужно перезапустить после подобной очистки. В Safari, в меню Safari, есть пункт "Очистить историю", выполняющий аналогичное действие. Ему можно назначить горячую клавишу через панель "Клавиатура" в системных настройках.

Изолированные профили Chrome и Firefox:

• Firefox и Chrome дают возможность использования разных профилей, открывающих отдельные, полностью изолированные друг от друга сессии браузера. В Chrome для этого нужно нажать на название профиля в верхнем правом углу. Firefox нужно предварительно настроить.
• Режим "инкогнито" доступен в Chrome, Firefox, Edge, Safari, и Internet Explorer. Он дает возможность открыть одноразовую сессию браузера, которая теряет свои настройки и временные файлы после закрытия. Такой режим идеален для тестирования ситуаций, для которых хранение информации не так уж важно. Имейте в виду, что все инкогнито-окна одного браузера делят между собой одну и ту же сессию. К примеру, временные файлы делятся между активными окнами браузера, открытыми в режиме инкогнито.

Что дальше?

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

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

Использование кросс-браузерных инструментов.

Инструменты вполне могут быть учтены при планировании кросс-браузерного тестирования. К примеру, BrowseEmAll – это инструмент, позволяющий посмотреть на разные графические движки в одном и том же окне. Пользователи, конечно, не будут пользоваться этим браузером, но этот инструмент идеален для быстрой проверки отображения общих элементов, верстки, и отсутствующего содержания.

Browserstack – это облачный инструмент, запускающий различные браузеры внутри одной браузерной сессии. Их плагин позволяет получить доступ к сайтам внутри вашей корпоративной сети или файерволла. Он превосходно подходит для тестирования специфических версий браузера, которые могут быть недоступны на тестовой машине.браузер запускается в виртуальном режиме. Если продукт или приложение опирается на специфический движок (например, WebGL), такая виртуализация не даст вам представления о поведении системы в реальном браузере.

Для прогона автотестов в разных браузерах существует масса инструментов. К примеру, Selenium Grid позволяет хранить браузерные сессии и запускать в них автотесты. Если поддержка серверов для Selenium Grid финансово невыгодна, можно обратиться к Sauce Labs – она предоставляет облачное решение для хорошего тестового покрытия различных браузеров.

Справочные материалы:

1. Surviving CRM – кросс-браузерная матрица
2. Desktop Browser Market Share - Netmarketshare
3. What are Browser Developer Tools? - Mozilla Developer Network
4. Firefox and other Browser Keyboard Shortcuts - F. David McRitchie
5. RapidRelease/Calendar - MozillaWiki

Chromium Development Calendar and Release Info

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