Тестирование в процессе дизайна
Я называю следующие три типа тестирования тестированием дизайнерского процесса, потому что они связаны с дизайнерскими процессами, которые мы применяем для максимального улучшения игры. Вы можете обнаружить некоторое совпадение и даже путаницу между этими тремя типами тестирования даже в профессиональных студиях, но я считаю, что осознавать различия между ними весьма полезно.
Формальный плейтест
При формальном тестировании дизайнеры наблюдают за людьми, которые никогда не пробовали их игру. Это испытание игры в строго контролируемых условиях, оно воспроизводит опыт игрока, впервые включившего новую игру дома. Дизайнеры пытаются понять, как эти совершенно новые игроки воспринимают игру. Могут ли они научиться в нее играть? Нравится ли им в нее играть? Дает ли игра им тот опыт, который надеялись создать дизайнеры? Какие проблемы с дизайном мешают игрокам получить желаемый опыт?
Этот вид тестирования настолько объективен, насколько это возможно в рамках задействованных сложных человеческих факторов. Формальное тестирование часто используется в Naughty Dog, и я был тесно вовлечен в процесс проведения официальных плейтестов наших игр на протяжении большей части моих восьми лет в студии. Мы поговорим о формальном тестировании гораздо подробнее в главах 24 и 25.
Пользовательский тест
Это тип тестирования, который гейм-дизайнеры унаследовали из мира юзабилити и UX (пользовательский опыт). Пользовательское тестирование сосредоточено на разработке и использовании интерфейсов (хотя оно охватывает и гораздо больший объем). В разработке программного обеспечения «юзабилити – свойство системы, продукта или услуги, при наличии которого конкретный пользователь может эксплуатировать систему в определенных условиях для достижения установленных целей с необходимой результативностью, эффективностью и удовлетворенностью»[151].
С определенной точки зрения все в видеоигре представляет собой интерфейс. Не только меню и заголовки, но и дизайн персонажа, вид игрового мира и система управления – три C, – все это передает информацию, формирует режимы взаимодействия и создает опыт.
Поэтому неудивительно, что вы часто будете встречать термин «пользовательское тестирование» при описании формального тестирования, которое мы рассмотрим в главах 24 и 25. Процессы, связанные с формальными плейтестами, частично заимствованы из мира юзабилити и академической дисциплины взаимодействия человека и компьютера (HCI – human-computer interaction). Многие игровые студии нанимают людей с опытом работы в HCI для проведения своих формальных плейтестов, а во многих программах обучения гейм-дизайну есть курс или кафедра юзабилити. Заслуженный профессор гейм-дизайна USC Деннис Виксон помог создать то, что журнал Wired назвал «новой наукой игры» в Microsoft Game Studios[152]. Научная строгость и дизайнерский процесс, которые Деннис и его коллеги использовали для улучшения дизайна своих игр, послужили источником вдохновения для формального тестирования, которые мы проводили в Naughty Dog.
Однако я думаю, что ошибочно полностью смешивать пользовательское тестирование и формальное тестирование. Как мы увидим в следующей главе, формальное тестирование – это несколько субъективная практика, когда дизайнерам часто приходится принимать решения, основываясь на своей интуиции или художественном чутье. В отличие от этого, пользовательское тестирование – это очень строгая, тщательная научная практика, где мы можем быть уверены в достижении определенного дизайнерского результата с помощью эвристических методов и объективного измерения результатов.
Фокус-тест
Как ни странно, некоторые игровые студии называют свои формальные плейтесты или пользовательское тестирование фокус-тестированием. Но фокус-тестирование сильно от них отличается. Фокус-тест – это часть профессиональной и академической дисциплины маркетинга, бизнес-процесса создания отношений с клиентами и удовлетворения их потребностей.
Фокус-тест проводится путем формирования фокус-группы, члены которой отбираются из широкой публики на основе психографической и/или демографической информации, указывающей их как потенциальных пользователей тестируемого продукта, услуги, концепции или рекламы. Членам фокус-группы обычно платят за их время. Заседание фокус-группы проводит специально обученный исследователь, который задает участникам тщательно разработанные вопросы в контролируемых условиях. Ответы группы записываются, а разговор между членами группы поощряется. Они рассказывают о своем восприятии, мнении, убеждениях и отношении к тестируемому объекту. Результаты теста позже анализируются исследователями и обсуждаются заинтересованными сторонами проекта.
Фокус-тесты могут быть полезны на ранних стадиях разработки игры, когда мы хотим убедиться, что наши идеи будут хорошо восприняты возможной аудиторией. Они особенно ценны, если бюджет нашей игры очень велик и мы хотим убедиться, что инвестируем наши деньги с умом. UX-исследователь и гейм-дизайнер Кевин Кикер предлагает множество отличных советов по эффективному использованию фокус-тестов в своем эссе Getting the Most Out of Focus Groups («Получение максимальной отдачи от фокус-групп») в книге Трейси Фуллертон Game Design Workshop[153].
QA-тестирование (обеспечение качества)
Авангардом тестирования любой игровой студии является ее QA-отдел (или отдел обеспечения качества, иногда известный просто как отдел тестирования). QA – это одна из самых зрелых, высококвалифицированных профессиональных дисциплин в любой области разработки игр. Задача QA-тестировщика заключается, во‑первых, в поиске багов: технических ошибок и проблем с контентом, которые негативно влияют на опыт пользователя. Эти баги нелегко найти, потому что они случаются только тогда, когда в игре происходит какая-то редкая последовательность событий или когда используется какое-то необычное сочетание элементов. QA-тестировщики способны исследовать обширное пространство возможностей игры так, как отдельные разработчики просто не могут, помогая нам создавать прекрасные игры.
QA-отдел проверяет игру, следуя тест-плану, который описывает, как будет тестироваться игра и какие проблемы будут устранены. Когда QA обнаруживают проблемы, они заносят их в баг-репорт, которым делятся с другими разработчиками игры. QA-менеджер передает документ руководителям дисциплин (ведущему художнику, ведущему программисту и так далее) в зависимости от природы бага: возможно, это проблема с кодом, которую нужно будет исправить инженеру, или ошибка дизайна, которую нужно исправить гейм-дизайнеру, или же проблема с плохо отображенной текстурой, которую решит художник.
Затем руководители дисциплины передают ошибки отдельным разработчикам в своей группе, которые их исправляют, проверяют изменения в системе управления версиями и отмечают каждый баг как исправленный. (Если они не могут исправить и найти предполагаемую ошибку или не согласны с тем, что это
