Современные отделы тестирования

Нынче каждый уважающий себя игрок считает своим священным долгом пожурить разработчиков за качество выходящего в свет проекта. В большинстве своем целью подобного “журения” становятся визуальные эффекты, вышедшие из моды еще несколько лет назад, сюжетная линия, полная избитых штампов, и многочисленные ошибки, допущенные из-за невнимательности, а порой и некомпетентности создателя. И если с первыми двумя недоработками бороться действительно сложно – их проще вообще не допускать, то без устранения ошибок выпускать игру попросту нельзя. В последние годы отечественные разработчики начали тратить существенные средства на создание своих собственных отделов тестирования. Должность «тестер» висит буквально на всех страничках вакансий разработчиков компьютерных игр. Так что же это такое – быть профессиональным тестером?
В данной статье я раскрою общие принципы процесса тестирования и методики отлова и уничтожения багов. Кроме того, я постараюсь дать ответ на извечный вопрос: “А почему же после выхода игры ошибки все равно остаются?”
Самые первые компьютерные игры не содержали больших огрехов вследствие своей простоты. Но с развитием индустрии виртуальные развлечения все больше и больше усложнялись. Апофеозом эволюции или, если хотите, ее критической точкой стало смешение жанров. Негласное правило о багах гласит: “Чем больше в игре нововведений, тем больше в ней ошибок”. Из данной ситуации имеется три различных выхода: первый – вообще отказаться от разработки компьютерных игр. По вполне объективным причинам подобный вариант мы рассматривать не будем. Выход второй – посвятить свою жизнь разработке простеньких игр, цена на которые не превышает нескольких долларов. Спрос на такие игры есть, пускай и гораздо меньший, нежели на полномасштабные хиты мирового уровня. Третий выход напрямую связан с затратой значительных средств и времени на тестирование.
Как только разработчики осознали всю важность проблемы борьбы с ошибками, они решили пойти путем наименьшего сопротивления. Уже на стадии завершения проекта начиналось так называемое «бета-тестирование». Специально отобранным по различным критериям людям давалась копия с игрой, и те за «спасибо» и строчку в титрах должны были в течение небольшого промежутка времени наблюдать за возникающими проблемами и докладывать о них девелоперам.
Затраты со стороны разработчиков были минимальны, как, впрочем, и польза от этого процесса. Неподготовленные люди могли лишь очень-очень поверхностно исследовать игру и в основном видели лишь “вершину айсберга”. После того, как игры стали выходить фактически такого же низкого уровня, как и до тестирования, издатели вместе с разработчиками начали задумываться о создании собственных тестерских отделов с профессиональным штатом сотрудников.
Вместе с образованием таких отделов возникли и некоторые проблемы. Одна из главных – люди, пришедшие устраиваться на работу тестером, абсолютно не представляли, куда они идут. Ведь процесс тестирования целиком покрыт мифами, и очень небольшое число пользователей действительно представляют, как же «это» происходит.

Мифы о тестировании
Первый и он же главный миф: “Тестировать – значит только играть и получать за это кругленькие гонорары”. Несостоятельность данного утверждения заключается в следующем: за длительный период разработки контент игры изменяется неоднократно. В результате чего тестер всегда должен быть в курсе предстоящих нововведений и понимать, насколько положительно они скажутся на геймплее в целом. Необходим многолетний опыт общения с играми различных жанров и четкое понимание того, какой должна быть финальная версия проекта. Одними игровыми навыками здесь не ограничишься.
Миф номер два: “Для тестирования не нужно никаких дополнительных знаний”. Действительно, владеть сложнейшими языками программирования в совершенстве тестер не обязан. Но если ему поручат задание по поиску ошибок в скриптах, а он не знает языка, на котором они написаны, у него мало что получится. Тестирование, не имеющее под собой дополнительных знаний и целиком рассчитанное на зоркий глаз, имеет достаточно низкий КПД.
Миф номер три: “Тестирование нужно лишь на последних стадиях создания проекта”. Сие утверждение неверно в корне. На последних стадиях создания проекта уже очень мало что можно сделать или изменить. Любое исправление некритичной для игры ошибки может привести к появлению десяти критичных. Разработчики вряд ли согласятся на такую авантюру, а посему именно в финальной части разработки любого проекта программный код фактически “замораживается”.

Ломать - не строить
Итак, кем же должен быть тестер? В зависимости от стадии разработки проекта от него требуются разные качества. Вначале, когда каждый день появляются новые наработки, он должен в максимально быстром темпе проверять их на жизнеспособность и на взаимодействие с другими, уже сделанными ранее. Как пример: в некую 3D “стрелялку” добавили способность перетаскивания предметов. Не станет ли теперь возможным выбраться за пределы локации? Это надо обязательно проверить во всех местах любого уровня.

Когда в игре уже реализована большая часть заявленных “фичей”, и своего часа дожидается второстепенный контент (дополнительные миссии, модели оружия, заклинания и так далее), особенно важно умение тестера грамотно “ломать”. Необходимо подвергнуть процессу “ломки” все составляющие игры (интерфейсам на этом этапе достается больше всего) и сделать это максимально возможным количеством способов. Нестандартные действия – вот девиз этой стадии тестирования! Поставить игру на паузу и сто раз нажать на одну кнопку, дать указание герою, а затем эту паузу отжать. Легко! Сменить разрешение шесть раз, дважды потревожить “Alt-Tab”, а затем резко крутануть камеру, приведя видеокарту к полнейшему шоку. Раз плюнуть! На этом этапе как раз и можно понять, предрасположены ли вы к работе тестера вообще. Новых фичей в игре почти не появляется, все разработчики заняты исправлением найденных тобою и твоими коллегами ошибок. Изо дня в день проверка одних и тех же вещей превращается в рутину, чертовски необходимую рутину. Когда же игра проходит эту стадию и начинает заполняться контентом, для тестера наступают счастливые деньки. Новые миссии, новые возможности, новые ошибки. Баги находятся легко и просто. Именно тут и ставятся личные рекорды и бьются любые показатели. “Я написал сто багов за неделю!” - кричит довольный тестер в пятницу вечером. Следующей ступенью тестирования является подготовка проекта к релизу. Постоянная работа в режиме полной готовности – вы вряд ли будете гулять по выходным, а про ночной сон и вовсе придется забыть. Но когда игра появляется на полках магазинов, начинаешь понимать, что это того стоило. Впрочем, эйфория длится недолго. Ведь разработчики не сидят без работы ни одного дня. За выходом одного проекта сразу же следует разработка другого, и так до полного коммунизма.

***
Нерассмотренным остался лишь один вопрос: почему же баги все равно остаются? Для ответа настоятельно рекомендую перечитать статью с самого начала. Избавить разработку игры от пресловутого человеческого фактора на данный момент нельзя. Единственное, что может сделать тестерский отдел, - это свести количество ошибок к минимуму. Обратимся к статистике: с момента образования внутреннего тестерского отдела в Nival Interactive количество патчей к проектам студии уменьшилось с семи до двух. Результат долгой и кропотливой работы, как говорится, налицо.