В сегодняшнем большом интервью с Леонидом Колобовым, старшим тестировщиком SaveLink, он поделится своим опытом и советами по тестированию адаптивных версий сайтов, а также объяснит, какие «подводные камни» чаще всего встречаются и как их избежать.
Редакция: Леонид, здравствуйте! Продолжим обсуждать тестирование адаптивов. В прошлый раз мы уже говорили о важности мобильной и десктопной версий, затрагивали планшеты и кроссбраузерность. Расскажите, пожалуйста, с чего вообще начинается процесс тестирования адаптивной версии?
Леонид Колобов, старший тестировщик Savelink: Здравствуйте! Когда мы начинаем тестировать адаптивы, то прежде всего смотрим, какие устройства и сценарии использования самые критичные для бизнеса. Здесь важна аналитика: на какие устройства или платформы приходится основной трафик и какой функционал там наиболее востребован. На этом этапе также согласовываем набор «целевых устройств» и браузеров, чтобы не ушли в бесконечное тестирование всего и вся. Как только есть четкий список приоритетов, мы готовим тестовые сценарии — что пользователь будет делать на сайте, где нужно проверить логику, верстку, навигацию, работу форм и так далее.
Редакция: А какие инструменты чаще всего используются для проверки адаптивности?
Леонид: Инструментов довольно много. Например, DevTools в Chrome или Firefox позволяет быстро переключаться между размерами экранов, смотреть, как ломается верстка или как «переезжают» элементы. Но это лишь часть истории, так как эмуляторы не дают полного представления о пользовательском поведении, скорости сети и реальных вводах. Поэтому помимо эмуляторов мы стараемся привлекать реальные устройства или хотя бы сервисы типа BrowserStack, где можно тестировать на «живых» мобильных ОС и разных версиях браузеров. Также используем инструменты автоматизации, например, Selenium или Cypress. Но тут важно понимать, что для адаптивных тестов автоматизация покрывает не все. Визуальные баги и «поехавшая» верстка лучше всего обнаруживаются глазами, пусть и по плану тест-кейсов.
Редакция: Понял. Скажите, а какие самые распространенные ошибки вы замечаете на проектах, когда речь заходит об адаптивах?
Леонид: Во-первых, это несогласованность макетов с реальным контентом. Бывает, дизайнер рисует красивую концепцию, которая отлично смотрится с демонстрационными картинками и короткими текстами, а реальность это длинные описания, изображения разного формата. В итоге в верстке все «плывет», меню налезает на логотип, кнопки уходят в «подвал».
Во-вторых, игнорирование «переходных» состояний: когда, например, пользователь разворачивает экран не до конца или меняет ориентацию телефона с портретной на ландшафтную. В этих случаях нужно понимать, как будет вести себя дизайн.
В-третьих, кроссбраузерные проблемы. То, что выглядит здорово в Chrome, вдруг оказывается нечитаемым в Safari. Или шрифты не подгружаются, или скрипты падают. Выявить это можно только тестированием в реальных условиях.
Редакция: Вопрос о бюджете. Часто у заказчика нет желания вкладываться во все возможные устройства и сценарии. Как убедить руководство, что тестирование адаптивов на разных размерах экрана — это не прихоть, а необходимость?
Леонид: Тут работают «боли» и понятная бизнес-логика. Речь о потере клиентов и снижении конверсии. Когда пользователи сталкиваются с неудобным сайтом, они уходят. Это прямые финансовые потери. Плюс репутационные риски. Если пользователь разочаровался в вашем продукте один раз, он не всегда даст второй шанс. Я обычно показываю статистику: «Вот, мы недотестировали под планшеты, и люди массово жалуются, что формы отображаются криво. В итоге падение записей на услуги или заказов — вот цифры». Когда руководство видит реальное влияние на продажи, вопрос самоокупаемости тестирования отпадает.
Редакция: А как в Savelink выстраиваете сам процесс? Используете ли вы Agile-подходы или Waterfall? Как это отражается на тестировании?
Леонид: Мы довольно гибкие. Agile хорош для быстрой обратной связи: если команда разработки выпускает инкрементальные обновления, то мы можем на ранних этапах проверять адаптивы и выявлять мелкие баги до того, как они вырастут в огромные проблемы. А вот в Waterfall часто бывает так, что к тестировщикам уже «приносится» законченный дизайн и функционал. И если там системные ошибки, правки будут сложнее и дольше. Но все зависит от заказчика. Мы в любом случае стараемся настаивать, чтобы нас подключали на ранних стадиях проектирования: тогда итоговое качество выше, а расходы на доработки ниже.
Редакция: Вы упомянули, что планшетная версия по аналитике часто не так востребована. Но ведь бывает ситуация, когда пользователь просто меняет размер окна браузера на компьютере. Как вы учитываете подобные кейсы?
Леонид: Именно так: «планшетная» версия это фактически состояние верстки при определенной ширине экрана. Действительно, если пользователь уменьшает окно, то он может «провалиться» в медиазапросы, которые дизайнеры заложили под планшет. Поэтому мы всегда делаем тесты на разных брейкпоинтах. Смотрим, что будет, когда окно браузера плавно сужается. Бывает, что при 1024 px все красиво, а при 990 px уже каша. Тогда указываем на проблему в стиле или медиазапросах.
Редакция: Из часто забываемых моментов вы называли работу с видео, которое тянется с YouTube и может не воспроизводиться. Расскажите, какие еще «мелочи» часто всплывают?
Леонид: Часто забывают проверить адаптивность всплывающих окон (попапов) и модальных форм. Например, если на мобайле пользователь жмет кнопку «Авторизация», открывается попап, а он не умещается, уезжает за границы экрана, и человек не может закрыть окно или ввести данные. Еще бывает, что блоки по ссылкам «Больше деталей» или «Читать полностью» не тестируют на всех устройствах. Итог: на десктопе все отлично, а на смартфоне контент не раскрывается или ломает верстку.
Также часто забывают про тестирование разных типов клавиатур и методов ввода. На iOS и Android можно подключить разные виртуальные клавиатуры или голосовой ввод, и иногда поля формы ведут себя некорректно — особенно если форма сделана кастомными скриптами.
Редакция: Что бы вы посоветовали начинающим тестировщикам, которые впервые сталкиваются с адаптивным тестированием?
Леонид: Во-первых, изучать гайды по responsive design и CSS-медиазапросам значит понимать, как верстка «подстраивается» под разные экраны. Во-вторых, не лениться проверять реальное поведение сайта: эмуляторы это хорошо, но живой смартфон, планшет или хотя бы сервис на реальных устройствах даст более точную картину. В-третьих, следить за аналитикой. Если видите, что у бизнеса много трафика с определенного устройства (или экзотического браузера), то уделите ему особое внимание. И, конечно, нужно учиться четко описывать найденные баги и их шаги воспроизведения, чтобы разработчикам не приходилось ломать голову, в чем именно проблема.
Редакция: Леонид, спасибо за такой подробный разговор! Теперь у наших читателей наверняка будет более полная картина того, как планировать и проводить тестирование адаптивов. Есть ли что-то, о чем вы хотите напоследок напомнить?
Леонид: Наверное, подчеркну, что адаптивное тестирование это не разовая акция, а постоянная задача. Сайт живет, контент меняется, появляются новые устройства и браузеры, старые версии перестают поддерживаться. Лучший подход — держать руку на пульсе, анализировать метрики и поддерживать релизы актуальными. Тогда пользователи будут довольны, а бизнес в выигрыше.
Редакция: Спасибо, Леонид! Было очень интересно и полезно. До новых встреч!
Леонид: Всегда пожалуйста! Успехов в тестировании!