Найти тему

Продолжаем тему аудитов и поиска “узких мест” на сайте

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

Чтобы найти ошибки на сайте, нужно знать желаемый результат. Т.е. как должен работать функционал в норме. Даже опытному специалисту будет невозможно протестировать сайт/приложение, если нет понимания, что должно быть в конце. Первое, на что обращаем внимание, есть ли зафиксированные требования к проекту. Если есть — отлично, если нет, то проверяем по своему жизненному опыту и чек-листу ;)

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

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

Распространенные функциональные баги:

1) Нет результата от действий пользователя. Жмешь, а обратной связи от сайта нет. Например, кладешь товар в корзину, а в списке заказов он не отображается.

2) Нет адаптации под мобильное устройство. Проверить этот пункт можно, посмотрев сайт на мобильном устройстве. Частые проблемы: «расползается» текст, элементы «наезжают» друг на друга.

3) Данные не записываются. Пользователь может зарегистрироваться на сайте, увидеть сообщение об успешной авторизации, а по факту в базе данных он все еще отсутствует. Вариант похуже, когда пользователь оформляет заказ, а он «теряется». Это критичная ошибка сайта. Срочно пишите своему разработчику.

Самостоятельно можно проанализировать сайт при помощи https://validator.w3.org/, он проверяет валидность (правильность) верстки. Но скажем сразу, если Вы не верстальщик - даже не пытайтесь понять, что он от Вас хочет. Ругается — сообщите своему разработчику.

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

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

Хотелось бы еще немного внимания уделить интеграциям. Это одних из самых страшных багов, потому что проблемы могут быть как на сайте, так и в другой системе. Здесь также важно знать “как и когда должно быть”. Самая частая история — это интеграция сайта с 1С. Проверить ее достаточно просто: смотрите в 1С — смотрите на сайт. Если есть какие-то различия - начинаете выяснять, а точно ли эти товары должны быть в двух системах. Если в 1С есть товар, а на сайте нет — однозначно произошла ошибка синхронизации и здесь уже можно звать разработчиков.

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