Как искать баги на сайтах


Список Часто Встречающихся Веб Багов

Еще Канер в своей книге «Тестирование ПО» составил список из 400 ошибок. Однако это было в 1999.
Но многие из них еще актуальны.
Я настоятельно рекомендую тебе их прочитать. Они идут отдельной главой в конце книги.
Я же составил для тебя список наиболее часто попадающихся МНЕ ошибок.
Список привожу ниже. Надеюсь он принесет тебе немало пользы.


Список Часто Встречающихся Веб Багов:

-- Проверка поля email
 
 Это поле пожалуй самое популярное поле по пропуску 
 проверки данных что мне встречалось. 
 Программисты упорно пропускают проверку правильных 
 и неправильных данных в это поле.
 Минимально оно проверяет введено ли туда хоть 
 что нибудь, и уже радостно считает что все хорошо. 
 Или если знак @ в поле введено - значит там точно 
 написал емаил. Чего заморачиваться то?
-- Кнопка\ссылка не работает
 
 Эта ошибка по количеству куда чаще существует 
 чем предыдущая. Ссылок на сайтах встречается много 
 и данные на которые они ссылаются часто изменяются,
 удаляются, переезжают на другой адрес.
 С кнопками сложнее. 
 Они либо не работают - и это плохо. 
 Либо перестают работать после каких то действий 
 пользователя.
-- Кнопка\ссылка открывает совсем другую информацию
 
 Раз уж речь пошла про ссылки. Почему бы не упомянуть
 неверную инфу по ссылке. Ее легко пропустить если не
 вчитываться в то что ссылка открывает и не знать на что
 на самом деле ссылка должна ссылаться.
-- Обязательные поля
 
 Иногда программист забывает установить какие поля
 являются обязательными.
 Поэтому иногда можно зарегистрироваться или сделать
 заказ без указания важных данных.
-- Отсутствует, пропадает или не обновляется
  информация которая должна быть
 
 Цифра может обновиться один раз и застыть так не
 изменяясь. Так бывает с итоговым подсчетом средств
 или количеством набранного товара.
-- Нет оповещения, что подтверждение пароля не верно
 
 При регистрации пароль пишется дважды, чтобы
 исключить ошибки пользователя.
 Программист может прописать лишь один раз
 проверить пароль с повторным паролем и дальше дать
 добро на регистрацию.
 Однако пользователь может передумать и записать
 другой пароль, даже если первый раз эти два поля он
 заполнил верно, второй раз он тоже может сделать
 ошибку. Однако программист не считает что нужно
 проверять это больше одного раза.
-- Избирательный поиск
 
 Для удобства поиска товаров в интернет-магазине
 каждому товару присваивают номер, введя который в
 поиск сайта можно сразу же найти товар. Обычно это 
 5-6 цифр.
 Поиск может находить товар по названию, но
 пропускать этот самый номер - номерной атрибут
-- Буква Ё
 
 О ней забывают, а иногда программист ограничивая
 разрешенный набор ввода символов для поля случайно
 выкидывает и букву Ё. Не забудь это проверить
-- Не удаляется аккаунт
 
 Если ты можешь зарегистрироваться, у тебя должна
 быть возможность удалить свой аккаунт и эта функция
 не должна быть упрятана далеко.
-- 31 число месяца
 
 Не везде выбор даты выбирается с помощью
 всплывающего календаря. Иногда день, месяц и год
 вводятся раздельно.(Дата рождения например).
 Проверяй месяц в котором нет 31-ого дня.
 (февраль, апрель, июнь, сентябрь, ноябрь)
-- Нет оповещения о неправильных, не валидных
  данных в полях
 
 (Нет красной рамки, нет вплывающего окна).
 Хотя программа считает поле неправильно
 заполненным и не дает отправить данные, но она
 не показывает какое поле неправильно заполнено.
-- Кнопка enter
 
 Иногда подтверждение введенной информации в поле
 кнопкой "enter" на клавиатуре (а не кнопкой на сайте)
 приводит к ошибке или перевод на пустую\другую не
 очевидную страницу.
-- Internet Explorer
 
 Этот браузер один сплошной баг. Особенно версии 8,9,
 10,11.
 Ранние версии тоже глючные, но они встречаются
 сейчас гораздо меньше.
 Этот браузер стоит по умолчанию при установке
 Windows на компьютер. А большинство пользователей
 не знает, не умеет или им лень ставить другой браузер.
 Поэтому большая доля трафика открывается именно
 этим браузером.
 Именно этот браузер сильно отличается от других в
 отображении сайта. Именно в нем верстка тестируемого
 сайта сдвинута, поломана и вообще поля и кнопки
 реагируют непредсказуемо.
 Мой самый странный баг в Internet Explorer был
 связан с заполнением числовых полей.
 Если в поле вписать число начинающееся с цифры 0
 (например 0100), то в подсчете итогов была совсем
 иная цифра(для 0100 итог был 64) и какой то связи,
 формулы я не нашел. А если второй цифрой после 0
 была 8 или 9 то поле вообще считалось пустым,
 незаполненным.
 Такое повторялось только в Internet Explorer. В других
 браузерах было все в порядке.
-- Стрелка "назад" в браузере
 
 Пользователь может попытаться вернуться назад чтобы
 исправить какую то информацию. А предыдущая
 информация не отображается\стирается
-- Смещение или наложение верстки
 
 При изменении размеров браузера или используя
 машины с маленьким разрешением (нетбуки, планшеты,
 телефоны) смещается верстка или одна информация
 накладывает на другую что затрудняет чтение.
-- Вводится больше текста чем отправляется
 
 Некоторые поля не ограничены максимальным числом
 символов. Из-за этого текст может быть больше чем
 размер отправляемого браузером пакета. Из-за этого
 выскакивает ошибка, либо сообщение обрезается и
 доставляется на сервер не полностью.
-- Не работает определенная сортировка записей\фильтры
 
 Определенная сортировка не сортирует записи. Ничего
 не происходит когда ее выбираешь.
 Встречается в интернет-магазинах.
-- Проблемы с горизонтальными и вертикальными
  полосами прокрутки
 
 Либо полосы не появляются при изменении размеров
 окна. Либо при использовании компьютеров,
 планшетов с маленьким разрешением - различные
 меню и навигация сайта просто не подстраивается под
 меньшие размеры экрана и не показываются полосы
 прокрутки.
-- Никак не валидируются важные поля, вроде
  телефона или логина, никнейма
 
 Существуют обязательные поля ввод данных в которые
 необходимо ограничивать. Но программист этого не
 делает.
 Чаще он даже не удаляет пробелы из этих полей и
 выходит так что поле вроде бы заполнено, но при этом
 может состоять из одних пробелов
 (сложно отличить - заполнено или нет)
-- Не регистрируется следующий "новый пользователь"
 
 У меня был случай когда после выхода
 залогированного пользователя я не мог зарегистрировать
 новый аккаунт.
 В одной из бирж бронирования авиабилетов. Если
 выбираешь выход из профиля и попадаешь на страницу
 с которой можно зарегистрировать нового пользователя
 - грех это не попробовать.
-- Бесконечный цикл загрузки
 
 Неверно составленный цикл программистом может
 привести к зацикливанию. Жрется память и сначала
 зависает браузер, а потом и операционная система.
 Вызвать это может все что угодно - кнопка, ссылка,
 загружаемый файл.
 Не забывай следить за памятью которую жрет браузер и
 каждая страница\процесс.
-- Поле для ввода url сайта
 
 Иногда программист уже ставит "http://" вначале по
 умолчанию, но в поле это не отображается. И если
 пользователь вводит url сайта с "http://" вначале тогда
 поле считается некорректно заполненным. А если
 пользователь введет просто www и дальше сайт - то
 поле будет считаться правильно заполненным.
 Хотя такая реакция сайта неправильна - пользователь
 может вводить сайт как с http вначале так и без него. 
 Он не должен впасть в ступор от того, что поле считает 
 его url неправильным.
-- Итоговая цена
 
 Не всегда итоговая цена соответствует всем выбранным
 параметрам. Программист может забыть вписать
 бонусы, акций и срок этих бонусов\акций.
-- Отрицательное значение в поле (цены, количества)
 
 Можно ввести отрицательную сумму. А иногда и
 перевести себе на счет эту сумму =)
 Так было с сайтом Амазон.
 "На заре Amazon, покупатели могли заказать 
 отрицательное количество книг, и обозначенная 
 сумма поступала на их кредитные карты."
-- Кнопка меньше Кнопки-Картинки
 
 Картинка используется как кнопка. И должна она 
 прокликиваться по все картинке если не указано
 обратного.
-- Нельзя зарегистрироваться на тот же email
 
 После удаления аккаунта нельзя зарегистрироваться
 на тот же логин или email
 Такого ограничения быть не должно.
-- Изменение одного параметра обнуляет другой параметр
 
 Обычно это в фильтрах интернет-магазинов. Там
 необходимо много фильтров чтобы удобнее находить
 нужные товары. Однако иногда изменение одного
 параметра обнуляет другой. Или манипуляция с одними
 данными затрагивает или обнуляет данные в других
 полях. Хотя такая зависимость ни чем не обусловлена
 и нигде не указывается.
 Например:
 Заполнив все поля нажал кнопку "добавить строку" и
 потом ее удалил - результат: Все ранее заполненные
 данные обнуляются.
-- Неправильно подобраны картинки
 
 В некоторых интернет-магазинах есть возможность
 выбрать цвет товара, например платья и при этом
 отобразиться и картинка платья с выбранным цветом.
 Некоторые товары могут иметь неправильно
 подобранные картинки под каждый цвет. Например
 содержать отличный цвет от указываемого или вообще
 на каждый выбор стоять картинки одного цвета.
-- Ошибка смены валюты
 
 В общей стоимости бронирования при смене валюты
 цифра может не поменяться.
 Перепроверяй валюту.
-- Нельзя сменить пароль
 
 Много проблем таит в себе смена пароля. Или новый
 пароль не высылается на почту. Или просто
 невозможно сохранить новый пароль.
-- Опечатки
 
 Конечно же опечатки. Я их совершаю постоянно.
 Где то одну клавишу быстрее чем другую нажмешь, а
 где то вообще забудешь нажать. Так или иначе опечатки
 не редкость, но от них лучше избавляться. Тем более что
 их исправление ничего сложного не затрагивает.
 

 

P.S. Надеюсь этот список поможет тебе лучше искать ошибки.

 

Напиши какие ошибки встречаются тебе. А какие тебе сложно находить или ты их вообще пропускаешь.
Напиши помог ли тебе этот список лучше находить ошибки?

27 Советы по поиску ошибок на вашем сайте

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

Тест мобильной готовности

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

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

Кроссбраузерное тестирование

Прошли те времена, когда Internet Explorer был единственным браузером, доступным на рынке. Многие новые браузеры вводятся почти ежедневно, и часто веб-приложения, которые отлично работают в Google Chrome, не работают в Opera, Safari или других браузерах

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

Тестирование доступности

W3C установил ряд руководящих принципов и стандартов, которые организации или частные лица должны соблюдать перед запуском своего веб-приложения. В правилах указано, что приложение должно быть доступно всем, особенно людям с ограниченными возможностями.

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

Общая проверка HTML и CSS

  • Убедитесь, что ваш код HTML или XHTML не содержит ошибок, проверив его с помощью W3C Markup Validation, официального инструмента проверки Консорциума World Wide Web.
  • Существуют и другие инструменты, такие как HTML Tidy, инструменты Google для веб-мастеров и т. Д., Которые могут искать в коде повторяющиеся метатеги, битые ссылки, отсутствующие заголовки или другие ошибки.
  • Служба проверки CSS, предоставляемая W3C, может использоваться для обнаружения любых ошибок или нарушений соответствия в вашем CSS.
  • После проверки кода предлагаемый инструмент, который можно использовать, - это CSS Compressor. Он минимизирует файл, сжав весь код в одну строку. Для большой страницы с тысячами строк CSS этот инструмент может ускорить время загрузки.

Тестирование безопасности для входа на сайт

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

  • Убедитесь, что учетная запись заблокирована после многократного ввода неверного пароля или идентификатора пользователя.
  • Обеспечьте предотвращение автоматического входа в систему с помощью таких методов, как проверка OTP или CAPTCHA при входе в систему.
  • Проверить шифрование файлов cookie и кеша.
  • После выхода пользователя из системы нажмите кнопку «Назад», чтобы убедиться, что сеанс просмотра истек.

Тестирование производительности приложения

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

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

Бета-тестирование реальными пользователями

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

  • Бета-тестирование очень важно, поскольку пользователи перемещаются по сайту и склонны обнаруживать любые слабые места со своей точки зрения.
  • Ваша группа тестирования следует набору правил для выполнения модульного тестирования. Настоящие пользователи часто думают нестандартно и могут заметить ошибку, которую группа тестирования могла пропустить.

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

Автор Арнаб Рой Чоудхури

Арнаб Рой Чоудхури - разработчик пользовательского интерфейса по профессии и энтузиаст ведения блога. Он пишет контент около 5 лет и имеет большой опыт в технических блогах, путевых заметках и контенте на новейших языках программирования.

.

27 советов по поиску ошибок на вашем сайте

Если вы разрабатываете веб-сайт для личного использования, для клиента или для своей организации, очень важно, чтобы на нем не было ошибок. Ошибка в вашем приложении не только испортит удобство использования вашего сайта, но также повлияет на вашу репутацию как разработчика. В этой статье мы обсудим базовый контрольный список, который позволит вам развернуть веб-приложение без ошибок в производственной среде.

Тест мобильной готовности

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

  • Настройте список устройств, на которых ваше приложение должно работать безупречно, с помощью поиска с помощью Google Analytics.
  • Вы можете использовать расширения эмулятора мобильных устройств в браузерах для тестирования своего приложения.
  • Если бюджет проекта велик, вы можете предоставить своей группе тестирования несколько портативных устройств с другой операционной системой, чтобы можно было проводить тестирование в реальном времени, поскольку эмуляторы часто пропускают определенные ошибки.
  • Убедитесь, что нет горизонтальной прокрутки; шрифты и кнопки удобочитаемы и сенсорны; а контент и изображения достаточно большие для маленького экрана.

Кросс-браузерное тестирование

Прошли те времена, когда Internet Explorer был единственным браузером, доступным на рынке. Многие новые браузеры вводятся почти ежедневно, и часто веб-приложения, которые отлично работают в Google Chrome, терпят неудачу в таких браузерах, как Opera, Safari и других.

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

Тестирование доступности

W3C установил ряд руководящих принципов и стандартов, которые организации или частные лица должны соблюдать перед запуском своего веб-приложения. В правилах указано, что приложение должно быть доступно всем, особенно людям с ограниченными возможностями.

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

Общая проверка HTML и CSS

  • Убедитесь, что ваш код HTML или XHTML не содержит ошибок, проверив его с помощью W3C Markup Validation, официального инструмента проверки Консорциума World Wide Web.
  • Существуют и другие инструменты, такие как HTML Tidy, инструменты Google для веб-мастеров и т. Д., Которые могут искать в коде повторяющиеся метатеги, битые ссылки, отсутствующие заголовки или другие ошибки.
  • Служба проверки CSS, предоставляемая W3C, может использоваться для обнаружения любых ошибок или нарушений соответствия в вашем CSS.
  • После проверки кода предлагаемый инструмент, который можно использовать, - это CSS Compressor. Он минимизирует файл, сжав весь код в одну строку. Для большой страницы с тысячами строк CSS этот инструмент может ускорить время загрузки.

Тестирование безопасности для входа на сайт

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

  • Убедитесь, что учетная запись заблокирована после многократного ввода неверного пароля или идентификатора пользователя.
  • Обеспечьте предотвращение автоматического входа в систему с помощью таких методов, как проверка OTP или CAPTCHA при входе в систему.
  • Проверить шифрование файлов cookie и кеша.
  • После выхода пользователя из системы нажмите кнопку «Назад», чтобы убедиться, что сеанс просмотра истек.

Тестирование производительности приложения

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

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

Бета-тестирование реальными пользователями

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

  • Бета-тестирование очень важно, поскольку пользователи перемещаются по сайту и склонны обнаруживать любые слабые места со своей точки зрения.
  • Ваша группа тестирования следует набору правил для выполнения модульного тестирования. Настоящие пользователи часто думают нестандартно и могут заметить ошибку, которую группа тестирования могла пропустить.

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

.

Найдите ошибки веб-сайта на вашей новой странице или сайте: трехэтапная структура

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

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

Шаг 1: просмотрите записи, чтобы найти и определить приоритеты, что нужно исправить

Шаг 2: просмотрите тепловые карты для выявления проблем на отдельных страницах

Шаг 3: выясните, ПОЧЕМУ что-то не работает с отзывами Опросы

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

Шаг 1. Просмотрите записи, чтобы найти и определить приоритеты, что нужно исправить.

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

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


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

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

В меню боковой панели выберите «Записи» и настройте их так, как вам нужно (ниже приведены пошаговые инструкции для , начиная с , если вы не делали этого раньше).

Посмотрите подборку пользовательских путешествий по сайту

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

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


В зависимости от того, какой объем трафика вы получаете на свой веб-сайт, вы можете обнаружить десятки или даже сотни записей в час (а) после запуска.Исходя из опыта, вам нужно всего около 5-10 записей, чтобы попасть в хороший поток просмотра. Для начала:

  • Заставьте всех в вашей команде просмотреть 20-30 записей за один раз и отчитаться, или
  • Просмотрите 30-50 записей, если вы один.
  • Пропускайте паузы и / или смотрите с увеличенной скоростью для экономии времени (см. две кнопки ниже, выделенные красным)

Примечания к запуску, который почти не прошел

Вскоре после запуска для ~ 600 пользователей мы получили первый звонок в службу поддержки: что-то ломалось.Итак, мы прошли два или три раунда, внимательно наблюдая за записями и выясняя, где лежат пути отказа. Когда пользователь пытается выйти в Интернет и у него возникают проблемы, это довольно пугает. Мы смогли очень быстро внести множество исправлений, просто внимательно просматривая записи. Я должен сказать, что без записей, я не знаю, могли ли мы даже иметь представление о том, что на самом деле происходит.
(
Полную историю читайте здесь )

Джон Керн - менеджер по стратегическим продуктам, Intelliquip

5 распространенных ошибок веб-сайтов, которые можно обнаружить с помощью записей

Просматривая записи, обращайте внимание на следующие ошибки:

  • Ошибки совместимости , при которых страницы загружаются неправильно на разных устройствах / браузерах
  • Ошибки функциональности , когда веб-сайт не выполняет то, что должен (например, : пользователи пытаются войти в систему, но не могут, или нажимаемые кнопки или элементы не работают)
  • Ошибки макета и дизайна , когда элементы страницы не отображаются правильно
  • Необычная активность мыши , такая как дикая прокрутка или повторный щелчок, который может указывать на то, что посетители не находят то, что им нужно
  • Проблемы с навигацией , например страницы 404 (чтобы найти их, отфильтруйте их по соответствующему URL-адресу, например https: // www.yoursite.com/404 . Если вы их найдете, следование обратному пути поможет вам увидеть, как люди туда попали)

Совет от профессионала : регистрируйте каждую ошибку, отмечая записи; позже вы можете фильтровать по отдельным тегам и повторно просматривать только соответствующие файлы. Заранее выберите соглашение об именах: некоторые из тех, что мы используем в Hotjar, включают Неработающая ссылка для связи с нами, Ошибка, Используемые фильтры, Неудачно, Для расследования, Похоже, не удалось найти цены, Проблема с проверкой - могут быть эти может зажечь идеи для вашей команды.

Поделитесь результатами с командой разработчиков продукта / продукта

Если вы и ваша команда разработчиков продукта или продукта используете систему управления проектами, такую ​​как Jira или Trello, создайте и добавьте ссылки записи к отдельным тикетам или запросам на исправления: это дает тем, кто отвечает за решение проблемы, возможность увидеть, как это происходит. прежде, чем войти и работать над исправлением.

Шаг 2: используйте тепловые карты, чтобы найти проблемы на отдельных страницах

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

пример тепловой карты с прокруткой (слева) и карты кликов (справа)

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

Пример тепловых карт до и после изменений от Bannersnack, которые улучшили CTA на главной странице

В Hotjar используйте двухэтапный подход:
1) Прежде чем выпускать изменения , настройте тепловую карту на наиболее релевантных / важных страницах:

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

Примечание: для того, чтобы тепловая карта начала работать, достаточно одного человека, чтобы посетить страницу, но данные, основанные только на одном посетителе, не будут очень полезны, поэтому не забудьте дать инструменту некоторое время, чтобы собрать хороший объем данных. (100-200 посещений - хорошая отправная точка).

Используйте тепловые карты, чтобы узнать, что вызывает наибольшее взаимодействие

Нажми и коснись тепловые карты показывают, где посетители щелкают курсором на настольных устройствах и нажимают на экран мобильных устройств и планшетов:


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

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

Примечание редактора: еще в 2018 году мы изменили дизайн домашней страницы Hotjar и добавили видео там, где его раньше не было.Мы также разместили тепловые карты на обновленной странице:

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

Используйте прокручиваемые тепловые карты, чтобы узнать, сколько посетителей просматривают страницы

Прокрутка тепловых карт показывает , насколько далеко вниз по странице прокручивают посетители :

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

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

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

Проверить наличие различий между устройствами

Программа записи сеанса

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

Поделитесь тепловыми картами и выводами со своей командой и / или клиентами

Из-за своего визуального воздействия тепловые карты обычно очень эффективны, помогая вашим продуктам / разработчикам и клиентам быстро понять, как действуют внесенные вами изменения . Вы можете загрузить тепловые карты и / или создать уникальные URL-адреса, чтобы поделиться с ними в виде ссылки - трудно спорить с тепловой картой, когда она показывает, что ваш новый дизайн страницы работает лучше, чем старый 😉

от наших клиентов: команда @ Skyscanner просматривает тепловые карты страницы

Шаг 3. Узнайте, ПОЧЕМУ что-то не работает, с помощью отзывов на месте

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

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

Создайте в Hotjar опрос на месте (мы называем их «Опросы») и разместите его на любой странице (ах), которую вы хотите изучить; настроить цвет и внешний вид в соответствии со стилем вашего бренда:

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

(ПРИМЕЧАНИЕ. Опросы работают лучше, если у вас около 1000+ пользователей в день. При меньшем объеме трафика вы, вероятно, выиграете от «партизанского исследования», когда вы просто покажете веб-сайт нескольким людям и спросите их вопросы напрямую.)

Спросите посетителей, почему они уходят

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

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

  • Почему вы уходите с этой страницы?
  • Что неясно в этом шаге / странице?
  • Перед тем, как уйти: чего не хватает на этой странице?
  • Не для тебя? Расскажите, почему:


Или вы можете попробовать менее прямой подход:

  • Что вы ожидаете делать после этой страницы?
  • Есть ли что-то, что, по вашему мнению, следует добавить на эту страницу?
  • Если бы вы могли добавить ОДНО на эту страницу, что бы это было?

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

Спросите совета у посетителей

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

  • Что вы ожидаете, когда вы нажмете [вставить описание элемента, по которому щелкнули]?
  • Что вы ожидаете после этой страницы?
  • Как можно улучшить эту страницу / раздел / форму / [и т. Д.]?
  • Что может повысить вероятность [вставить желаемое действие]?

Не нужно останавливаться на открытых вопросах.Вы можете использовать подход ДА / НЕТ, чтобы дать людям варианты и связать их с последующим вопросом:

  • Есть ли на этой странице что-нибудь, что не работает так, как вы ожидали? Да / Нет ( Если люди ответят «да», введите : укажите, что именно)
  • Вы бы предпочли видеть [X] на этой странице? Да / Нет (если нет: почему?)

Примечание редактора: вот удобное руководство, которое научит вас анализировать результаты открытых вопросов после того, как вы соберете соответствующее количество ответов.

Ваш трехэтапный контрольный список готов к использованию:

(щелкните изображение, чтобы увидеть полноразмерную версию)

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

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

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

Подготовьтесь к запуску сайта 🤞

Настройте Hotjar как можно скорее и собирайте необходимую информацию до, во время и после запуска веб-сайта.

.

Как отправить отчет об ошибке в Bugzilla

Я провожу много времени, исследуя свои книги и статьи Opensource.com. Иногда это приводит меня к обнаружению ошибок в программном обеспечении, которое я использую, включая Fedora и ядро ​​Linux. Как давний пользователь Linux и системный администратор, я получил огромную пользу от GNU / Linux, и мне нравится давать взамен. Я не программист на языке C, поэтому я не создаю исправления и не отправляю их с отчетами об ошибках, как это делают некоторые люди. Но один из способов вернуть ценность сообществу Linux - это сообщать об ошибках.

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

Начать поиск

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

Если окажется, что никто не сталкивался с этой проблемой раньше (или, если они были, они не сообщили об этом как об ошибке), я захожу на сайт Red Hat Bugzilla и начинаю поиск отчета об ошибке, который может быть близок к соответствующему симптомы, с которыми я столкнулся.

Вы можете выполнять поиск на сайте Red Hat Bugzilla без учетной записи.Перейдите на сайт Bugzilla и щелкните вкладку «Расширенный поиск».

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

Поле Логика Данные или выбор
Сводка Содержит строку Ядро режима восстановления
Классификация Fedora
Товар Fedora
Компонент grub2
Статус Новое + Назначено

Затем нажмите Поиск .Это возвращает список одной ошибки с идентификатором 1654337 (это ошибка, о которой я сообщил).

Щелкните ID, чтобы просмотреть подробности моего отчета об ошибке. Я ввел как можно больше релевантных данных в верхний раздел отчета. В комментариях я описал проблему и включил вспомогательные файлы, другие соответствующие комментарии (например, тот факт, что проблема возникла на нескольких материнских платах), а также шаги по воспроизведению проблемы.

Здесь вы можете предоставить дополнительную информацию, относящуюся к ошибке, такую ​​как симптомы, аппаратные и программные среды (если они применимы), другое программное обеспечение, которое работало в то время, уровни выпуска ядра и дистрибутива и т. Д., легче будет определить, куда привязать вашу ошибку.В этом случае я изначально выбрал компонент ядра, но он был быстро заменен на компонент GRUB2, поскольку проблема возникла до загрузки ядра.

Как отправить отчет об ошибке

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

Консультации: Bugzilla - это рабочий веб-сайт, на который люди рассчитывают получить поддержку. Я настоятельно рекомендую не создавать учетную запись, если вы не собираетесь отправлять отчеты об ошибках или комментировать существующие ошибки.

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

Войдите в свою учетную запись и нажмите New в строке меню или кнопку File a Bug .Вам нужно будет выбрать классификацию ошибки, чтобы продолжить процесс. Это сузит некоторые варианты на следующей странице.

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

Когда вы вводите краткое описание проблемы в поле Сводка , Bugzilla отображает список других ошибок, которые могут совпадать с вашей. Если один из них совпадает, щелкните Добавить меня в список CC List , чтобы получать электронные письма об изменениях в ошибке.

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

Когда вы закончите добавлять как можно больше информации, нажмите Отправить ошибку .

Будьте добры

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

Убедитесь, что вы отправляете сообщения об ошибках на правильный веб-сайт сообщений об ошибках. Например, отправляйте сообщения об ошибках в продуктах Red Hat только в Red Hat Bugzilla и отправляйте сообщения об ошибках в LibreOffice, следуя инструкциям LibreOffice.

Сообщать об ошибках несложно, и это важный способ участия.

.

Смотрите также

Поделиться в соц. сетях

Опубликовать в Facebook
Опубликовать в Одноклассники
Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий