Смотрите на Кинопоиске с подпиской 
Условия: clck.ru/FMQND Условия: clck.ru/FMQND. 18+
Личный опыт
Lena Nexman

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

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

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

Без тестирования - все плохо

А надо ли?

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

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

Тестирование для не тестировщиков

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

  • Соответствие результата ожиданиям клиента;
  • Кроссбраузерность;
  • Кроссплатформенность;
  • Скорость загрузки;
  • Анимации и изображения;
  • “Тыкательность”;
  • Чтобы было понятно, где какие элементы интерфейса и за что они отвечают.
"Модная" анимация старого сайта http://ofisnaden.ru/. P.S. теперь на первом экране новые баги :)

Чек-лист как основа всего

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

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

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

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

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

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

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

Соответствие ожиданиям клиента

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

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

Кроссбраузерность

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

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

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

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

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

После успешных тестов все равно воспользуйтесь рабочими браузерами на вашем компьютере и посмотрите, как ведет себя сайт. Особенно это касается “любимцев” публики: Яндекс. Браузер и 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 — вы знаете где меня найти.

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

0
18 комментариев
Написать комментарий...
Евгений Широков

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

Ответить
Развернуть ветку
Lena Nexman
Автор

Ценный комментарий, но не все умеют ими пользоваться, а уж pagespeed/webpagetest сложно заменить встроенными инструментами :)

Ответить
Развернуть ветку
Ekaterina Bogatina

Было полезно, спасибо

Ответить
Развернуть ветку
Blinov

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

Ответить
Развернуть ветку
Lena Nexman
Автор

вот вам еще, в тему про тестирование сайтов :)

sup: опиши, плз, твою последовательность действий, предшествующую появлению ошибки
us: Вскипятил чайник, положил в кружку пакетик, залил кипяточком. Подхожу к компу — а там эта хрень...

Ответить
Развернуть ветку
Blinov

Благодарю )

Ответить
Развернуть ветку
Anton

Елена, давно читаю ваши статьи! Очень нравится, что вы все проблемы описываете именно в точку. Как мне передать разработчику то, что найду, чтобы не возникло недопонимания? В каком формате это лучше делать?

Ответить
Развернуть ветку
Lena Nexman
Автор

Google Docs с несколькими колонками: устройство, браузер, страница, описание ошибки, скриншот, ответ разработчика, все :)

Ответить
Развернуть ветку
Alex Gurulli

Решил тыкнуть в комментарий)

"С вами была Лена, UX/UI/Motion-дизайнер, которая всегда тестирует результат верстки даже тогда, когда на проекте есть тестировщики."
Аа, так вы "Аккуратистка".
А «тыкательность» = проверка работоспособности активных элементов на сайте, это для прикола? Мя сразу оно улыбнуло ;)

"Чтобы было понятно, где какие элементы интерфейса и за что они отвечают = удобство использования интерфейса (Юзабилити). И с «Юзабилити» ссылка на сообщество). SEO, Лена, SEO!

Эх, мягенько сидится на комментаторском диване пользователя VC))

Ответить
Развернуть ветку
Lena Nexman
Автор

Не то, чтобы аккуратистка, просто иногда больно видеть результат внедрения дизайна индусскими руками и хочется этого избежать ;)
Про тыкательность - конечно для прикола, можно начать сыпать терминами, но зачем, просто возьми и ткни в сайт, авось что случится :)
А про SEO надо почаще вспоминать, конечно, это да...

Ответить
Развернуть ветку
Андрей Чередниченко

Статья понравилась, самостоятельно тестирование оказалось объемнее, чем я думал, хах

Отдельное спасибо за чек-лист)

Ответить
Развернуть ветку
Lena Nexman
Автор

Можно начать с пары имеющихся браузеров + pagespeed, для начала этого хватит :)

Ответить
Развернуть ветку
Абырка

Это все хорошо, конечно, но где ссылка на инстаграм и фото в купальниках?

Ответить
Развернуть ветку
Lena Nexman
Автор

Много работы, этим летом еще полноценно не была на море, так что сори, позже....

Ответить
Развернуть ветку
Прокрастинация и отвага

даже не думал что анимация-так просто

Ответить
Развернуть ветку
Lena Nexman
Автор

Боль будет в тестировании анимации :)

Ответить
Развернуть ветку
clingon

Добавлю в копилку сервисов: Applitools https://applitools.com — для визуального тестирования регресса в верстке.

Ответить
Развернуть ветку
Lena Nexman
Автор

Поддерживаю, спасибо

Ответить
Развернуть ветку
Читать все 18 комментариев
null