Как протестировать сайт/анимацию самостоятельно?

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

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

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

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

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

• Соответствие результата ожиданиям клиента;
• Кроссбраузерность;
• Кроссплатформенность;
• Скорость загрузки;
• Анимации и изображения;
• “Тыкательность”;
• Чтобы было понятно, где какие элементы интерфейса и за что они отвечают.

Какое ТЗ, такой результат = какой чек-лист, такой результат тестирования. Чек-лист в самом простом понимании — список идей для тестирования.

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

Если вы хотите, чтобы чек-лист был действительно вам полезен, он должен быть:

• Логичным. Он должен отражать определенные цели и пути их достижения. Не превращайте его в “свалку” идей.
• Последовательным и структурированным. Тут все просто: идеальный чеклист это вид многоуровневого списка от простых тестов к сложным. Логика перехода от одного теста к другому должна быть понятна не только вам.
• Полным и непереполненным. Не перегружайте чек-лист ненужными подробностями. Пункты должны быть краткими и по делу. Мимоходом, не забудьте сокращения, которые вы придумали.

Избегайте типовых ошибок:

• Пункты зависят друг от друга. “Повторить то же, что и в пункте 5, только нажать на левую кнопку”. Лучше лишний раз повторить описание, потому что пункт 5 могут удалить, изменить или сдвинуть. А еще можно случайно перепутать цифры, повторить пункт 6 и не получить ожидаемый результат.
• Нечеткая формулировка шагов. “Проверить вход в личный кабинет” — что означает эта фраза? Проверить кликабельность кнопки входа, корректность отображения данных в полях, интерфейс личного кабинета, время загрузки страницы, анимацию загрузки — вариантов может быть много. Лучше вообще не использовать слово “Проверить”. Замените его на конкретный результат, который вы хотите увидеть: “Открытие окна с полями для заполнения при нажатии на кнопку “Вход”. Ваш чек-лист может достаться другому специалисту и он должен четко понимать, что делать.
• Нечеткая формулировка ожидаемого результата. Если вы проверяете кнопку входа, ожидаемый результат “Кнопка нажалась” — это плохо, а “При наведении на кнопку корректно сработала анимация, при нажатии открылось поле для заполнения, как было задумано в ТЗ” — хорошо.
• Описание элементов интерфейса “от себя”. “Нажать на крестик”, “Синяя кнопка должна стать больше”, “Появится всплывашка” — избегайте этого.
• Сопровождайте найденные ошибки скриншотами. Без этого — никто кроме вас не разберется, да и вы через неделю-другую забудете что имели ввиду.

Если вам не от чего оттолкнуться — вот пример чеклиста.

Да, не забудьте проверить бриф и ТЗ. Возможно, вы приготовили глазунью, а изначальной задачей был омлет.

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

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

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

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

Небольшой список от меня:

• Browsershots;
• BitBar;
• Litmus;
• Browsera;
• Sauce Lab.

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

После успешных тестов все равно воспользуйтесь рабочими браузерами на вашем компьютере и посмотрите, как ведет себя сайт. Особенно это касается “любимцев” публики: Яндекс. Браузер и Microsoft Edge. Программы облегчили нашу жизнь, но человека все равно не заменить.

Небольшое уточнение: вышеприведенные сервисы не гарантируют 100% совпадение с реальным поведением браузера.

Проверяем адаптивность сайта, удобство просмотра контента и скорость загрузки сайта. Сайт должен корректно работать на:

• ПК с Windows/macOS с разрешениями дисплеев от 1366x768 до 4k;
• Ноутбуках — те же разрешения что и выше;
• Планшетах — от 768px;
• Умных телевизорах — тут встречается даже 8k;
• Айфонах — хотя бы от 7го;
• Смартфонах на Android;
• Китайских смартфонах.

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

Что нужно сделать:

Шаг 1. Купить пару дешевых телефонов и дешевый ноутбук.

Шаг 2. Проверять работу сайта на них. Что проверяем:

• Сайт открывается и загружается со скоростью, не превышающую скорость загрузки в ТЗ;
• Весь контент на сайте можно увидеть и прочесть;
• Анимации не зависают;
• Кнопки нажимаются;
• Поля для заполнения удобно заполнять.

Шаг 3. Проверить сайт на своих устройствах.

Шаг 4. Скинуть сайт коллегам, чтобы они его проверили на своих гаджетах. Всем необязательно, можно взять 3-4 человека с разными устройствами. Попросить выполнить целевые действия.

[:::]

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

В отличие от эмуляторов, на реальных девайсах можно:

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

Но если сильно хочется, можете воспользоваться следующими сервисами:

• Adaptivator — бесплатный, можно моделировать поведение сайта на телефоне / планшете различных моделей;
• Screenfly — бесплатный, более 30 моделей смартфонов, планшетов, ПК и ТВ;
• Browserling — платный, позволяет проверить не только кроссплатформенность, но и кроссбраузерность.

Идем в сервис для проверки скорости загрузки сайта Pagespeed от Google. Им я пользуюсь всегда. Что он показывает:

• Скорость загрузки основного контента (LCP) — как быстро загружается самый большой текстовый блок или изображение в видимой для пользователя области.
• Время ожидания до первого взаимодействия с контентом (FID) — время от момента, когда пользователь нажал на ссылку до момента, когда браузер готов реагировать на взаимодействие с сайтом.
• Совокупное смещение макета (CLS) — совокупное время смещения всех элементов макета. Показывает, как много времени нужно, чтобы все элементы макета сместились в свое итоговое положение.
• Первая отрисовка контента (FCP) — время от начала загрузки страницы до появления любого видимого контента на экране. Это может быть текст, изображение или любые другие небелые элементы.
• Скорость взаимодействия с контентом (INP) — самая долгая реакция на взаимодействие с контентом. Сайт нажимает на все, что нажимается и то, что отвечает дольше всего, идет в метрику.
• Время отклика сервера (TTFB) — думаю, тут понятно.

После корректировки по Pagespeed — проверяем еще раз в сервисе Webpagetest, не забывая выставить ближайший сервер, корректируем.

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

Если вы хотите протестировать, нравятся ли вашим пользователям картинки и анимации, запускайте A/B тесты с разными анимациями и картинками или вообще без них. Где ниже показатель отказов — то и выбирайте.

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

• Для проектов, рассчитанных на широкие массы — не используйте сложную анимацию, ограничьтесь интерфейсной (ховеры etc);
• Попробуйте не использовать JavaScript для анимаций, если можно использовать CSS или SVG;
• Не забывайте про правильные свойства. Если нужно переместить объект, то стоит использовать transform: translate, а не абсолютное позиционирование и координаты left и right;
• Изучите видео по оптимизации анимаций.

Небольшая табличка-помощник по сжатию:

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

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

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

Не забывайте, что многие люди не любит рекламу и использует блокировщики по типу AdGuard и AdBlock. При не самом удачном коде — они могут серьезно подпортить пользовательский опыт. Установите себе самые популярные, включайте их по очереди в разных браузерах и смотрите, чтобы сайт не разъехался.

Это ярче всего проиллюстрирует анекдот:

Заходит однажды тестировщик в бар. Забегает в бар. Пролезает в бар. Танцуя, проникает в бар. Крадется в бар. Врывается в бар. Прыгает в бар и заказывает:

• кружку пива,
• 2 кружки пива,
• 0 кружек пива,
• 999999999 кружек пива,
• ящерицу в стакане,
• –1 кружку пива,
• qwertyuip кружек пива.

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

Какова мораль?

Вам и не надо. Ваша задача — найти максимум важных ошибок за имеющееся время.

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

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

А вы проверяете свой сайт? Если да, то как?

С вами была Лена, UX/UI/Motion-дизайнер, которая всегда тестирует результат верстки даже тогда, когда на проекте есть тестировщики.

• Подписывайтесь, вступайте в сообщество Юзабилити, в планах — много интересных материалов.
• Присоединяйтесь к авторам сообщества. За хорошие статьи по теме Юзабилити я предлагаю 4000-10000 рублей за материал. Свяжитесь со мной, предложите темы, чтобы начать зарабатывать.
• Всегда рада нетворкингу с UI/Motion-дизайнерами и Front-end — вы знаете где меня найти.

А какие самые дикие баги на сайте вы находили?