Высокоэффективное кросс-браузерное тестирование с минимальными усилиями

Кроссбраузерное тестирование занимает много времени и сил. Однако разработчики ленивы по своей природе: придерживаются принципа DRY, пишут сценарии для автоматизации вещей, которые в противном случае нам пришлось бы делать вручную, используя сторонние библиотеки; лень делает нас хорошими разработчиками .

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

Дальнейшее чтение на SmashingMag:

• Переход Ноя к юзабилити-тестированию мобильных устройств
• Основы автоматизации тестирования приложений, игр и мобильной сети
• Как создать свой собственный план тестирования внешнего интерфейса сайта
• Где находятся лучшие в мире лаборатории открытых устройств?

В течение следующих пятнадцати минут я надеюсь сэкономить вам часы потраченных впустую усилий, описав стратегию тестирования, которая не только менее трудоемка , но и более эффективна для выявления ошибок. Я хочу задокументировать реалистичную стратегию тестирования, более актуальную и ценную, чем просто «тестировать ВСЕ!», опираясь на свой опыт разработчика в тестировании в BBC Visual Journalism.

Контекст

Кроме того, стоит отметить, что в нашей команде мы делаем больше, чем просто ручное тестирование. Кросс-браузерное тестирование не заменяет модульные тесты (Jasmine/QUnit), функциональные тесты (Cucumber) и, при необходимости, автоматические визуальные регрессионные тесты (Wraith). Действительно, автоматические тесты в долгосрочной перспективе дешевле и необходимы, когда ваше приложение достигает определенного размера.

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

Какова ваша цель?

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

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

Первое, что я хочу, чтобы вы вынесли из этой статьи, это то, что эти две цели противоречат друг другу .

С одной стороны, я знаю, что могу проверить опыт почти 50% нашей британской аудитории, просто протестировав в Chrome (Desktop), Chrome (Android) и Safari (iOS 9). С другой стороны, если моя цель состоит в том, чтобы найти ошибки, я захочу запустить свое веб-приложение в наиболее проблемные браузеры, которые мы должны активно поддерживать: в нашем случае это IE8 и родной Android Browser 2.

Пользователи этих двух браузеров составляют сокращающийся процент нашей аудитории (в настоящее время около 1,5%), что делает тестирование в этих браузерах нерациональным использованием нашего времени, если наша цель — проверка работоспособности. Но это отличные браузеры для тестирования, если вы хотите увидеть, насколько искаженным может стать ваше хорошо спроектированное приложение, когда его бросают в малоизвестный движок рендеринга.

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

Что вы делаете, когда обнаруживаете ошибку на позднем этапе тестирования с длинным хвостом?

1. Не обращайте внимания на ошибку.
2. Исправьте ошибку и надейтесь, что вы ничего не сломали.
3. Исправьте ошибку и повторите тестирование во всех ранее проверенных браузерах.

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

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

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

Трехфазная атака

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

1. Разведка Отправьте своего шпиона во вражеский штаб, чтобы узнать, где могут скрываться плохие парни, сколько их там и общее состояние поля боя.
2. Рейд Отправьте свою первоклассную команду прямо в сердце врага, уничтожив большинство плохих парней в одной яростной внезапной атаке.
3. Очистка Отправьте местную милицию, чтобы убрать оставшихся злодеев и обезопасить территорию.

Вы можете привнести ту же военную стратегию и дисциплину в кроссбраузерное тестирование:

1. Разведка Проведите исследовательские тесты в популярном браузере на компьютере для разработки. Почувствуйте, где могут скрываться ошибки. Исправьте все обнаруженные ошибки.
2. Raid Тестирование вручную на небольшом количестве проблемных браузеров, вероятно, продемонстрирует наибольшее количество ошибок. Исправьте все обнаруженные ошибки.
3. Clearance Sanity проверяет, что самые популярные браузеры среди вашей аудитории очищены для получения ожидаемого опыта.

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

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

Подготовка: знай своего врага

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

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

Статистика использования браузера полезна только в том случае, если ее можно легко использовать: вы не хотите, чтобы вам представили длинный, пугающий список комбинаций браузер/ОС/устройство, которые нужно протестировать. Кроме того, тестирование всех возможных комбинаций — напрасная трата усилий. Мы можем использовать наши знания веб-разработчика для эвристической консолидации нашей статистики.

Упростите статистику использования вашего браузера

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

Нам также не особо важно, использует ли кто-то Firefox 40 или Firefox 39: различия между версиями незначительны, а обновление версий бесплатное и часто автоматическое. Чтобы упростить понимание статистики браузера, мы объединяем версии всех настольных браузеров, кроме IE. Мы знаем, что старые версии IE проблематичны и широко распространены, поэтому нам нужно отслеживать показатели их использования.

Аналогичный аргумент применим к браузерам портативных ОС. Нас не особенно волнует версия мобильного Chrome или Firefox, так как они регулярно и легко обновляются — поэтому мы объединяем версии. Но опять же, нам важны разные версии IE, поэтому мы регистрируем их версии отдельно.

Версия ОС устройства не имеет значения, если мы говорим об Android; важна версия используемого родного браузера Android, так как это общеизвестный проблемный браузер. С другой стороны, очень важно, какая версия iOS работает на устройстве, поскольку версии Safari неразрывно связаны с ОС. Кроме того, есть целый ряд нативных браузеров для других устройств: они составляют такой небольшой процент от нашей общей аудитории, что их номера версий тоже объединены.

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

После того, как мы использовали наши экспертные знания в предметной области для объединения соответствующей статистики, мы еще больше сузили список, удалив все браузеры, которые составляют менее 0,05% нашей аудитории (не стесняйтесь настраивать этот порог в соответствии с вашими собственными требованиями).

Настольные браузеры

Портативные браузеры

Браузеры в приложениях

Когда вы закончите, ваша электронная таблица должна выглядеть примерно так (пока игнорируйте столбец «Приоритет» — мы вернемся к этому позже):

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

Теперь вы готовы приступить к трехфазной атаке.

1. Разведка: поиск ошибок, не зависящих от браузера

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

Ошибки, не зависящие от браузера, — это ошибки реализации, которые не имеют ничего общего с браузером или оборудованием, используемым для доступа к вашему приложению. Например, предположим, что ваша веб-страница запущена, и вы начинаете получать неясные отчеты об ошибках от людей, жалующихся на то, что ваша страница выглядит хламом на их HTC One в ландшафтном режиме. Вы тратите много времени на определение того, какая версия браузера использовалась, используя режим USB-отладки Android и поиск помощи в StackOverflow, задаваясь вопросом, как вы собираетесь это исправить. Незаметно для вас, эта ошибка не имеет ничего общего с устройством: скорее, ваша страница выглядит некорректно при определенной ширине области просмотра, которая, как оказалось, является шириной экрана рассматриваемого устройства.

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

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

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

• Попробуйте изменить размер, чтобы увидеть скорость отклика. Была ли где-нибудь напуганная точка останова?
• Увеличение и уменьшение масштаба. Были ли смещены фоновые позиции спрайта вашего изображения?
• Посмотрите, как приложение ведет себя с отключенным JavaScript. Вы все еще получаете основной контент?
• Посмотрите, как выглядит приложение с отключенным CSS. Имеет ли смысл семантика разметки?
• Попробуйте отключить JavaScript и CSS. Получаете ли вы приемлемый опыт?
• Попробуйте взаимодействовать с приложением, используя только клавиатуру. Можно ли перемещаться и видеть весь контент?
• Попробуйте ограничить подключение и посмотрите, как быстро загружается приложение. Насколько велика загрузка страницы?

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

Быть ленивым. Исправьте ошибки, не зависящие от браузера. Затем мы можем перейти ко второй фазе атаки.

2. Raid: сначала протестируйте в браузерах с высоким риском

Когда мы исправляем ошибки, мы должны быть осторожны, чтобы наши исправления не привели к новым ошибкам. Настройка нашего CSS для исправления отступов в Safari может привести к поломке отступов в Firefox. Оптимизация этого фрагмента JavaScript для более плавной работы в Chrome может полностью сломать его в IE. Каждое изменение, которое мы делаем, сопряжено с риском.

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

Статистический анализ распространения ошибок

Рассмотрим следующую таблицу, где значок креста означает, что в браузере есть ошибка.

Допустим, мы должны протестировать наш контент в порядке возрастания риска: браузер с низким уровнем риска, браузер со средним уровнем риска, браузер с высоким уровнем риска. Если это поможет вам визуализировать это, эти браузеры могут сопоставляться с Google Chrome, IE 9 и IE 6 соответственно.

Сначала протестировав браузер с низким уровнем риска (Chrome), мы нашли и исправили ошибку № 2. Когда мы переходим на браузер Medium Risk, ошибка № 2 уже исправлена, но мы обнаруживаем новую ошибку: № 4. Мы меняем наш код, чтобы исправить ошибку, но как мы можем быть уверены, что не сломали что-то в браузере с низким уровнем риска? Мы не можем быть полностью уверены, поэтому нам нужно вернуться и снова протестировать в этом браузере, чтобы убедиться, что все работает так, как ожидалось.

Теперь переходим к браузеру High Risk и находим ошибки №1, №3 и №5, требующие значительной доработки для исправления. Как только они будут исправлены, что мы должны сделать? Вернитесь и снова протестируйте браузеры со средним и низким уровнем риска. Это дублирование усилий. Нам пришлось тестировать наши три браузера в общей сложности шесть раз.

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

Сразу же мы находили ошибки № 1, № 3, № 4 и № 5 в браузере High Risk. После исправления этих ошибок мы переходили прямо к браузеру Medium Risk и обнаруживали ошибку № 2. Как и прежде, это исправление могло косвенно что-то сломать, поэтому необходимо вернуться в браузер с высоким риском и повторно протестировать. Наконец, мы тестируем в браузере с низким уровнем риска и не обнаруживаем новых ошибок. В этом случае мы протестировали наши три браузера в общей сложности в четырех разных случаях, что значительно сократило время, необходимое для эффективного обнаружения и исправления того же количества ошибок и проверки поведения того же количества браузеров. .

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

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

Исправление ошибок в плохих браузерах делает ваш код более устойчивым в хороших браузерах.

Часто вы обнаружите, что ошибки, возникающие в этих проблемных браузерах, являются неожиданным результатом плохого кода с вашей стороны. Возможно, вы неуклюже стилизовали div, чтобы он выглядел как кнопка, или взломали setTimeout, прежде чем вызвать какое-то произвольное поведение; существуют лучшие решения для обеих этих проблем. Исправляя ошибки, которые являются симптомами плохого кода, вы, скорее всего, будете исправлять ошибки в других браузерах еще до того, как увидите их. Опять эффект тающего айсберга .

Проверяя поддержку функций, а не предполагая, что браузер что-то поддерживает, вы исправляете эту болезненную ошибку в IE8, но вы также делаете свой код более устойчивым к другим суровым условиям. Предоставляя это резервное изображение для Opera Mini, вы поощряете использование прогрессивного улучшения и, в качестве побочного продукта, улучшаете свой продукт даже для пользователей браузеров, которые срезают горчицу. Например, мобильное устройство может потерять 3G-соединение, если загружена только половина ресурсов вашего приложения: теперь пользователь получает значимый опыт, которого раньше не было.

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

Выявление проблемных браузеров

Так что же такое браузер с высоким риском? Ответ немного расплывчатый и зависит от функций браузера, которые использует ваше приложение. Если ваш JavaScript использует indexOf , он может не работать в IE 8. Если ваше приложение использует position: fixed , вам нужно проверить его в Safari на iOS 7.

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

Полезная вещь об ошибках, которые вы обнаруживаете в проблемных браузерах, заключается в том, что они часто распространяются. Если в IE9 есть ошибка, скорее всего, она существует и в IE8. Если что-то выглядит странно в Safari на iOS 7, это, вероятно, будет выглядеть еще более ярко в iOS 6. Заметили здесь закономерность? Старые браузеры, как правило, являются проблемными. Это должно помочь вам составить довольно хороший список проблемных браузеров.

При этом сделайте резервную копию со статистикой использования. Например, IE 6 — очень проблематичный браузер, но мы не утруждаем себя его тестированием, потому что его доля на рынке слишком мала. Время, затраченное на исправление специфичных для IE6 ошибок, не будет стоить усилий для небольшого числа пользователей, чей опыт будет улучшен.

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

Современные прокси-браузеры (такие как Opera Mini) также могут быть хорошим выбором для рейд-теста, если ваше приложение использует функции CSS3, такие как градиенты или радиус границы. Распространенной ошибкой является рендеринг белого текста на неподдерживаемом градиенте, что приводит к неразборчивому тексту «белое на белом».

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

Разнообразьте свои проблемные браузеры

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

Может показаться заманчивым сгруппировать связанные браузеры вместе, потому что это ощутимая скидка на затраты усилий. Если у вас уже открыт VirtualBox для тестирования IE8, сейчас самое время протестировать IE9, IE10 и IE11. Однако, если вы находитесь на ранних этапах тестирования своего веб-приложения, вам следует бороться с этим искушением и вместо этого выбрать три или четыре комбинации браузера и оборудования, которые заметно отличаются друг от друга, чтобы получить как можно больше охвата всего ошибка пространство, как вы можете.

Хотя они могут варьироваться от проекта к проекту, вот мои текущие проблемные браузеры:

• IE 8 на виртуальной машине Windows XP;
• родной Android Browser 2 на Android-планшете среднего уровня;
• Safari на iPhone 4 под управлением iOS 6;
• Opera mini (на самом деле стоит тестировать только контент, который должен работать без JavaScript, например datapics).

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

3. Клиренс: проверка работоспособности

Вы протестировали свое приложение в самых суровых браузерах, которые вам приходилось поддерживать, и, надеюсь, обнаружили большинство ошибок. Но ваше приложение еще не полностью избавлено от ошибок. Меня постоянно удивляет, насколько разные даже последние версии Chrome и Firefox отображают один и тот же контент. Вам все еще нужно сделать еще несколько тестов.

Это старое правило 80:20. Образно говоря, вы исправили 80% ошибок после тестирования 20% браузеров. Теперь вам нужно проверить опыт 80% вашей аудитории, протестировав другие 20% браузеров.

Приоритет браузеров

Простой и очевидный подход теперь состоит в том, чтобы вернуться к «традиционному» кросс-браузерному тестированию, рассматривая каждый браузер в порядке убывания доли рынка. Если настольный компьютер Chrome занимает наибольшую часть доли браузера вашей аудитории, за ним следует Safari на iOS 8, а затем IE11, то имеет смысл проводить тестирование именно в таком порядке, верно?

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

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

Вот наше дерево решений:

Мы разработали наше дерево решений таким образом, чтобы браузеры P1 покрывали примерно 70% нашей аудитории. Браузеры P1 и P2 в совокупности покрывают примерно 90% нашей аудитории. Наконец, браузеры P1, P2 и P3 дают нам практически полный охват аудитории. Мы стремимся протестировать во всех браузерах P1, затем P2, затем P3, в порядке убывания доли рынка.

Как видно из таблицы ранее в этой статье, у нас всего несколько браузеров P1. Тот факт, что мы можем так быстро проверить опыт более 70% нашей аудитории, означает, что у нас мало оправданий для того, чтобы не проводить повторное тестирование в этих браузерах, если кодовая база изменится. По мере того, как мы переходим к браузерам P2 и P3, нам приходится прилагать все больше усилий для проверки опыта постоянно уменьшающейся аудитории, поэтому мы должны установить более реалистичные идеалы тестирования для браузеров с более низким приоритетом. В качестве ориентира:

• Р1 . Мы должны проверить работоспособность этих браузеров, прежде чем подписывать приложение. Если мы внесем небольшие изменения в наш код, нам следует снова проверить работоспособность этих браузеров.
• П2 . Мы должны проверить работоспособность этих браузеров, прежде чем подписывать приложение. Если мы внесем большие изменения в наш код, нам следует снова проверить работоспособность этих браузеров.
• Р3 . Мы должны проверить работоспособность этих браузеров один раз, но только если у нас есть время.

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

Резюме: трехфазная атака

После того, как вы приложили усилия, чтобы узнать своего врага ( упростив статистику аудитории и сгруппировав браузеры по приоритетам ), вы сможете атаковать в три этапа:

1. Разведка : исследовательское тестирование в вашем любимом браузере, чтобы найти ошибки , не зависящие от браузера.
2. Raid : тестирование наиболее проблемных поддерживаемых браузеров на различном оборудовании для выявления большинства ошибок .
3. Разрешение : проверка работы вашего приложения в наиболее широко используемых и стратегически важных браузерах, чтобы сказать с количественной уверенностью, что ваше приложение работает .