С реализованной функциональностью все вроде бы понятно: мы можем ее увидеть, услышать и почувствовать, когда используем какой-то продукт, в том числе и видеоигру. А вот как быть с заявленными требованиями? Кем заявленными? Где они записаны и как их узнать? Давай порассуждаем. Если они кем-то заявлены, то мы имеем право ожидать, что они и реализованы. Так ведь? Какие требования и функционал пользователь вправе ожидать, например, от старого доброго «шутана»? [4] Очевидно, что в нем геймплей будет развиваться по законам игрового жанра, а перед игроком будут стоять соответствующие задачи. То есть игрок ждет, что в игре он получит возможность использовать различные виды оружия для уничтожения различных видов умных и не очень врагов, восполняя свое здоровье и запасы патронов, находя на уровнях аптечки и ящики с амуницией. При этом ему необходимо будет добраться живым от точки А на первом уровне до точки Б на последнем.

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

Тут я вынужден развенчать один из самых распространенных мифов среди желающих попасть в игровую индустрию через тестирование. Ты не поверишь, как часто при собеседовании очередного кандидата в игровые тестировщики на вопрос «Как ты представляешь себе работу?» можно услышать: «Я играю в игру и по ходу прохождения обращаю внимание на разные баги [5] , потом просто сообщаю об этом своему руководителю». Это утверждение очень-очень далеко от истины.

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

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

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

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

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

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

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

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

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

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