Планирование юзабилити-тестирования. Часть 2
Привет, Хабр, с вами снова Наталия Спрогис, руководитель направления UX-исследований в Mail.Ru Group! Это вторая часть статьи о планировании юзабилити-тестирования. В первой я рассказывала о формулировке целей и гипотез, выборе метода тестирования и инструментов фиксации данных, а также об организационных моментах для исследователя. Эта часть посвящена составлению протокола (сценария) тестирования: продумыванию того, какие задания вы дадите респонденту, какие вопросы будете задавать, какие опросники предложите заполнить.
Протокол любого юзабилити-тестирования состоит из следующих частей:
- Инструктаж/брифинг (приветствие, описание мероприятия, подписание документов)
- Вводное интервью (проверка скрининга, небольшое интервью об использовании продукта, контексте и сценариях)
- Работа с продуктом (задания тестирования)
- Сбор итоговых впечатлений от продукта на основании опыта тестирования
Инструктаж/брифинг
Независимо от предмета тестирования, любое исследование начинается одинаково. Нужно:
- Создать атмосферу. Познакомьтесь с человеком, предложите ему чай, кофе или воду, покажите, где туалет. Постарайтесь немного расслабить респондента, ведь он может нервничать перед мероприятием. Узнайте, легко ли было вас найти, спросите, как настроение.
- Описать процесс. Расскажите, что за мероприятие ждёт респондента, сколько времени оно займёт, из каких частей оно состоит, что вы будете делать. Обязательно обратите внимание респондента на то, что его вклад поможет улучшить продукт и что вы не тестируете способности человека. Если вы ведёте видеозапись, предупредите об этом респондента и успокойте его, что данные не появятся в Сети. Я говорю примерно следующее:
«Мы находимся в офисе компании Mail.Ru Group. Сегодня мы поговорим о проекте ХХХ. Это займёт около часа. Сначала мы немного побеседуем, потом я попрошу вас что-то попробовать сделать в самом проекте, а после мы обсудим ваши впечатления. Мы будем вести видеозапись того, что происходит в комнате и на экране компьютера. Запись нужна исключительно для анализа, в интернете вы себя не увидите. Мы проводим исследование, чтобы сделать проект ХХХ лучше, понять, что в нём нужно исправить и в какую сторону ему развиваться. Поэтому очень прошу вас открыто высказывать любые комментарии, и положительные, и отрицательные. Не бойтесь нас обидеть. Если при изучении проекта у вас что-то не получится, относитесь к этому спокойно. Значит, мы с вами нашли проблему, которую команде проекта нужно исправить. Самое главное — помните: мы не тестируем вас, это вы тестируете продукт. Если вы готовы, предлагаю начинать». - Подписать документы. Как правило, это согласие на обработку персональных данных, а иногда — соглашение о неразглашении информации о тестировании. Для тестов с несовершеннолетними необходимо согласие родителей на участие ребёнка в исследовании. Обычно мы высылаем его родителям заранее и просим принести его с собой. Обязательно объясните, зачем вы просите подписать документы, и дайте время изучить их. В России люди с опаской относятся к любым бумагам, которые требуется подписать.
- Настроить оборудование. Если вы используете айтрекинг, биометрическое оборудование или просто ведёте видеозапись, самое время всё это включить. Предупредите респондента, когда начнёте запись.
Вводное интервью
Оно решает следующие задачи:
- Проверить рекрутинг. На всякий случай всегда начинайте с этого — даже если вы доверяете агентству или человеку, который нашёл респондента. Не раз уже на тесте мы выясняли, что респондент неправильно понял вопросы и на самом деле пользуется продуктом не совсем так, как нам нужно. Старайтесь отойти от формальности и не задавать вопросы из скринингового опросника: человек может уже знать, что отвечать на них.
- Сценарии и контекст использования продукта. Даже если у вас мало времени на тест, не пропускайте этот пункт. Хотя бы в целом узнайте у респондента, какие задачи он решает при помощи продукта, пользуется ли аналогичными проектами, в каких условиях взаимодействует с ними и с каких устройств. Знание особенностей использования продукта поможет вам лучше понимать причины поведения респондента. А если вы применяете гибкий сценарий — то и формулировать подходящие задания. Если хватает времени, попросите респондента показать, что и как он обычно делает. Это бывает источником дальнейших вопросов и инсайтов.
- Ожидания и отношения. Начало тестирования — хорошее время узнать, что респондент знает о продукте, как относится к нему и чего от него ожидает. После теста вы сможете сравнить ожидания с итоговым впечатлением.
Для большинства тестов подойдёт такая структура вводного интервью. Однако если вы тестируете новый продукт, возможно, стоит пропустить вводные вопросы. Если вы слишком подробно начнёте обсуждать какую-то тему, это может создать у пользователя определённые ожидания от продукта. Поэтому оставьте только пару самых общих вопросов, чтобы наладить контакт с респондентом, и сразу же переходите к заданиям. Обсуждать сценарии, отношения и контекст в этом случае лучше после того, как пользователь первично изучит продукт. Работа с продуктом, составление заданий
Какие бывают задания
Давайте представим, что вы хотите протестировать интернет-магазин. У вас есть важные сценарии (поиск и выбор товара, процесс оформления заказа), известные проблемы (частые ошибки в форме оплаты) и даже гипотеза, что дизайнер что-то намудрил с фильтром по цене. Как же сформулировать задания?
Сфокусированные задания. Очевидным кажется сделать примерно такое задание:
«Выберите посудомоечную машину шириной 45 сантиметров с функцией «луч на полу» стоимостью не более 30 тысяч рублей».
Это мотивирует респондента пользоваться фильтрами и сравнивать товары между собой. Вы сможете проверить фильтр по цене на всех респондентах и посмотреть на ключевой сценарий подбора товара. Подобные задания вполне имеют право на жизнь и хороши для проверки конкретных гипотез (как с фильтром по цене). Однако если весь тест будет состоять из них, то вы рискуете следующим:
- Точечная проверка интерфейса. Вы найдёте только проблемы, связанные с деталями задания (фильтр по цене и ширине). Вы не увидите прочих проблем, например сортировки товаров или других фильтров, если не укажете и на них. А сделать задания для всех элементов сайта вы вряд ли сможете.
- Отсутствие вовлечения. Подобные задания пользователи часто выполняют механически. Увидев первый товар, подходящий под критерии, они останавливаются. Возможно, в жизни респондент никогда не выбирал посудомойки и ему всё равно, что такое «луч на полу». Чем больше задание походит на ситуацию из реальной жизни, чем больше в нём понятного пользователю контекста, тем выше шансы вовлечь респондента, который представит, что на самом деле выбирает товар. А вовлечённый пользователь лучше «проживает интерфейс», оставляет больше комментариев, повышаются его шансы найти проблемы и дать полезные знания о поведении и особенностях аудитории.
- Суженный спектр инсайтов. В реальной жизни пользователь бы, возможно, подбирал товар совсем не так. Например, вообще не пользуясь фильтрами (а тут вы на них указали). Или искал бы товар по критериям, которых нет на сайте. Давая жёсткие, сфокусированные задания, вы не узнаете о реальном контексте использования продукта, не найдёте сценариев, которые команда проекта, возможно, не предусмотрела, не соберёте данные о потребностях в контенте и функционале.
Задания с контекстом. Один из способов лучше вовлечь пользователей — добавить в сухое задание реальную историю и контекст. Например, вместо «Найдите рецепт пирога со сливами» на сайте с рецептами предложите следующее:
«Через час к вам придут гости. Найдите, что можно испечь за это время. У вас в холодильнике есть всё для бисквита, а также немножко слив. Но, к сожалению, нет сливочного масла».
Подобный подход можно использовать и с интернет-магазином. Например: «Представьте, что вы выбираете подарок сестре. У неё недавно сломался фен, и она была бы рада получить новый. Вам нужно уложиться в 7 тысяч рублей». Важно, чтобы респондент действительно выбрал реального человека, которому будет «покупаться» подарок (если нет сестры, предложите другого родственника или подругу). Ключевое для подобных заданий — реальность и понятность контекста. Легко представить, что ты выбираешь подарок родным, куда труднее — что ты «бухгалтер, составляющий годовой отчёт».
Яркий пример такого подхода — «метод Болливуда», который придумала индийский UX-эксперт Апала Лахири Чаван (Apala Lahiri Chavan). Она утверждает, что индусам, как и многим азиатам, сложно открыто высказывать своё мнение об интерфейсе. Зато, представляя себя героями вымышленных драматических ситуаций (как в любимых ими фильмах), они раскрываются и начинают живо участвовать в тестировании. Поэтому задания для индусов должны выглядеть примерно так:
«Представьте, что ваша любимая юная племянница собирается замуж. И тут вы узнаёте, что будущий муж — мошенник, да ещё и женатый! Вам нужно срочно купить два билета на рейс до Бангалора для себя и жены обманщика, чтобы расстроить свадьбу и спасти семью от позора. Торопитесь!»
Задания с опорой на опыт респондентов. Напомним: для успешного тестирования респонденты должны соответствовать аудитории проекта. Поэтому для проверки интернет-магазина бытовой техники мы рекрутируем тех, кто недавно выбирал технику или выбирает её сейчас. Именно этим мы будем пользоваться, составляя задания с опорой на опыт респондентов. Есть два варианта использования такого подхода:
- Параметры респондентов. В этом случае вы адаптируете фиксированные задания под респондентов. Например, для случая с магазином бытовой техники и задачи на работу с фильтрами уточняете у человека, что именно он недавно приобрёл. Узнаёте критерии (цена, функции и т. д.) и предлагаете повторить «покупку» на вашем сайте.
- Сценарии респондентов. Задания полностью формируются с опорой на опыт участников. Чтобы понять, какие сценарии проверить, модератор выясняет, как именно человек решал задачу в жизни, и предлагает сделать это на сайте. Например, покупатель долго сравнивал между собой несколько моделей перед выбором. Даже если на сайте нет подходящей функции, предложите респонденту сравнить товары, чтобы понять, на какие параметры он станет опираться. Возможно, вы получите идеи, как должна выглядеть функция сравнения, а также адаптируете под этот сценарий страницу товара.
Подобные задания дают много реальных примеров выполнения базовых операций в продукте. Это часто порождает гораздо больший спектр проблем и находок. Кроме того, позволяет проверить продукт на новых сценариях, которые вы не считали основными или даже не продумывали. Например, когда мы тестировали проект Недвижимость Mail.Ru, именно задания с опорой на опыт респондентов помогли нам сделать много открытий. Так, мы увидели, что люди при поиске квартиры в Подмосковье указывают в геофильтре конечные станции метро, имея в виду, что это станции, до которых можно доехать из области. Мы же рассчитывали, что фильтр по метро ищет квартиру недалеко от станции. Также мы узнали, чем отличаются сценарии поиска новостроек от вторички, что помогло позже вынести поиск новостроек в другой раздел на сайте — со своими фильтрами и своей концепцией описания квартир.
Советую также прочитать отличную статью Джареда Спула о пользе подобных заданий.
Задания без заданий. Иногда лучше вообще не предлагать пользователям задания на работу с проектом, а посмотреть, с чего они сами начнут знакомство с продуктом. Дайте респонденту вводную: «Представьте, что вы решили попробовать этот продукт. Я оставлю вас на несколько минут. Делайте то, что вы стали бы делать в реальной жизни. Я не даю вам никаких заданий».
Важно, чтобы модератор при этом выходил из комнаты. В противном случае у пользователя появляется соблазн сразу же что-то спросить, уточнить: «А надо ли регистрироваться? А как вот это сделать?» и т. д.
Данный тип заданий полезен для полностью новых продуктов. Мы часто применяем его для мобильных приложений и игр. Так, мы видим, читают ли пользователи обучающие материалы, какие детали сразу привлекают внимание, что люди понимают в концепции продукта, как потом описывают его возможности. Уже после свободного задания идут запланированные конкретные сценарии.
Ещё одна область применения свободных заданий — контентные проекты. Если вы хотите понять, как читают ваши статьи, где надолго задерживаются, что пропускают, на какие элементы на странице обращают внимание и пр., то просто оставьте респондента на несколько минут наедине с проектом. Только без модератора, смотрящего через плечо, пользователь расслабится и будет читать текст так же, как обычно, в реальной жизни. Так мы тестируем проекты Новости Mail.Ru, Леди Mail.Ru и др. Этот подход позволил выделить разные модели поведения на сайте, разные паттерны чтения статей и понять, какие типы материалов стоит оформлять по-другому.
Составляем хорошие задания
Первое задание — простое. Начинайте тестирование с ознакомительных и несложных заданий. Респондент должен освоиться с форматом тестирования, особенно если вы используете метод «мысли вслух»: на первом задании человеку нужно привыкнуть к необходимости озвучивать свои мысли и чувства. Не стоит сразу вываливать на него всю боль и страдания интерфейса.
Не подсказывайте. Сформулируйте задания так, чтобы не подсказывать правильных действий респонденту. Например, если вы хотите протестировать возможность добавления в избранное товаров в интернет-магазине, обойдитесь без задания «Давайте добавим вот этот телевизор в избранное», особенно если кнопка так и называется. Респондент, прочитав задание, будет просто находить кнопку с нужной подписью на экране, возможно даже не понимая, что именно он делает. Лучше объяснить смысл задания, не прибегая к терминам в интерфейсе. Например: «На сайте есть возможность сохранить понравившиеся товары и потом выбрать, что из них заказать. Давайте попробуем сделать это с таким-то телевизором».
Следите за терминологией. Не используйте непонятные слова и обозначения. Это кажется очевидным, но мы часто, привыкнув к каким-то терминам, забываем, что их мало кто знает за пределами IT-тусовки. Например, при тестировании нового функционала тредов (цепочек писем) в Почте Mail.Ru нам пришлось достаточно сложно. Ведь у пользователей, незнакомых с подобным функционалом, просто нет в голове термина, который бы обозначал треды. В итоге мы никак их не называли. Мы просто показывали респондентам ящик с подключёнными цепочками и обсуждали эту новую возможность. В рамках обсуждения давали пользователям самим подобрать слово для обозначения тредов. Это помогло нам позже использовать наиболее понятные тексты в обучающих промоматериалах. Следите не только за заданиями, но и за вопросами модератора, особенно за теми, которые приходят от команды во время тестирования. Не стоит, например, использовать слово «тулбар» при обсуждении функций: оно не всем знакомо. Ещё несколько лет назад даже слово «браузер» знали далеко не все пользователи. То, как именно лучше сформулировать задания, зависит от аудитории тестирования. Не стоит кидаться и в обратную крайность, объясняя все термины подряд. Например, опытным игрокам не надо растолковывать, что такое «баф», «фраг», «респаун» и пр.
Меньше тестового. Часто очень велик соблазн сделать респонденту тестовый аккаунт в системе и проводить тестирование на нём. Ведь можно заранее всё обкатать в этом аккаунте, избежать накладок и не тратить время на регистрацию или авторизацию респондента. Часто ещё и технически гораздо легче включить новый дизайн на тестовых, а не на реальных данных. Однако при таком подходе вы рискуете получить гораздо меньше полезных результатов. Ведь у тестовых действий нет реальных последствий. Ситуация становится совсем искусственной, пользователям сложно проецировать её на реальный опыт. Например, при работе в собственном аккаунте в соцсети респонденты, как и в реальной жизни, будут аккуратно делать всё, что могут увидеть их друзья (публиковать ссылки, отправлять сообщения). При настройках собственного ящика в почте — стараться не удалить важные письма. При тестировании интернет-магазинов иногда применяют подход, когда вознаграждение нужно потратить прямо на тесте. В таком случае респондент не ткнёт в первый подходящий по заданию товар, а подберёт то, что ему на самом деле нужно.
Плюс, имея одни лишь тестовые данные, вы найдёте проблемы, связанные только с ними, а не проверите функционал на разных вариациях. Например, когда мы тестировали социальную панель браузера Амиго, один из респондентов, подключивший в панель свой аккаунт «ВКонтакте», сразу отметил, что так читать ему неудобно. Почти вся лента состояла из подписок на группы с эротическими фотографиями. А в узкой панели на картинках было просто ничего не разглядеть.
Ещё одна проблема тестовых данных — сложно разобраться в системе, так как всё вокруг непривычное. Например, пользователь соцсети привык узнавать свою страницу по собственной фотографии. Даже тестируя прототипы, мы стараемся максимально персонализировать их. Например, при тестировании кликабельных прототипов в «Одноклассниках» мы всегда адаптируем их для каждого пользователя, вставляя на страницу его имя и фотографию, а иногда и последние новости.
Не ограничивайтесь только интерфейсом. Не забывайте о том, что взаимодействие с продуктом часто не ограничивается одним лишь интерфейсом. Если есть возможность, тестируйте сопутствующие продукты или сервисы и связи между ними. Например, при тестировании игр мы стараемся проверить не только игру, но и её сайт и связанные с ним загрузку, регистрацию в игре, поиск информации на форуме. А при тестировании одного интернет-магазина я также проверяла звонок оператора после оформления заказа, что дало рекомендации для колл-центра.
Думайте о тайминге. Для хорошего сценария важно расставлять приоритеты задач. Скорее всего, если система большая и целей у теста много, вам захочется сделать очень много заданий. Однако уставший респондент уже не будет полезен. Хороший тест длится не больше полутора часов, два — это максимум. Исключение разве что игры. И помните, что ваши цели — не только задания, но и интервью, опросники, настройка оборудования и подписание документов. Всё это обычно занимает не менее получаса. Если заданий слишком много, а отказаться от каких-то очень не хочется, можете наименее приоритетные пустить в ротацию, т. е. показывать только части респондентов. Или сделать часть теста обязательной для всех, а остальное смотреть только с теми, с кем хватит времени. Но это, скорее всего, будут наиболее успешные респонденты.
Оценивайте полезность задания. Подумайте, действительно ли оно соответствует вашим гипотезам. Например, вы хотите проверить функцию подписки на новости на сайте. Задание «Подпишитесь на новостную рассылку» позволит проверить только то, смогут ли найти рассылку те, кто будет её искать. Однако мы понимаем, что люди редко приходят на сайт, чтобы подписаться на новости. Задание не относится к реальной жизни. Вам же нужно понять, замечают ли возможность подписки те, кто выполняет совсем другие задачи. Проверять это можно разными способами — в зависимости от реализации функции. Если человек занимался заданиями, в которых ему на глаза могла попасть возможность подписки, спросите его, есть ли она на сайте. Только обязательно уточните, где он видел эту возможность или как она реализована, чтобы удостовериться, что респондент не просто с вами соглашается. Если предложение подписки встроено в процесс регистрации или оформления заказа, посмотрите, воспользуется ли им респондент, а после задания обсудите это. Очень мало шансов, что в лабораторных условиях люди реально подпишутся на рассылки, но можно проверить, обратил ли человек внимание на такую возможность, чего он ожидает от рассылки и т. п.
Сбор итоговых впечатлений
Цель заключительной фазы тестирования — собрать впечатления от работы с продуктом, понять, что понравилось пользователю, а что его расстроило, оценить субъективную удовлетворённость. Как правило, в этой части теста используется сочетание интервью с модератором и заполнения формальных опросников.
Интервью с модератором
В итоговом интервью мы всегда задаём респондентам примерно одни и те же вопросы: «Какие впечатления остались?», «Что понравилось, а что нет?», «Было ли что-то, что показалось сложным или неудобным?», «Чего не хватало?», «Что хотелось бы изменить в продукте?» и т. п. Самое время уточнить непонятные моменты поведения респондента, если вы не сделали этого в процессе теста. А если вы узнавали у пользователей отношение к бренду или продукту и ожидания от него до теста — выясните, изменилось ли что-нибудь. При интервью обращайте внимание на следующее:
- Социальная желательность. Обращайтесь с результатами интервью очень аккуратно. Если во время теста вы часто слышите импульсивные комментарии под влиянием проблем, то в финальном интервью вовсю расцветает социальная желательность. Одним кажется, что, говоря о проблемах в продукте, они признаются в собственной некомпетентности. Другие просто не хотят расстраивать приятного в общении модератора. Очень часто респонденты (особенно женщины), которые промучились весь тест, говорят, что всё, в принципе, нормально. Отрицательные отзывы также могут быть продиктованы социальной желательностью: если респондент уверен, что цель теста — найти недостатки, он старательно пытается их отыскать.
- Цитаты и приоритеты. Несмотря на то что все слова участников теста в финальном интервью часто нужно делить на два, а то и на десять, это не значит, что они бесполезны. По тому, как именно респонденты подытоживают впечатления, вы можете сделать вывод о приоритетах. Продукт — «полный отстой»? Что именно повлияло на это? Какую из многих проблем респондент запомнил больше всего и считает самой раздражающей? Однако делайте скидку на то, что лучше всего запоминается последнее задание. Также очень полезно отслеживать, какими прилагательными описывают продукт респонденты в разговоре, с чем сравнивают свой опыт.
- Не забываем о хорошем. Очень часто отчёт о юзабилити-тестировании — это длинный перечень найденных во время теста проблем. В общем-то, поиск проблем — одна из основных задач. Однако, пожалуйста, не забывайте и о положительных сторонах продукта. Потому что, во-первых, отчёт без положительных результатов просто демотивирует команду. А во-вторых, полезно знать, что пользователям в продукте нравится. Вдруг при следующем редизайне решат убрать функцию, которая так всем приглянулась. Поэтому обязательно спрашивайте у респондентов о положительных сторонах продукта, даже если они ругали интерфейс в течение всего тестирования.
- Отношение к «хотелкам». Скорее всего, помимо своих впечатлений, респонденты будут также высказывать пожелания и идеи. Ваша задача — понять, какая проблема стоит за предложениями. Потому что решения, которые предложат пользователи, с высокой вероятностью вам не подойдут. Ведь участники тестирования — не дизайнеры, они не в курсе особенностей и ограничений разработки. Тем не менее за любым подобным запросом стоит потребность, которую вы должны зафиксировать. Если респондент говорит, что ему вот здесь непременно нужна большая зелёная кнопка, обязательно спросите —, а зачем?
Мера удовлетворённости
Часто по словам респондента в финальном интервью сложно понять, понравился ему в итоге продукт или нет. А уж тем более трудно сравнить отношение нескольких респондентов, которые и плюсы отмечали, и недостатки находили. Тут на помощь исследователю приходят опросники. Во-первых, при заполнении опросника (особенно до разговора с модератором) чуть меньше влияние пресловутой социальной желательности, хотя полностью вы от него не избавитесь. Во-вторых, опросник даёт вам чёткие параметры, позволяющие сравнивать сценарии, продукты или стадии проекта.
Составление хорошего опросника — это отдельная и очень большая тема. Тут важны и формулировки, и шкалы, и многое другое. Поэтому хорошим подспорьем могут стать готовые и проверенные опросники. Они уже отточены и многократно протестированы. Проблема только в том, что почти у всех этих анкет нет официальных переводов на русский. Естественно, вы можете перевести их самостоятельно, но с методологической точки зрения переводы нужно протестировать, чтобы проверить корректность формулировок. Тем не менее анкеты могут стать ориентиром при составлении собственных опросников.
Есть опросники, которые даются после каждого задания, чтобы оценить удовлетворённость от конкретных сценариев. Например:
- After Scenario Questionnaire (ASQ). Три вопроса о сложности, продуктивности и подсказках в системе.
- Single Ease Question (SEQ). Один вопрос о сложности сценария.
А есть анкеты, которые применяются уже в заключительной фазе тестирования. Вот несколько примеров, которые мы используем при необходимости:
- System Usability Scale (SUS) и Post-Study System Usability Questionnaire (PSSUQ). Два классических и популярных опросника, созданных более 20 лет назад. Оба состоят из утверждений. Респонденты должны указать степень согласия с ними. Все эти утверждения с разных сторон характеризуют юзабилити продукта. Например: «Я легко мог найти нужную информацию», «Разные возможности системы легко доступны» и т. д.
- Microsoft Desirability Toolkit. Опросник, который часто помогает нам на тестах. Пользователю предоставляется набор прилагательных, из которых он выбирает те, что, на его взгляд, могут характеризовать продукт. В итоге вы получаете облако слов — характеристик вашего проекта. Часто эта методика приносит очень интересные результаты.
- Game Experience Questionnaire. К играм нельзя применять классические юзабилити-опросники: вовлечённость в игровой процесс гораздо важнее, чем понятность интерфейсов. Поэтому для игр нужно всегда составлять особые опросники или пользоваться GEQ. Опросник содержит несколько модулей: базовый модуль, внутриигровой блок, постопросник и опросник социальных возможностей игры.
Вы можете воспользоваться предложенными анкетами или создать свои опросники, актуальные для вашего продукта.Заключение
Хорошее планирование позволит вам провести исследование, точно отвечающее целям заказчика и максимально полезное для проектной команды. Также грамотный план сокращает время подготовки отчёта. Однако, как бы хорошо вы ни подготовились, обязательно проведите пилотный тест на ком-нибудь из коллег или знакомых. Это позволит избежать казусов с неправильно настроенным оборудованием, покажет, укладываетесь ли вы в тайминг, понятны ли тексты заданий и нет ли опечаток в опросах.
