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

Тестирование документации к программным продуктам

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

Перечень качеств, на которые можно ориентироваться при тестировании документации:

1. Работоспособность сценариев

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

2. Полнота описания

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

3. Уделение внимания обязательным пунктам

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

4. Актуальность описания

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

5. Адаптированность к тому, что пользователь будет в спешке

Важное качество. Редко когда бывает так, что документацию читают неспешно на досуге. Чаще всего люди обращаются к документации, когда у них что-то не работает, велика вероятность того, что пользователь читает документацию в нерабочее время. Здесь можно порекомендовать минимизировать количество цепочек действий с зависимостями. Выполнение сценария не должно напоминать прохождение квеста. Было бы хорошо, чтобы все необходимые условия для выполнения сценария были описаны до сценария. Можно привести такую аналогию: Если требуется прибить полку к кирпичной стене, то помимо полки в обязательном порядке потребуется перфоратор, бур, дюбель-гвозди.

6. Адаптированность к тому, что пользователь будет раздражен

Эмоциональная реакция при взаимодействии с программными продуктами имеет очень большое сходство с реакцией при взаимодействии с другими людьми. В случае, если пользователь читает документацию из-за того, что у него возникли какие-либо неполадки, скорее всего он будет в раздраженном состоянии. Здесь можно рекомендовать делать атомарность предложений и абзацев. Например, вместо <<Переустановите приложение, если возникают неполадки при использовании. Неполадки возникают когда установлен компонент-1 операционной системы, и в настройках операционной системы задано условие-2.>> лучше прописать <<Если установлен компонент-1 операционной системы и в настройках операционной системы задано условие-2, то в приложении могут возникнуть неполадки, решить которые можно лишь переустановкой.>>

7. Структурированность, адаптированность к быстрому поиску

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

8. Наличие указания на необратимость действий

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

9. Подтверждение ожидаемого

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

10. Описание последствий отсутствия действий пользователя

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

11. Ясность изложения информации

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

12. Логика и согласованность

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

13. Последовательность изложения

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

14. Орфография, синтаксис, пунктуация

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

15. Наличие описания настроек по умолчанию

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

16. Адаптированность к аудитории

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

17. Атомарность сценариев

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

18. Адаптированность к наименее возможной квалификации пользователей

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

Кому нужна качественная документация

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

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

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

Edit me

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

Преимущества тестирования инструкций

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

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

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

Во время тестирования находятся ошибки и в документации. Например, протестировав запросы API, можно обнаружить неверный параметр. Вместо verboseMode параметр был просто verbose. Такое маленькое несоответствие — одна из тех деталей, которые не обнаружить без тестирования, не обнаружить, что работает, а затем решите выяснить, что не так.

Тестируя REST API, можно отправлять тестовые запросы с помощью curl, Postman или другого инструмента. Сохраняя запросы, можно быстро запускать различные сценарии.

Когда мы начинаем проводить тесты и эксперименты, мы начинаем узнавать, что работает, а что нет.

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

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

Сквозь процесс

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

Иногда обнаружить ошибки можно только после создания своего собственного приложения и отправки его в AppStore.

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

Например, взять видеозаписи подкастов Write the Docs, и использовать их для приложения.
Поскольку шаблон приложения не поддерживает YouTube в качестве веб-хостинга, придется скачать MP4 с YouTube и загрузить их непосредственно на свой веб-хостинг. Затем нужно создать медиа-канал, который будет использоваться для интеграции с шаблоном приложения. Шаблон приложения может считывать все мультимедиа из канала, ориентируясь на него с помощью синтаксиса выражений Jayway Jsonpath или XPath.

Можно использовать Jekyll для подачи материала. (Материалы автора курса на основе JSON можно посмотреть по адресу podcast.writethedocs.org/fab.json.) Самым сложным в настройке является настройка объекта рекомендаций. Каждое видео имеет несколько тегов. Объект рекомендаций должен показывать другие видео с таким же тегом. Получить JSON там сложно, но можно рассчитывать на поддержку форума Jekyll.

После того, как получены мультимедийный материал, интегрировать их в Fire App Builder было легко, потому что, в конце концов, для этого уже есть документацию.
Отправка приложения в AppStore является увлекательной частью рабочего процесса разработчика, которые могут быть не понятны тех.писателю. Просмотреть приложение подкаста Write the Docs на веб-сайте Amazon AppStore здесь.

Вот как выглядят экраны приложений на Fire TV:

Если выбрать видео, появится экран предварительного просмотра:

Казалось, что все прошло хорошо, но потом обнаружились некоторые ошибки, которые не обнаружить, без отправки приложения в AppStore. Во-первых, ориентация на устройства (перечисление определенных функций в манифесте Android для определения того, какие устройства Fire поддерживает приложение) не работает правильно для приложений Fire TV. (Эта проблема не была напрямую связана с шаблоном приложения.)

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

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

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

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

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

Команда разработчиков также утверждала, что это же приложение может быть отправлено в магазин приложений Google Play. Однако никто не проверял такое предположение. При отправке приложение в Google Play, Google отклонил его из-за отсутствия активов баннера, заявленных в манифесте, что вызвало предупреждения «опасного разрешения». Информацию получили разработчики, которые создали заявку в JIRA для решения проблем. Такое тестирование позволит не только создавать лучшую документацию, но и улучшить продукты, на которые создается документация. (И в свою очередь такое отношение улучшит доверие среди разработчиков)

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

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

Возможность проверки дополнительных функций

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

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

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

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

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

Удовольствия тестирования

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

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

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

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

Учет необходимого времени

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

Но не стоит думать, что как только продукт будет выпущен, документация готова. Всегда можно вернуться к уже существующей, уже опубликованной документации и улучшить ее. Первый выпуск можно считать своего рода «версией 1» вашей документации. Это — первая итерация. Документация будет улучшаться с каждой итерацией. Если не получилось запустить тестовую систему до первого выпуска, это нормально. Можно создать тестовую систему для следующего выпуска.

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

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

🔙

Go next ➡

Ключ к написанию хорошей документации: тестирование инструкций

25.09.2017

Всем нам попадались инструкции, в которых было или сложно найти то, что нужно, или была куча непонятных терминов, или даже отсутствовали какие-то шаги в последовательности действий. А некоторые из нас и сами писали такие инструкции ? Чтобы этого избежать, необходимо проводить тестирование документации как неотъемлемой части разрабатываемых продуктов. Статья посвящена организации тестирования документации на предприятии и проблемам, которые при этом возникают. Автор: Том Джонсон, технический писатель из США.

Нет времени писать и/или тестировать инструкции? Заказать разработку инструкции в компании «ПроТекст» — лучшее решение!

---

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

О тестировании

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

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

Шаг 1: Создайте среду для тестирования

Первый шаг в процессе тестирования – создание среды для тестирования. Обычно у команды по контролю качества (QA) уже есть эта среда, в этом случае всё, что вам требуется – узнать, как получить к ней доступ. Получите соответствующую ссылку, идентификатор для входа, роли и т.д. от вашей команды по контролю качества. Узнайте у них, есть ли что-то такое, что вам нельзя менять или удалять, из-за того, что той же самой тестовой средой пользуются и другие группы. Без такой тестовой среды вам действительно будет трудно добиться хотя бы небольшого прогресса в тестировании ваших инструкций.

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

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

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

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

А иногда вам может потребоваться обойти сложности с безопасностью. Например, подключение к Amazon Web Services из внутренней сети может потребовать от вас пройти через промежуточный сервер. Поэтому, чтобы подключиться к тестовому образцу AWS, вам придётся подключиться через безопасное соединение к промежуточному серверу, и затем подключиться от промежуточного сервера к AWS.

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

Когда вы готовы отправить тестовый запрос (при условии, что у вас есть REST API), вы, вероятно, сможете использовать cURL, что упрощает задачу, но вам, конечно, придётся включить авторизацию в заголовке вызова. При авторизации часто используется хэш совокупности факторов.

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

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

Никогда не позволяйте разработчику говорить так: «Ой, тебе всего лишь нужно сделать a, b, c». Затем вы вернетесь к вашему рабочему месту, и ничего не будет работать, или всё окажется куда сложнее, чем он делал вид.

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

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

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

Шаг 2: Самостоятельное тестирование инструкций

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

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

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

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

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

Борьба с предположениями

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

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

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

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

Например, моя десятилетняя дочь начинает готовить. Она чувствует уверенность в том, что если инструкции понятны, она сможет сделать практически всё (если предположить, что у нас есть ингредиенты для этого). Однако она иногда говорит, что инструкции говорят ей сделать что-то, что она делать не умеет — например, потушить (в оригинале – sauté, прим. пер.).

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

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

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

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

Например, знает ли пользователь, как очистить кэш, или обновить Flash, или убедиться, что установлен JRE, или клонировать git-репозиторий? Знают ли пользователи, как открыть терминал, импортировать пакет, cd в командной строке или chmod права на файл?

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

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

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

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

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

Шаг 3: Тестирование инструкций на аудитории

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

Сотрудники из контроля качества смотрят, точны ли инструкции. Они не тестируют на то, поймёт ли пользователь инструкции, очевидны ли понятия. И члены команды контроля качества — плохие тестировщики, уже потому, что они уже знают систему слишком хорошо.

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

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

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

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

У меня не было редакторов годами. На самом деле единственный раз, когда у меня был редактор ­ на моей первой работе в должности технического писателя, где у нас была дюжина писателей. Но этот редактор был в основном сосредоточен на стиле.

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

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

Просьба коллегам проверить инструкции

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

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

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

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

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

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

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

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

Должны ли вы наблюдать?

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

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

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

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

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

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

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

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

Удовольствие от тестирования

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

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

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

Расчёт необходимого времени

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

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

Удачного тестирования!

Источник: The key to writing good documentation: Testing your instructions

Тэги: инструкции, качество контента, опыт, профессия, редактирование, советы, тестирование документации, Том Джонсон, целевая аудитория, ценность контента, эффективность

«Тестирование» руководства пользователя

2010/10/28, 10:48, Екатерина Саковская. b3et, разработка.

Тест-кейсы и чек-листы. Мы помним, что хорошее требование является проверяемым, а значит, должны существовать объективные способы определения того, верно ли реализовано требование. Продумывание чек-листов или даже полноценных тест-кейсов в процессе анализа требований позволяет нам определить, насколько требование проверяемо. Если вы можете быстро придумать несколько пунктов чек-листа, это ещё не признак того, что с требованием всё хорошо (например, оно может противоречить каким-то другим требованиям). Но если никаких идей по тестированию требования в голову не приходит — это тревожный знак. Рекомендуется для начала убедиться, что вы понимаете требование (в том числе прочесть соседние требования, задать вопросы коллегам и т.д.). Также можно пока отложить работу с данным конкретным требованием и вернуться к нему позднее — возможно, анализ других требований позволит вам лучше понять и это конкретное. Но если ничто не помогает — скорее всего, с требованием что-то не так. Справедливости ради надо отметить, что на начальном этапе проработки требований такие случаи встречаются очень часто — требования сформированы очень поверхностно, расплывчато и явно нуждаются в доработке, т.е. здесь нет необходимости проводить сложный анализ, чтобы констатировать непроверяемость требования. На стадии же, когда требования уже хорошо сформулированы и протестированы, вы можете продолжать использовать эту технику, совмещая разработку тест-кейсов и дополнительное тестирование требований.

• Что такое дизайн UI/UX
• Важность UI/UX
• Что такое юзабилити
• Что такое юзабилити-тестирование
• Что такое тестирование UI/UX
• Почему тестирование UI/UX очень важно
• На что обращают внимание в первую очередь
• Как эффективно тестировать юзабилити
  • Определение, что тестировать
  • Определение пользователей
  • Выбор метода
  • Запись сценариев
  • Анализ результатов и коррекция UI/UX
• Чеклист тестирования UX
• Чеклист тестирования UI
• Инструменты
• Автоматизация
• Сколько пользователей нужно?
• Советы

Что такое дизайн UI/UX

Дизайн UI (пользовательского интерфейса) — разработка вида/дизайна программного продукта; каждый экран, кнопка, страница, и все прочие визуальные компоненты, видимые на экране приложения/странице.

Дизайн UX (User Experience) — стратегия улучшения впечатлений пользователей посетителей от взаимодействия с продуктом.

Важность UI/UX

Приятный и удобный вид приложения/сайта и позитивные впечатления пользователей — генератор прибыли в бизнесе и средство привлечения новых пользователей. 

Что такое юзабилити

Юзабилити — это общая комфортабельность продукта, с точки зрения пользователя. Просто ли освоить продукт, научиться работать с ним? Как быстро пользователь/клиент получает то что ему нужно? Есть ли в приложении или на странице что-то, что его раздражает? Проще говоря, юзабилити — это «точка соединения» UI+UX.

Что такое юзабилити-тестирование

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

Что такое тестирование UI/UX

Это тестирование пользовательского интерфейса и пользовательских впечатлений в программных продуктах.

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

Тестирование UX оценивает, как продукт влияет на общее впечатление пользователя (то есть User Experience). Тестирование UX — это о комфорте пользователя. Такое тестирование включает все аспекты UX, от разметки и дизайна интерфейса до тонкостей подачи контента. Оно определяет проблемы с комфортабельностью, например меню, неудобные для навигации, некорректная или просроченная информация, или медленно реагирующие кнопки.

Почему тестирование UI/UX крайне важно

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

Позитивное впечатление пользователей — это то что привлекает пользователей и удерживает их.

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

На что обращают внимание в первую очередь

Доступность

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

Легкость восприятия

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

Скорость и производительность

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

Понятный интерфейс

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

Удобство навигации

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

Плавность

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

Также юзабилити-тестирование контролирует:

• Целостность, последовательность и логичность контента
• Совместимость
• Легкость освоения/обучения работе с продуктом
• Надежность, точность и практичность контента и навигации

Как эффективно тестировать юзабилити

1. Определить, что будет тестироваться

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

2. Знать своих пользователей/клиентов

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

3. Выбрать методы

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

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

Модерированное юзабилити-тестирование

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

Немодерированное тестирование

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

Удаленное тестирование

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

«Герилья»

Проводится в публичных местах, например кофешопах или парках. Такое тестирование позволяет быстро оценить продукты. Конечная цель: не «обозначить присутствие», то есть не рекламная, не улучшить узнаваемость/продажи бренда, а для прототипирования, то есть для проверки, как прототип приложения работает с реальными пользователями.

Интервью по телефону

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

Также могут быть дополнительные методы тестирования:

• Лабораторное тестирование
• Запрос по контесту
• Немодерированное удаленное тестирование
• Оценка экспертами по юзабилити
• Сравнительное тестирование (сравнение с конкурентами в нише)
• Исследовательское тестирование
• «Сортировка карт» — специфический тип тестирования юзабилити, при котором эксперты/пользователи сами пытаются сформировать лучший дизайн, с их точки зрения, из готовых карточек-блоков
• Трее-тестирование, в дополнение к предыдущему, для формирования удобной структуры меню
• Социологические опросы
• Запись пользовательских сеансов тестирования

4. Запись сценариев

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

5. Анализ результатов и коррекция UI/UX

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

Чек-лист тестирования UX

• Навигационные элементы везде, как в основном модуле (странице) так и в дополнительных (вложенных)
• Кликабельность кнопок наверху и в «подвале»
• «Продающие» CTA-элементы
• Редиректы и все ссылки
• Производительность и плавность
• Является ли приложение mobile-friendly, приспособленным к экрану смартфона
• Является ли контент читабельным и четким
• Все кликабельные элементы
• Проверить сообщения об ошибках / успешном выполнении операций
• Не допускать «нагромождения» элементов

Чек-лист тестирования UI

Чтобы проверить плавность взаимодействия пользователя с интерфейсом, предполагается чек-лист UI-тестирования:

• Элементы интерфейса — позиционирование, размер, длина и ширина всех UI-элементов
• Шрифты — размеры, интервалы и гарнитуры
• Иконки и цвета, их сочетания
• Поля пользовательского ввода
• Ввод в поля цифр, текста, специальных и невалидных символов
• Поведение UI-элементов на экранах разного размера
• Скроллинг (особенно в таблицах)
• Прогресс-бары
• Самые Главные Кнопки (Сохранить, Изменить, Удалить, Расшарить и т.п.)
• Выпадающие меню
• Предупреждения
• Шорткаты и элементы меню

Часто применяемые инструменты юзабилити-тестирования:

GTmetrix

Создание финальных отчетов по страницам, рекомендации по устранению проблем

Ссылка

Lool11

Мощная платформа пользовательского тестирования. Модерируемые и немодерируемые тесты на отдельных фреймворках

Ссылка

Optimizely

Задание условий, при которых растет прибыль, регистрации, загрузки, и потребление контента

Ссылка

Crazy Egg, Hotjar

Хитмапы, как пользователи работают с приложением

Ссылка на CrazyEgg, вот на Hotjar

BrowserShots

Инструмент семейства BrowserStack. Скриншоты сайта в разных браузерах и ОС, через онлайн-сервис

Ссылка

Maze

Инструмент прототипного тестирования UI/UX. Интеграция с инструментами дизайна типа Figma и Adobe XD

Ссылка

Zurb

Оценка, нравится ли пользователям дизайн сайта, что запомнилось

Ссылка

UXPunk

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

Ссылка

Автоматизация UI/UX

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

Например, можно автоматизировать ввод данных и анализ, пользуясь платформами для UX-тестирования и вспомогательными инструментами, получая более-менее надежные данные из приложений типа Hotjar или UserReport. Однако нельзя наблюдать в реальном времени за поведением реальных пользователей в любом из перечисленных инструментов. Поэтому в юзабилити принято ручное тестирование.

Сколько пользователей нужно?

Некоторые научные исследования говорят, что всего 5 пользователей достаточно, чтобы определить 80% проблем с юзабилити. Для небольших проектов этого достаточно; в зависимости от продукта, это число может быть больше на порядки.

Советы

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

< p>В этой статье мы узнаем, что такое пользовательское приемочное тестирование, а также следующее.

Что такое UAT-тестирование?< /h2>

UAT расшифровывается как User Aacceptance Ttesting.

Приемочное тестирование пользователей — это последний шаг в тестировании программного обеспечения, который проверяет, выполняет ли программное обеспечение первоначальные цели в соответствии с требованиями пользователя.

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

Это выполняется после оценки постоянного, системного и регрессионного тестирования .

Обычно UAT выполняется клиентом, а конечный пользователь проверяет, что требования были должным образом доведены до сведения и выполнены.

• Клиент — UAT выполняется заинтересованными сторонами программного обеспечения
• Конечные пользователи — UAT выполняется конечными пользователями программного обеспечения

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

Типы пользовательского приемочного тестирования< /h2>

Следующие типы пользовательского приемочного тестирования.

Альфа-тестирование:

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

Бета-тестирование:

Оно выполняется на стороне клиента реальными пользователями или заказчиками вне организации-разработчика.

Не пропустите более 100 типов тестирования программного обеспечения

Когда выполняется?

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

UAT — это наиболее решительная и эффективная процедура тестирования программного обеспечения, которая гарантирует, что разработанное программное обеспечение удовлетворяет всем требованиям, предъявляемым к выходу на рынок.

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

• Готовы ли пользователи использовать приложение?
• Будет ли приложение вести себя ожидаемым образом?
• Решит ли приложение проблемы пользователей ‘ проблема?

В настоящее время вы можете думать примерно так:

«Весь этот фактор UAT кажется жизненно важным, однако, может ли он нам действительно понадобиться? Я имею в виду, что у нас, как правило, уже реализованы различные типы тестирования… разве этого недостаточно?»

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

Зачем необходимо приемочное тестирование пользователей?

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

Даже тестировщики — это технические специалисты, которые следуют документам с требованиями и тестируют их.

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

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

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

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

Обзор процесса UAT:

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

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

< сильный>Критерии входа (предварительные условия) для тестирования UAT

Ниже приведены критерии входа для пользовательского приемочного тестирования:

• Должны быть доступны принятые бизнес-требования
• Полностью разработанное приложение
• Типы тестирования, такие как модульное, интеграционное и системное тестирование, должны быть завершены.
• Тестирование системной интеграции должно быть завершено без дефектов, дефектов высокой и средней степени серьезности.
• Регрессионное тестирование должно быть завершено без серьезных обнаруженных ошибок
• Косметика ошибки допустимы
• Все обнаруженные ошибки должны быть исправлены и протестированы
• Матрица отслеживания требований должна быть заполнена и обновлена
• Среда UAT с надлежащими тестовыми данными
• Письмо с подтверждением (подпись) от группы тестирования системы о том, что приложение готово к UAT

Как провести приемочное тестирование пользователя

Шаги в Внутренние процедуры универсального приемочного тестирования:

Планирование

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

Проектирование

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

Тестеры UAT

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

Исправление ошибок

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

Подписать

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

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

Критерии выхода (пост-реквизиты) пользовательского приемочного тестирования

Ниже приведены критерии выхода пользовательского приемочного тестирования:

• Нет ограничителей показа, открыты высокие и средние дефекты.
• Плавная работа бизнес-процесса
• Утверждение UAT на встрече с заинтересованными сторонами

Как мы может отличить UAT от других методов тестирования

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

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

UAT не является приемочным тестированием

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

UAT в основном выполняется вручную

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

Основные проблемы UAT

Основные проблемы, с которыми сталкиваются тестировщики UAT:

1. Первая задача состоит в том, чтобы определить, кто из команды будет участвовать в процессе UAT. Необходимо учитывать многие роли, такие как владелец UAT, спонсор проекта и команда UAT. UAT будет управлять всем процессом и принимать окончательные решения вместе с командой.
2. Тип тестирования (очное или индивидуальное) определяется путем определения местоположения членов команды и того, нужно ли вам несколько смен для теста или нет. Это может быть выполнено лично или дистанционно, или и то, и другое.
3. Процедура настройки и развертывания среды командой функционального тестирования программного обеспечения, безусловно, создаст реальные варианты использования. Некоторые виды тестирования, такие как тестирование производительности, нельзя выполнять в среде с неполными тестовыми данными. Для каждого из них необходимо установить отдельную производственную среду.
4. Всегда необходимо устанавливать заполнитель для стандартных временных рамок UAT, которые может ожидать организация.
5. Также сложно убедиться, что документация создается и поддерживается в весь проект.
6. UAT нельзя рассматривать как универсальное действие, поскольку у некоторых пользователей есть мотивация, навыки и время для проведения точного теста, а у некоторых нет.
7. Планы тестирования могут содержать ошибки, поэтому планы тестирования всегда должны проверяться группой обеспечения качества, руководителем проекта или любыми другими людьми, знакомыми с тестированием программного обеспечения.

Лучшее Практика

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

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

Вот некоторые инструменты UAT, доступные на рынке.

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

Watir: Watir — это бесплатный инструмент с открытым исходным кодом. Используются библиотеки Ruby для автоматизации веб-браузеров в процессе приемочных тестов пользователей.

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

Также узнайте:< /p>

• Подробное руководство по регрессионному тестированию
• Подробное руководство по тестированию блокчейна
• Полное руководство по тестированию API
• SDET — инженер-разработчик программного обеспечения в тестировании
• Карьерный переход от ручного к автоматизированному тестированию

TAG: qa

Что такое юзабилити-тестирование

Юзабилити-тестирование (usability testing) — это возможность посмотреть на интерфейс глазами пользователя и проверить удобство продукта. Тесты помогут определить:

• впечатление о продукте — что пользователь чувствует при первом использовании;
• прозрачность навигации — легко ли найти нужный раздел;
• доступность формулировок и качество контента — все ли понятно сформулировано и достаточно ли информации.

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

Виды и методы юзабилити-тестирования

Перед началом юзабилити-теста нужно выбрать тип тестирования. Он будет зависеть от стадии разработки и ваших ресурсов. Есть несколько критериев.

По целям

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

По наличию модератора

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

По местонахождению участников

• Очное. Участник и модератор взаимодействуют напрямую и находятся в одном помещении.
• Удаленное. Человек тестирует продукт, находясь в удобном для себя месте, общение с модератором проходит по видеосвязи.

Также тестирование бывает качественным и количественным:

• Качественное. Участвуют 6–8 человек на каждый сегмент аудитории. Главная цель — выявить проблемы и выяснить причины, оценить потребности посетителей сайта, найти способы удовлетворения этих потребностей. 

Количественное. Участвуют от 50 человек. Главная цель — проверить, насколько часто люди сталкиваются с проблемами при использовании интерфейса и что потом может доработать UX-дизайнер. Здесь будет трудно получить ответы на вопросы «почему», «как именно», зато удастся узнать, насколько сами проблемы критичны, часто ли встречаются.

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

Основные методы юзабилити-тестирования — это:

• лабораторное тестирование. Респонденты получают сценарий и выполняют задания под наблюдением модератора;
• глубинное интервью. Людям, которые уже пользовались продуктом, задают вопросы, чтобы понять, какое впечатление у них осталось от приложения или сайта;
• фокус-группы. Группе из 3–10 респондентов предлагают обсудить будущий продукт;
• тепловая карта. Показывает, какие элементы на экране привлекают больше всего внимания;
• А/Б-тестирование. Помогает сравнить две версии приложения, сервиса или сайта, отличающиеся несколькими элементами. Аудиторию разбивают на сегменты, каждому показывают какую-то одну версию.

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

Как проводить юзабилити-тестирование в лаборатории

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

1. Сценарий. По шагам расписываем задания для респондентов и дополнительные вопросы. 
2. Гипотезы. Выдвигаем предположения, чтобы в ходе исследования подтвердить или опровергнуть их.
3. Метрики. Например, время, успешность выполнения задания, удовлетворенность участника.

Для тестирования потребуется 8–12 респондентов. Это могут быть клиенты компании или представители целевой аудитории. Не стоит звать знакомых и друзей, потому что они могут быть не до конца честными, чтобы вас не обидеть. А вот людей из категории «знакомые знакомых» можно пригласить. Чтобы точно пришли представители вашей аудитории, обрисуйте знакомым и друзьям портрет ЦА, и они кого-нибудь посоветуют.

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

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

На лабораторное тестирование удобства пользования уходит приблизительно 1,5 часа. 1 час занимает сама процедура, 15 минут требуется на инструктаж и столько же — на выводы. Не стоит затягивать тестирование. Люди устают, будут делать ошибки или слишком формально относиться к поставленным задачам. И это скажется на итоговом качестве результатов.

Как подготовить задание для теста

К примеру, начинающий UX/UI-дизайнер хочет проверить юзабилити сервиса по доставке еды. 

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

Сфокусированное задание

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

Но если предлагать только это задание, картина будет неполной по нескольким причинам:

• Точечная проверка интерфейса. Если в сервисе есть другие недочеты, респонденты их не найдут, так как у них нет такой задачи.
• Маленькая выборка инсайтов. Возможно, если человеку на самом деле надо заказать еду, он подошел бы к выбору по-другому: не стал бы ограничивать общую сумму и обращал внимание на другие параметры (качество, свежесть, производитель). Четкая задача при тестировании сужает круг поиска ошибок.
• Нет вовлечения. Респонденты могут выполнить задачу формально: найдут первые попавшиеся блюда, которые отвечают установленным критериям, и завершат работу. При этом в обычной жизни человек может заказывать совершенно другие продукты в таком же сервисе. Поэтому лучше максимально приближать задание к настоящей жизни исполнителя.

Задача с контекстом

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

Задача с учетом опыта пользователей

В этом случае важны:

• параметры участников. Например, уточняем, как человек на самом деле выбирает продукты в сервисе доставки. Что покупает и как определяет, что продукт подходит. Может быть, он ориентируется на цену, производителя или рекламу;
• сценарии участников. То, как человек заказывает еду в онлайн-сервисе в обычной жизни: смотрит промокоды, выбирает товары со скидками, переходит в конкретные категории каждый раз. Тогда нужно попросить его воспроизвести свой стандартный алгоритм.

Задания без заданий

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

Модератор может выйти из комнаты, чтобы оставить человека наедине с приложением и не отвлекать. Человек должен найти все ответы без подсказок. В самостоятельном поиске и есть суть теста. Например, нужно ли регистрироваться или где найти личный кабинет.

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

Итак, вот основные советы, как подготовить понятное респондентам задание:

1. Сделайте первое задание максимально простым. Это поможет участникам влиться в формат и привыкнуть к модератору.
2. Формулируйте задания без подсказок. Респондент сам должен понять, как его выполнить, иначе тестирование потеряет смысл. 
3. Не используйте термины, которые описывают интерфейс продукта. Они могут быть непонятны простым пользователям.
4. Позаботьтесь о тайминге. Если нужно выполнить много заданий, расставьте приоритеты. Не старайтесь в один тест вместить слишком много задач. Люди устанут, результаты не будут корректными.
5. Проверьте, соответствуют ли задачи гипотезам. Например, если нужно протестировать подписку на новости, не просите в задании делать это напрямую. Важно, заметит ли респондент эту возможность самостоятельно.

Метрики юзабилити

Стандартные характеристики юзабилити любого продукта: эффективность, продуктивность, удовлетворенность. 

Например, какие конкретно могут быть метрики:

Успешность выполнения задач. Оцениваем либо по принципу «справился или нет», либо по методу Нильсена:

• 100% — справился с задачей почти без проблем;
• 50% — были трудности, но человек решил задачу;
• 0% — человек не выполнил задание.

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

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

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

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

Наблюдение

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

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

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

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

Анализ результатов юзабилити-тестов

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

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

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

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

Найденные проблемы или ошибки классифицируем:

• Критические. Допустим, не функционирует кнопка. Если ее не починить, пользовательский сценарий невозможно пройти, а значит, человек не может зарегистрироваться или совершить покупку.
• Серьезные. Например, выдача в поиске занимает слишком много времени. Пользователи могут сдаться, не пройти от начала и до конца задуманный сценарий. Кто-то выбирает закрыть приложение и искать в другом месте.
• Минорные. Предположим, человеку приходится несколько секунд ждать загрузку результатов. Это вызывает раздражение, но не мешает завершать пользовательский сценарий. Человек не уйдет, так как потратил уже какое-то время, но впечатление от сервиса испорчено.

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

Онлайн-сервисы для анализа юзабилити 

Для исследования юзабилити интерфейса можно воспользоваться платными или бесплатными сервисами. 

Яндекс.Метрика

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

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

Optimal Workshop

Сервис предоставляет три инструмента:

• Optimalsort — перестраивает структуру сайта благодаря сортировке карточек.
• Treejack — анализирует многоуровневую информационную архитектуру веб-ресурса на основе данных, загруженных в таблицу.
• Calkmark — оценивает юзабилити страниц по скриншотам, выдает тепловую карту кликов, отмечает среднее время выполнения каждой операции.

Участников для тестирования нужно искать самостоятельно.

UsabilityHub

Предлагает три инструмента:

• Navflow — помогает выяснить, насколько человеку комфортно ориентироваться по странице.
• Fivesecondtest — выявляет элементы, которые наиболее привлекательны для посетителей сайта.
• ClickTest — формирует карту кликов, которая показывает те области веб-страницы, где люди больше всего выполняют какие-либо действия.

Анализируем приложение так:

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

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

Usabilla

Работаем в несколько этапов:

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

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

Feng-GUI

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

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

Итоги

1. Тестируйте прототип на этапе разработки. Тогда в готовом продукте не придется делать существенных правок, которые увеличат бюджет.
2. Выбирайте релевантную аудиторию. Тестировать продукт стоит на тех, кто действительно может им пользоваться, а не на случайных людях, родственниках или знакомых. 
3. Задавайте вопросы, которые предполагают развернутый ответ, и не давайте подсказок.
4. Фиксируйте замечания респондентов и обращайте внимания на эмоции. 
5. Проводите несколько тестов в ходе разработки, делайте промежуточные выводы и дорабатывайте элементы интерфейса.
6. Обязательно тестируйте готовый продукт и прислушивайтесь к обратной связи от пользователей.