Контрольный список тестирования веб-сайта: пояснения к юзабилити-тестам, пользовательским приемочным тестам и AB-тестам

Резюме: Сочетание тестов юзабилити веб-сайта, приемочных тестов пользователей (UAT) и тестов AB может показаться огромной работой. Но наличие контрольного списка тестирования веб-сайта, который нужно пройти перед запуском функции или пути, на самом деле экономит время и деньги в долгосрочной перспективе.

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

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

Чтобы всего этого избежать, нужны тесты. Но какие? И когда вы применяете все это?

Здесь может помочь контрольный список тестирования веб-сайта.

Давайте погрузимся.

1. Применение юзабилити-тестов

Юзабилити-тесты — это, по сути, интервью с людьми, которые пытаются что-то использовать, и их следует включить в контрольный список тестирования вашего сайта. Ты …

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

Юзабилити-тесты на сайтах конкурентов

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

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

Юзабилити-тесты внутренних функций

Принцип прост, хотя на практике это иногда усложняется.

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

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

И это в основном тест на юзабилити. Вы запустите это снова, когда у вас будет прототип, и еще раз, когда функция запустится.

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

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

«Хотите узнать больше о юзабилити-тестировании? Мы вас прикрыли. Прочитайте «Кратко об основах юзабилити-тестирования веб-сайтов»

2. Применение приемочных тестов пользователей (UAT)

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

Вот где вступает в действие приемочное тестирование веб-сайта, или UAT.

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

Это самое близкое к «реальному миру» испытание, которое вы проведете перед запуском. UAT охватит больше, чем приведенные ниже сценарии, но вам, по крайней мере, нужно понять, если…

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

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

После учета UAT весь процесс выглядит следующим образом:

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

3. Применение тестов AB / сплит-тестов

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

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

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

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

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

Важность контрольного списка тестирования веб-сайта

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

Звучит как дополнительная работа, но на практике большая часть работы приходится на переделку страниц, которые не работают, или функций, которые ломают другие вещи. Реализация тестов обычно не приводит к потере времени; для большинства ваших крупных проектов они на самом деле сэкономят время, потому что вы не будете менять цели в середине или вносить «панические изменения» непосредственно перед запуском.

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

Этот пост был первоначально опубликован в августе 2015 года и был обновлен для полноты информации.