Процедура тестирования
По сути, тестирование – это симулятор. Моделирование использования продукта в более или менее безопасных условиях. Задача тестирования – получить чёткий ответ от пользователей на вопрос прототипа. Прототип – это подготовка к ответу, тестирование – ответ. Просто ответ «мне понравилось» или «мне не понравилось» не имеет смысла. Тестирование нужно для того, чтобы исправить конкретные ошибки.
Кроме основного вопроса, вы можете постараться найти ответы и на дополнительные. Например:
• хотят ли игроки проходить игру несколько раз?
• в какой момент они испытывают скуку или не понимают, что происходит?
• как быстро они понимают, что от них требуется?
• какая часть показалась им самой интересной, а какая – самой нудной?
Как видите, все эти вопросы – ситуативные, и идеальная ситуация – если вы сами присутствуете на тестировании и можете это видеть воочию. Поверьте, есть очень мало более полезных вещей при проектировании игрофицированной системы, чем возможность посмотреть на будущих игроков, когда они тестируют систему. Если вы видите, как игрок хмурится или отвлекается, это может быть очень полезной обратной связью – сигналом, что надо что-то менять.
Наверное, самое лучшее, что может произойти, – это если игрок найдёт какую-то стратегию, о которой вы не задумывались, или сможет взломать систему. Это значит, что у вас есть возможность использовать эту стратегию или исправить баг, пока это не обнаружили сотни или даже тысячи игроков.
Если вы находитесь на тестировании лично, вас подстерегает большая опасность. Вы можете ненамеренно или даже специально – из лучших побуждений направить игрока в нужное вам русло. Постарайтесь этого не делать – после того как система будет запущена для пользователей, вы не сможете стоять за спиной у каждого и давать подсказки. Лучше соберите статистику самых сложных мест и подготовьте для них подсказки, чтобы можно было разобраться без участия фасилитатора. Понятность этой подсказки для игроков лучше отследить во время следующего теста.
Кроме пассивного наблюдения за респондентом, есть ещё один способ тестирования – размышления вслух. Во время такого тестирования игрока просят устно комментировать свои действия в стиле «я нажимаю на зелёный квадратик и вижу новый экран, в левом нижнем углу сидит кролик, попробую кликнуть по нему мышкой» и т. д. Такой метод довольно часто используется при тестировании игр. Мы не слышали, чтобы кто-нибудь занимался тестированием игрофицированных систем таким образом, и сами пока пробовали этот формат слишком небольшое количество раз, чтобы дать какие-то чёткие рекомендации. Одно можно отметить точно – это очень информативный формат тестирования, хотя у него и есть две проблемы. Во-первых, довольно сложно найти человека, которому будет комфортно так использовать ваш продукт. Во-вторых, в самых сложных моментах тестировщики имеют обыкновение замолкать – им нужно сосредоточиться на самом процессе, комментирование им мешает [9].
Как уже было сказано, тестирование – это, по сути, симуляция со всеми минусами этого подхода. Вам нужно постараться сделать так, чтобы оно максимально походило на непосредственное использование продукта там, где это возможно.
Не стоит во время тестирования вслух объяснять, для чего эта система и в чём её суть (если, конечно, не планируется именно так о ней рассказывать в дальнейшем). Лучше сделайте текстовое описание или вступительное аудио/видео и посмотрите, насколько люди его поняли. К следующему тестированию исправьте ошибки и снова посмотрите, насколько всё понятно игрокам.
После тестирования вы можете дополнительно провести анкетирование или взять интервью у игроков. О том, как это лучше всего сделать, можно узнать из нашего курса.
Довольно часто встречается такая ошибка, когда не учитывается обратная связь от игроков, в том числе и тех, кто тестировал систему. Происходит это по нескольким причинам: разработчикам лень это делать, они не считают проблему существенной, даже если о ней рассказали сразу несколько игроков, они подвержены инерции мышления или обратная связь собирается, но не обрабатывается.
Могут быть и другие причины, но такое отношение к их мнению игроки обязательно заметят, и кто-нибудь из них может постараться доказать, что вы зря к нему не прислушались. Вообще такое поведение разработчика – отличный пример того, как можно направить эволюцию игроков в обратную сторону, в частности – превратить Предлагателей и Улучшателей в Разрушителей. Мы наблюдали такое не раз и очень советуем внимательно прислушиваться к обратной связи, а также вносить соответствующие изменения.
Кого звать на тестирование?
Первое побуждение – позвать друзей и знакомых, но тут есть опасность: они могут слишком лояльно относиться к системе из-за хорошего отношения к вам и не расскажут о недостатках, боясь расстроить вас. Иногда они ещё и могут что-то знать о системе заранее и использовать эти знания во время тестирования. Это не то, что вам нужно. Бывает и так, что друзья стараются выполнить задачу по полной и придираются так, что вы уже не рады, что их позвали.
Лучше всего пригласить именно тех, для кого вы и будете делать продукт. Допустим, целый отдел из департамента или несколько отдельных сотрудников. Если вы им скажете, что это особое, специальное, секретное задание по тестированию продукта, о котором ещё никто пока не знает, очень многие с радостью согласятся. Даже если они потом и проболтаются в курилке о том, в чём участвовали, вам это только на руку – интереса к системе в день запуска будет больше.
Если вы всё преподнесёте правильно, то ваши «спецагенты» будут помогать вам и дальше, если вы их об этом попросите. Те, кто помог один раз, как правило, с большей охотой помогают и дальше [30].
