Как протестировать сайт/анимацию самостоятельно?
Когда вы создали “сайт мечты” для клиента, протестируйте его, прежде чем бежать к заказчику с праздничным тортом.
Понимаю, может быть неприятно несколько раз просматривать готовую работу, прежде чем отдавать ее на оценку, ведь можно заметить в ней недочеты и сильно расстроиться. Но если этого не сделать, вы рискуете споткнуться и запустить торт в лицо клиенту, чего уже не хочет он.
А надо ли?
Вопрос философский. В своих статьях я говорю о том, что каждый этап создания сайта реализуется конкретным специалистом. И для такой задачи специальный человек тоже есть — имя ему тестировщик (QA).
Однако, если бюджет небольшой или вы хотите сберечь время тестировщика на фиксацию поверхностных ошибок, расскажу вам, как провести самостоятельный тест сайта и анимаций.
Тестирование для не тестировщиков
Не стоит вдаваться в технические сложности работы профессиональных тестировщиков. Они учились не один месяц, их работа посвящена только этому, да и у вас, уверена, полно других дел. Возьмитесь за то, что проверить проще всего:
- Соответствие результата ожиданиям клиента;
- Кроссбраузерность;
- Кроссплатформенность;
- Скорость загрузки;
- Анимации и изображения;
- “Тыкательность”;
- Чтобы было понятно, где какие элементы интерфейса и за что они отвечают.
Чек-лист как основа всего
Какое ТЗ, такой результат = какой чек-лист, такой результат тестирования. Чек-лист в самом простом понимании — список идей для тестирования.
Поскольку внутри компании проекты более-менее однотипны, один хорошо продуманный качественно оформленный чек-лист может использоваться повторно с небольшими корректировками. Это сэкономит ваши силы и время.
Если вы хотите, чтобы чек-лист был действительно вам полезен, он должен быть:
- Логичным. Он должен отражать определенные цели и пути их достижения. Не превращайте его в “свалку” идей.
- Последовательным и структурированным. Тут все просто: идеальный чеклист это вид многоуровневого списка от простых тестов к сложным. Логика перехода от одного теста к другому должна быть понятна не только вам.
- Полным и непереполненным. Не перегружайте чек-лист ненужными подробностями. Пункты должны быть краткими и по делу. Мимоходом, не забудьте сокращения, которые вы придумали.
Избегайте типовых ошибок:
- Пункты зависят друг от друга. “Повторить то же, что и в пункте 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 — вы знаете где меня найти.
А какие самые дикие баги на сайте вы находили?
"За ним заходит обычный посетитель, спрашивает, где туалет и бар взрывается" - это шедевр )
вот вам еще, в тему про тестирование сайтов :)
sup: опиши, плз, твою последовательность действий, предшествующую появлению ошибки
us: Вскипятил чайник, положил в кружку пакетик, залил кипяточком. Подхожу к компу — а там эта хрень...
Немного подушню. Список сервисов запросто заменят инструменты разработчика.
Почти все перечисленные браузеры на движке хрома, и будут отображаться с минимальными расхождениями. Нельзя забывать о других популярных движках, например firefox
Ценный комментарий, но не все умеют ими пользоваться, а уж pagespeed/webpagetest сложно заменить встроенными инструментами :)
Было полезно, спасибо
Елена, давно читаю ваши статьи! Очень нравится, что вы все проблемы описываете именно в точку. Как мне передать разработчику то, что найду, чтобы не возникло недопонимания? В каком формате это лучше делать?
Google Docs с несколькими колонками: устройство, браузер, страница, описание ошибки, скриншот, ответ разработчика, все :)