«А вот другу магазин разработали, запустили и все работает. Если делали хорошо, зачем проверять?»
Потому что ни один серьезный продукт не выпускается в люди без итогового тестирования. Mercedes-Benz перед запуском модели в массовое производство проводит 28 краш-тестов. Nokia подвергает свои телефоны 200 механическим испытаниям. Велосипеды «Велотрейд» проходят 5 тестов по 100-108 часов каждый. Чем сайт хуже?
Вообще, фанаты экспериментов и исследований за 5 минут набросают вам список из 10-20 видов тестирований. Мы же разберем только те, которые действительно нужны:
1. Тестирование производительности,
2. Нагрузочная оценка,
3. Тестирование безопасности,
4. Юзабилити-тестирование.
Смотрим производительность
Тестирование производительности помогает понять, как быстро работает сайт, какова скорость подгрузки контента и основных интерактивных форм. Google регулярно намекает на зависимость ранжирования ресурса от скорости его работы, а Яндекс, хоть ничего прямо не говорит, то и дело ссылается на поведенческие факторы. Которые при медленной работе сайта просто не могут быть удовлетворительными.
В процессе тестирования производительности проверяются 6 метрик PageSpeed Insights:
- Загрузка первого контента,
- Индекс скорости подгрузки,
- Время загрузки интерактивных элементов,
- Срок подгрузки значительной части контента,
- Окончание работы ЦП.
- Время задержки страницы при вводе.
Как правило, новые сайты попадают в зеленую зону PSI. Это хорошо. Если перемудрили с тяжелой графикой и анимацией — PageSpeed Insights выдаст 50-89 баллов и набор рекомендаций.
Проверяем устойчивость
Нагрузочная оценка, по сути — часть тестирования производительности. Но так как ее делают не все и не всегда, мы выделили этот тест в отдельное направление. Цель тестирования — посмотреть, как поведет себя ресурс, если N пользователей зададут Y запросов в единицу времени. Это тестирование обязательно проводим для крупных интернет-магазинов и электронных каталогов. Чтобы знать, выдержит ли сайт 10 000 покупателей, спешно заполняющих корзины в 23:00 «Черной пятницы».
Ищем дырки
Главная цель тестирования безопасности — найти места, уязвимые для атак. Конечно, у большинства CMS есть встроенные модули безопасности, а серьезные ресурсы создают двойной-тройной уровень защиты, но…
Всегда находится тот, кому обязательно нужно проверить систему на прочность. Именно поэтому крупные проекты перед запуском в сеть обязательно обследуются на уязвимости: запросы к базе данных, отладочные скрипты, синтаксические теги HTML кода и пр. Если говорить о сайтах финансовой сферы, то для них даже предусмотрен специальный стандарт тестирования на проникновение — РС БР ИББС-2.6-2014. Вам он пригодится, если откроете банк и соберетесь делать интернет-банкинг.
Юзабилити-тестирование
Как бы ни хотелось упростить юзабилити-тестирование (UX) — не получится. Потому что UX — это совокупность экспериментальных методов. Очень разных, от очных интервью с фокус-группой до A/B тестов. Интервью, кстати, простейший вариант. В формате вопрос-ответ он дает массу полезной информации, особенно если после сбора данных провести их сравнение и анализ.
Модерируемое и немодерируемое UX проводится по заранее сформированному сценарию, в котором респонденту предлагается выполнить ряд задач: собрать товары в корзину, подписаться на рассылку, найти дополнительный продукт к основному и пр.
Отдельный формат юзабилити-тестирования — партизанское. При таком варианте исследования пользователь не знает, что участвует в тестах.
А/Б тестирование подходит для ситуаций, когда у вас есть два варианта дизайна и непонятно, какой лучше. Цель исследования — выяснить, с каким набором элементов у страницы/сайта/электронного письма больше конверсия. Проще говоря, вы берете два прототипа или готовых лендинга, направляете на них трафик и смотрите, где результат лучше. Показательный способ исследования, но есть несколько нюансов:
- в тестировании должны принимать участие ВСЕ сегменты аудитории, иначе результаты будут нерепрезентативны,
- за один раз можно проверять только ОДИН элемент — текст, размер кнопки, расположение видео,
- тестирование требует от 1 суток до 2 недель — чем дороже товар, тем длиннее цикл покупки, сами понимаете,
- для статистически достоверных результатов придется отсечь экстремальные значения или доказать, что они не искажают факты.
Частный случай А/Б тестирования — eye-tracking. Эта технология регистрирует движение глаз пользователя, создавая нечто вроде тепловой карты страницы. По ней видно, откуда респондент начинает просматривать массив данных, где задерживает взгляд — читает, на каком этапе бросает просмотр. Для сайтов малого и среднего бизнеса технология дорогая и избыточная, но если соберетесь запускать масштабный проект — присмотритесь к ней.
Когда тестируем
Юзабилити-тестирование выполняют как на стадии прототипирования сайта, так в рамках маркетингового аудита готового ресурса. В первом случае тестирование исключает догадки, интуицию и художественные предпочтения заказчика/дизайнера. После тестов прототипа остаются голые факты: этот вариант рабочий, а этот — провальный. Правда, многое зависит от детализации. Тест рабочего и предельно детализированного прототипа будет результативным. Оценка абстрактной схематичной концепции даст мало полезных данных.
UX-тесты готового ресурса проводятся, когда и цены на сайте нормальные, и товар качественный, и дизайн лучше, чем у конкурентов и основные страницы в ТОПе, а продаж нет. Чтобы понять, в чем препятствие — подключаем тяжелую артиллерию: Google Analytics сервис «Эксперименты», тестировщиков кроссбраузерности, «Вебвизор», карту скроллинга и так далее. На выходе получается отчет с ошибками и рекомендациями по их устранению.
Когда тестировать юзабилити не нужно
- Для маленьких проектов с маленьким бюджетом. Нет, это не дискриминация. Это как зонтик для рыбки или меховая шапочка для белого медведя — лишняя трата времени и денег.
- Если на сайте есть технические или контентные проблемы. Обычного тестирования мало. Нужен комплексный аудит и комплексное решение проблем.
- Когда мало трафика. Иначе результаты будут нерепрезентативны.
Давайте резюмируем. Юзабилити-тестирование — полезный инструмент, но не ждите чуда. Он применим не везде и не всегда, а после тестов все равно придется поработать руками: исправить неработающие формы, поиграть со шрифтами, добавить/убрать кнопки.
