UX и юзабилити — контроль качества

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

— Д-р Ральф Спет, генеральный директор Jaguar Land Rover.

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

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

Результаты этого фокуса говорят сами за себя.

Например, каждый доллар, вложенный в UX, приносит 100 долларов взамен. исследовательский отчет Forrester. Кроме того, исследование за 10-летний период показывает, что финансовые показатели компании, ориентированные на дизайн, опережают S&P на 219%.

Существует также легендарная история о том, как просто изменить текст на одна кнопка увеличил продажи на 300 миллионов долларов в компанию электронной коммерции за один год!

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

Настоящая проблема — это приложения с OKish UX. Это тот вид, который является пресловутым опытом «занозы в вашем уме», который вы не можете на всю жизнь понять, почему он вам не нравится!

Я слышу, как вы говорите: «Мы все это знаем; Я читаю The QA Lead, потому что плачу в голос, так какое же это имеет отношение ко мне?» Я иду к этому.

Важность UX

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

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

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

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

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

1. Она взяла на себя обязательство освежить свои знания UX, прочитав несколько интенсивных книг.
2. Затем она сама провела базовый эвристический обзор UX для реализованной функциональности, поговорила с UX-специалистами и получила их помощь там, где это было необходимо.
3. Она создала новые задачи в JIRA, чтобы исправить разницу между тем, что было обещано, и тем, что было выполнено — с точки зрения UX.
4. Она связалась с нашим руководителем UX и получила его одобрение, чтобы убедиться, что был установлен новый процесс, в котором визуальные аспекты приложения фиксировались во время каждого спринта, а не только в конце.
5. Наконец, она также научила наших QA-специалистов понимать основы UX, чтобы они могли выявлять вопиющие проблемы и помогать команде решать их на ранних стадиях.

Глазурь на торте? Во время следующей демонстрации спринта владелец продукта / клиент улыбался, и через несколько месяцев наш руководитель отдела контроля качества был повышен до менеджера по контролю качества! 😉

Романтические и классические взгляды на реальность

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

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

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

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

Есть несколько интересных следствий такого способа классификации мира:

1. По умолчанию у большинства людей доминирует либо классическая, либо романтическая точка зрения, но не то и другое одновременно.
2. Люди — думаю, клиенты, внутренние или внешние — с романтической точки зрения значительно превосходят численностью тех, кто придерживается классической точки зрения. Если вам когда-нибудь приходилось играть роль техподдержки семьи и друзей, вы понимаете, о чем я говорю!

3. Очень немногие могут переключать режимы, и даже для них это деятельность, требующая усилий.
4. Реальность = классика + романтика. Они не исключают друг друга. Оба являются существенными аспектами тотальности. Красота функциональна. Функция может быть красивой.

Возьмем, к примеру, цветы. У них такие великолепные узоры, которые, кажется, не имеют никакой функции. Тем не менее красота, которую мы видим в цветах, имеет базовую структуру, основанную на математике: Последовательность  Фибоначчи управляет структурой и узорами, которые мы видим в цветах. Структура и неземная красота идут рука об руку в природе.

И дело не только в красоте. Расположение семян в подсолнухе соответствует последовательности Фибоначчи и Золотое сечение для того, чтобы уместить максимально возможное количество семян в цветке. Те же принципы применимы к проектированию и пользовательскому опыту.

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

Роль контроля качества программного обеспечения в UX/юзабилити

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

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

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

Как выполнить обзор UX/юзабилити в качестве инженера-испытателя

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

Эвристика юзабилити для дизайна пользовательского интерфейса

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

Изучите принципы доступности

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

UX-команда — ваша новая тусовка

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

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

Включите аналитику в свой план тестирования

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

Сдвинься влево, пока ты не сможешь больше сдвинуться

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

До разработки

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

Если контроль качества еще не является частью этапа проектирования, сделайте это, если это возможно.

Целевое ручное тестирование

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

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

Тогда присмотритесь. Легко ли им пользоваться? Являются ли потоки очевидными и интуитивными? Они утомительны и медленны? Есть ли наложения или дублирование действий, которые могут раздражать пользователя? Является ли дизайн годный к употреблению при разных размерах экрана?

Ну наконец то

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

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

Вас это волнует? Или вы думаете, что UX лишь косвенно относится к этой области? Дайте мне знать в ваших комментариях ниже.