Салют Хабровчане. Сегодня я хочу затронуть чуть глубже топик игрового тестирования, ввести в курс дела начинающих в этом деле тестировщиков, развеять стереотипы вида «поиграй сам, дай другу поиграть, вот и всё тестирование. А что ещё нужно, другу же нравится!», а также расскажу базово о видах тестирования, багах, а также подходах и инструментах в рамках тестирования игр.
Это первая из 3х статей по данной теме, где я затрону виды тестирования, во 2й мы поговорим о разновидностях «игровых» багов и посмотрим на их примеры, ну а в 3й — про используемые инструменты, которые помогут с проверкой качества вашего продукта. Вторая и третья статьи планируются к выходу уже в ближайшее время!
С вами Алексей Симкин и мне вновь есть что сказать по теме.
Определение термина и с чего начиналось тестирование игр
Что же такое видеоигра? Базируясь на википедии, приведу следующую цитату: Видеоигра или компьютерная игра — это электронная игра, которая включает взаимодействие с пользовательским интерфейсом или устройством ввода, например джойстиком, контроллером (геймпадом), клавиатурой или устройством обнаружения движения, для создания визуальной обратной связи. Эта обратная связь отображается на устройстве отображения видео, таком как телевизор, монитор, сенсорный экран или гарнитура виртуальной реальности. Видеоигры часто дополняются звуковой обратной связью, передаваемой через динамики или наушники, а иногда и другими типами обратной связи, включая тактильную технологию.
Исходя из вышеописанного, можно заключить, что такое программное обеспечение включает достаточно много составляющих и такие эфемерные вещи как «фактор веселья» или «fun factor», ведь это, в первую очередь, игра. Поэтому можно сказать, что утверждение «поиграть в игру = протестировать игру» все же частично верно, ведь за такие вещи в целом отвечает один из видов тестирования — Playtesting.
Разновидности «игрового» тестирования
Для тестирования видеоигр, как и в других направлениях, есть “стандартные” и свои особенные подходы для решения определённых задач. Давайте рассмотрим их!
Playtesting — это один из видов тестирования игр, который предназначен для понимания предоставления игроки ожидамый вами (гейм дизайнеру в частности) игровой опыт и эмоции от игрового процесса. Для проведения плейтестов игрокам дают доступ к раннему билду (данный вид тестирования проводится до релиза игры и/или фичи). Чаще всего в плейтестах участвуют не QA специалисты, а рядовые геймеры, родственники, в общем кто угодно, кто может взглянуть на ваш продукт свежим взглядом, дать вам обратную связь на основе своего игрового опыта и впечатлений, а также будет уважать то, что написано в подписанным им NDA перед стартом плейтеста.
Мнения, нужно ли подключать команду разработки, включая QA, в плейтестинг, сильно разняться, т.к. фидбек от знающих свою игру на зубок людей может быть не настолько ценен для вас, т.к. тут важно понять заинтересованность в игре вашей же целевой аудитории. Проводить плейтестинг внутри компании или же приглашать “внешних” людей, решение вашей компании на основе её желаний и возможностей. Подробнее про плейтесты можно почитать тут.
Говоря о специфических для видеоигр видов тестирования, я бы выделил такую группу как Game Design Testing, куда включу Balance testing, Level Design testing, «Fun Factor» testing).
Balance Testing предполагает проверку того, что баланс есть 🙂 А именно одно оружие не сильно сильнее/слабее другого в этом же классе, среди персов и их перков нет имбы в той или иной комбинации, лёгкий уровень сложности не слишком лёгкий, сложный — не слишком сложный и т.п. Может быть местами даже нужно подумать о мете игры, но это уже как бонус, этим должен заниматься уже явно не Quality Assurance специалист.
Level Design Testing подразумевает проверку уровней (левелов). Даже самый красивый визуально уровень может содержать непроходимые места из-за, к примеру, невидимых стен (есть модель (меш), но нет текстур), дырок в полу (к примеру из-за плохой стыковки плоскостей или моделей), попадания в так называемые Stuck points, где встрял и уже никуда дальше сдвинуться персонаж не может.
Такой достаточно абстрактный вид тестирования как Fun Factor Testing кто-то выделяет отдельно, а кто-то считает, что это часть Playtesting. Здесь упор делается на «фановость» процесса игры. Идеально сбалансированная игра может банально не весело играться и это отпугнёт аудиторию. Также тут стоит проверить такие игровые механики как навигация, прицеливание, взаимодействие с предметами, NPC и т.д. Неудачные механики, непривлекательный арт, также находится на этой стадии. Если вас в процессе ничего не фрустрирует, вы на верном пути =) Больше про плейтесты, включая Fun Factor, можно посмотреть тут, хоть я и не во всем согласен с автором.
Чуть выше кто-то где-то упомянул персонажей/уровни/предметы и т.п.? Т.е. мы начинаем говорить о Visual Components Testing группе, куда можно внести тестирование 3D моделей/сцен, 2D (спрайты) и 2.5D.
3D Models Testing включает в себя проверку корректности модели (хай и лоу поли) на визуальную составляющую и кол-во полигонов, выставленное в требованиях. Также проверяются все ли текстурные карты доступны и используются для моделей, есть ли отображение внутренней стороны моделей (если они видны), не ломается ли модель во время анимации (риггинг и правильный скиннинг). Во время таких проверок всегда можно заранее найти проблемы с, к примеру, текстурными картами и запечь новые для фикса найденной проблемы.
2D и 2.5D Testing — тестирование уже 2D и 2.5D графики. Сюда включают работу со спрайтами (2D), проверка спрайтов и/или 3D моделей для 2.5D игр, часто в таком виде делают файтинги, сайд скроллеры или рогалики.
Говоря о персонажах, мы не ограничиваемся только игровыми персами и их моделями. Сюда также стоит отнести NPC, а также врагов с их AI, а тут уже целое поле для группы AI testing, куда я включу проверку таких фичи как Pathfinding, AI Spawning, AI Reaction, Detection Range / NPCs (конус зрения) и т.п.). Ведь всегда приятно, когда массовка ведёт себя правдоподобно, не утыкаются в сцены, враги появляются не за спиной или перед игроком и так далее. Тут же проверяем, что Импостеры правильно спаунятся (импостер — это 2D спрайт в 3D массовке или очень лоу поли модели, нужны для разгрузки мощностей вашей машины). Явный пример использования импостеров можно увидеть в финальном сражении Serious Sam 4. Также важно проверить Navigation Mesh (Nav Mesh), чтобы убедиться, что враги и NPC будут двигаться не в предметы и стены. Больше о толпах NPC можно посмотреть здесь.
Такие хитрости как замены хай поли на лоу поли моделей или даже на Импостеров, баланс и скорость отображения полигонов на загруженных сценах, обработка эффектов и т.п. очень сильно могут снизить производительность и количество кадров в секунду (FPS). Данные аспекты проверяются в рамках всем нам известного Performance Testing. Я бы отнёс плюс/минус в эту категорию и Soak Testing, благодаря которому ищут memory leaks в играх. Также в рамках группы по тестированию производительности стоит отнести Stability testing, в рамках которого вы находите такие всеми любимые вещи как фризы, краши, чёрные экраны, невозможность загрузить уровень, порча сохранённых данных и прочее.
Однако проблемы могут возникнуть не только при большом количестве моделей на экране, но также и при большом количестве онлайн игроков в вашей игре. Хотя и не при большом, если вы не протестировали неткод в рамках Network Testing. Благодаря данному виду тестирования можно также проверить лаги/дропы в соединени, matchmaking, стабильность конекшенов, инпут лаги контроллеров и многое другое. Немного отходя в сторону, я бы выделил ещё баги, которые воспроизводятся при плохом интернет соединении и, если у вас со скоростью интернета всё хорошо, то нужно эмулировать «плохое интернет соединение». Больше о неткоде и типах соединения можно посмотреть здесь.
Уже всё вышеописанное звучит достаточно громоздкая и сложная система. Но это ещё ничего, ведь мы больше говорили о front-end части (клиент), а ведь Back-End часть и Back-End testing никто не отменял. Здесь мы пробегаемся по вашему беку, который часто включает базы данных, API (к примеру REST API), телеметрию и многое другое.
Выше я говорил о производительности на железе, но не уточнил о каком именно, а ведь игры нужно оптимизировать и переносить на разное железо различных платформ — Playstation 4/5, XBox Serios X/S, Nintendo Switch, Steam Deck и самые различные и неповторимые конфигурации вашего персонального красавца (ПК). За это отвечает, как вы уже догадались, Compatibility testing. Многие платформы имеют разные режимы работы, к примеру 4K 30FPS + Raytracing, 1080p 120fps и т.д. Та же Nintendo Switch работает в 2х режимах: портативном (720р) и стационарном (1080р). Не стоит забывать и о тенденции «геймпады везде и всюду» и обязательно стоит проверить, что самые разнообразные контроллеры могут работать с вашей игрой на ПК или консоли — разнообразные контроллеры, руль и педали для авто симуляторов, джойстики, контролеры в виде музыкальных инструментов и т.п. Все они имеют в вашей игре корректные иконки при переключении контроллеров, а также все конфигурации для них работают исправно.
Также относительно недавно начал активно развиваться рынок VR и AR приложений и игр. VR и AR Testing я хочу выделить отдельно, т.к. данные устройства имеют слишком много особенностей, чтобы запихнуть их под одну гребёнку с остальными девайсами. Как интересный факт из практики: у VR есть «физическое» ограничение, из-за которого не все смогут разрабатывать/тестировать под VR, а именно — моушн сикнес (укачивание), который возникает при использовании шлемов.
Важно держать во внимании, что кроме ваших собственных стандартов качества к игре, свои стандарты есть у платформодержателей. Часто такие проверки называются Technical Requirements Checklist или TRC, а проверяются они в рамках Compliance testing и, часто, не вашей командой, а командой QA на стороне платформодержателя. В рамках данного тестирования вы можете также проверить внутриигровые покупки, достижения (Achievements), подписки (subscriptions), если они у вас есть, а также поддержку фич стриминговых сервисов. Часто для таких нужд «отпочковывается» отдельный билд, который доводят до ума и не аффектят его изменениями основной билд.
Похожая ситуация происходит во время Альфа и Бета тестирования. Pre-Alpha, Alpha и Beta Testing это больше не о подходе к тестированию, это о срезе игры в определённый момент времени и проверки готовности определённого скоупа на той или иной стадии. Ранее часто подразумевалось, что Альфа — это ещё внутреннее тестирование, а Бета — уже внешнее (к примеру закрытое бета тестирование, когда ключи от билда дают определённому количество игроков). Сейчас же много игр выходит в раннем доступе и альфа билды становятся доступны широкому количеству игроков. Живой фидбек даёт понять разработчикам что они делают (не)верно, что помогает оперативно реагировать и удовлетворять нужды игроков.
Но даже на таких ранних важно, чтобы игроки могли удобно использовать различные контроллеры во время геймплея и навигации по вашей игре — вот мы и пришли к Usability testing. Здесь никакого секрета нету, вашей игрой должно быть интуитивно понятно и приятно пользоваться.
Более чем уверен, что много читателей данной статьи — аудиалы. Звук в играх, как и в кино — один из самых важных и мощных инструментов для влияния на игрока. За тестирование таких нюансов как триггер и проигрыш музыки, звуковых эффектов (SFX), диалогов и реплик, миксовка музыки под происходящее на экране и прочее отвечает Audio testing. Для работы со звуком есть специализированный софт и триггеры многих эффектов и реплик можно найти в автоматическом режиме. Если вы не специализируетесь на тестировании аудио, то скорее всего ваши задачи будут лимитированы пунктами выше. В вашу задачи далеко не всегда будет поиск и использование нужных звуков, главное — заимплементировать возможность проигрыша их при определённых условиях, а далее аудио команда уже сделают оставшуюся магию за вас — вставит нужное аудио или создаст абсолютно новое! Всегда приятно, когда саунд-дизайн в вашей игре на высоте!
А ещё приятнее пользоваться игрой на родном для вас языке + выход на глобальный рынок подразумевает больший охват потенциальной аудитории. Вооружившись знаниями по тестированию I18N и L10N вы сможете сделать так, чтобы от вашей игры получали удовольствие даже в противоположной от вас части земного шара! Если вам не понятные сокращения I18N и L10N, то ознакомьтесь с моим большим и полезным гайдом и чеклистом по тестированию интернационализации и локализации. В качестве особенности проверки локализации игр (Localization testing), стоит упомянуть разницу в часовых поясах ваших игроков и сервера, а также возможность манипуляции времени и даты на вашем устройстве через смену даты и/или времени через календарь. Часто это приводит к разнообразным ошибкам или нежелательному результату. К примеру если вы засетали какой-то контент для отображения с определённой даты, то хитренький пользователь может сменить дату на будущую и заранее увидеть всю ту красоту, что вы ему подготовили и спойлернуть это всем. Даже дата майнингом заниматься не обязательно 🙂 Для проверки корректности языков есть специальные команды локализации, но не забывайте, что в ваших силах проверить языко-независимые вещи в рамках данного тестирования и это стоит сделать заранее!
Странно, что я так долго обходил стороной упоминание основы основ — функциональное и нефункциональное тестирование. Здесь есть где разгуляться и не всегда вам нужно глубокое знание игр и их механик. Самый главный документ с требованиями, который вам точно будет нужен — это Game Design Document (GDD). Здесь описаны все основные и важные нюансы по вашей игре. Есть даже мнение со стороны разработчиков, что тестировщикам не нужно разбираться в играх, чтобы их тестировать, ведь есть GDD и многие другие доки с требованиями. С этим утверждением я больше не согласен, т.к. знание механик, трендов и игр в целом помогает проводить анализ найденных ошибок и создания комплекса ивентов для предотвращения появления их в будущем или возможности найти их на самых ранних стадиях. Формально, да, можно тестировать без знания и понимания многих вещей, да и на аутсорс нередко отдают разработку и тестирование, не связанное с геймплеем или изменением основных геймплейных механик, но так можно тестировать всё, что угодно и это ничем не будет отличаться от Monkey Testing или, если QA крайне пылает энергией и энтузиазмом, но отказывается изучать особенность домена — Gorilla Testing.
Мы уже поговорили о ПК, консолях, даже о VR и AR играх, но не обсудили те девайсы, которые используют большинство геймеров — мобильные телефоны. Как минимум основы Mobile Testing важно знать и понимать, ведь оооочень много игр выходит на мобилки и этот рынок уже давно обогнал по выручке консоли и ПК. Да, игры эти, в большинстве своём, казуальные и гиперказуальные, но и далеко не все игроки «хардкорные» и имеют достаточно времени, чтобы играть в ААА и инди игры на ПК и консолях. Все виды тестирования, упомянутые выше, действительны и для мобильных игр, но также тут важно знать специфику мобильных девайсов и приложений!
Не стоит также забывать и о Security Testing, использование которого глобально не отличается от других сфер. В играх используются учётные записи, аккаунты от разных систем, включая онлайн сервисы и аккаунты от ваших учёток на консолях (к примеру вам нужно играть играть в Rocket League через Epic Games аккаунт, но в системе Playstation), В наше время крайне важно уделять этому аспекту достаточно внимания, ведь никто не хочет потерять даже одну игру, которую этот человек купил или донатил в ней, не говоря уже о потере целого аккаунта со всем «наработанным» добром!
В качестве финального пункта на сегодня в разделе «видов тестирования» важно выделить Game Automation Testing. Автоматизация в гейминге является достаточно сложным процессом. Многие вещи крайне сложно поддаются автоматизации, к примеру, геймплей, ведь важно не только «знать» расположение персонажа, но и понимать, что вокруг него происходит. Если у вас есть рандомайзер, который спавнит врагов в разное время и в разном количестве или ваши элементы для «3 в ряд» появляются далеко не всегда одинаково, то вам нужно придумать что-то наподобие бота для автоматизации и осмысленных действий в рамках ваших тестов. Думаю вы уже догадались, что автоматизация UI элементов или навигации по таким экранам как «Главное Меню» не составит большого труда. Геймплей же автоматизируют при помощи написании своих ботов. Также можно использовать Image Recognition тулы, они также хорошо подходят и для автоматизации скринов без геймплея. Про одну такую интересную тулу (Airtest) я писал в своих предыдущих статьях. Вот они: раз, два и три.
Стоит упомянуть, что одни и те же понятия в разных игровых компаниях могут отличаться. Те же «тест кейсы, чеклисты, тот или иной вид тестирования» даже такие стандартные понятия могут называться иначе. Это не плохо и не хорошо, но нужно иметь такую особенность ввиду.
Посмотрите какие виды тестирования используются у вас в компании, сравните их с выше описанными и, если вы не нашли свой подход к тестированию игр тут, дайте знать об этом в комментариях!
