Скачать книгу

обращаю внимание на разные баги[5], потом просто сообщаю об этом своему руководителю». Это утверждение очень-очень далеко от истины.

      Просто поиграть тестировщику удается редко, если только во время знакомства с новым проектом или во время плейтестов[6].

      Обычный пользователь запускает игру, чтобы ее пройти, победить соперников или приятно провести время. Тестировщик же проверяет соответствие игры требованиям, записанным в спецификации (если повезет и такие требования ему дадут[7]), или, основываясь на многих факторах, старается понять, как устроена эта игра и как в нее играть. Другими словами, делает все, чтобы пользователь потом прошел игру, победил врагов и приятно провел время. Причем сама игра может не совпадать с личными предпочтениями тестировщика, так как предназначена совсем для другой аудитории. Тем не менее тестировщик будет раз за разом проходить один и тот же уровень, чтобы проверить, например, правильность отображения игровых объектов.

      Кроме того, помимо самого игрового процесса игра содержит множество различных элементов, которые тоже необходимо проверять. Тестировщики могут обнаружить изъяны в архитектуре игрового ПО уже на ранних этапах разработки, найти ошибки в звуковом сопровождении или выявить дефекты в тексте уже готовой к выпуску игры. Обычно тестировщик занят проверкой порученной ему небольшой части игры, и его задача – убедиться, что его 10 % игры работают на 100 %.

      Вот тебе факт № 1: «тестировать игру» не равно «играть в игру». Но про то, что ты геймер, тоже забывать не нужно.

      Нина Резниченко, QA-менеджер Saber Interactive

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

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

      Например, для игрока всплывающие подсказки в игре могут просто бесить и раздражать, но это не будет являться багом с точки зрения их функционала. Фича работает в соответствии с ГДД[8], подсказки действительно нужны, они работают. Но для игрока они навязчивы, прерывают геймплей в неподходящий момент, а отключить их невозможно.

      Тестируя игру с позиции игрока, спрашивай себя, понятна ли фича для игрока. У тебя, как у QA[9], есть ГДД или описание фичи или какие-то подробности от разработчиков. Но представь, что ты видишь ее в первый раз. Спроси себя: «Как игрок

Скачать книгу


<p>5</p>

Баг – жаргонное название дефекта. В индустрии ходит такая легенда о появлении этого термина. В 1945 году при испытании компьютера Mark II случился сбой в работе, вызванный мотыльком, закоротившим собой контакты реле. В журнале была сделана соответствующая запись о первом подтвержденном случае обнаружении бага (жука). Так с тех пор называют любой дефект программного или аппаратного обеспечения.

<p>6</p>

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

<p>7</p>

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

<p>8</p>

ГДД (гейм-дизайн-документ) – детальное описание разрабатываемой компьютерной игры.

<p>9</p>

QA (Quality Assurance) – это любой систематический процесс определения соответствия продукта или услуги определенным требованиям.