Тестирование игрового проекта на примере Snowrunner.

Немного ознакомившись с игрой Snowrunner на протяжении 1600+ часов, я нашел пару-тройку десятков багов и недоработок. И возник неудержимый вопрос - а как бы я тестировал проект такого уровня, будучи тестировщиком? Вот ответ! Во-первых, сам для себя напишу, а дальше как пойдет...

Да, я не тестировал проект такого уровня и часть статьи - допущения. Если подскажите в комментариях, где и почему я не прав - честь вам и хвала.

Snowrunner - это видеоигра-симулятор бездорожья 2020 года, разработанная Sabre Interactive и изданная Focus Home Interactive. Вслед за Spintires и сиквелом MudRunner, в августе 2018 года игра была анонсирована как MudRunner 2. Год спустя Focus Home и Sabre Interactive повторно представили название как SnowRunner.

Содержание:

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

Тестовое окружение.

Тестирование игры — это процесс поиска несоответствий: логических, физических, в сюжете, в звуковом окружении, в графике и анимациях.

Процессы тестирования разделяют по стадиям состояния проекта. Чтобы не раздувать статью (а она будет не маленькая), принимаю, этап производства, как начало тестирования. Более ранние этапы сосредоточены на процедурах планирования, проработки стратегии и создание артефактов тестирования, а этап производства затрагивает непосредственную проверку работающих механик и проверку качества продукта (игры).

Чуть-чуть о терминах и процессах тестирования:

QA (обеспечение качества) - тестирование происходит с момента возникновения идеи. Процессы QA обеспечивают качество продукта, т.е. не дают команде разработки совершить ошибок.

QC (контроль качества) - тестируют с конкретной версии продукта, когда продукт уже готов и качество не устраивает.

Testing (тестирование) - процесс проверки качества определенной версии продукта. Разовый процесс, проверили, оценили, выдали оценку и всё, процесс завершен.

Нижний процесс тестирования вкладывается в верхний. Казалось бы надо только QA заниматься, это же полноценное тестирование, тем более оно позволяет исправить еще не совершенные ошибки. В реальности используются все процессы и наиболее часто используется как раз контроль качества. Почему так происходит? У каждого проекта для этого есть отдельная история.

Документы и ревизия.

Исходные данные - в наличии версия игры, где присутствуют основные игровые механики. В неё уже можно играть и дело за малым - добавить карт, заданий, декораций, машин и модулей для них. Есть как минимум один уровень более-менее готовый. Игру предстоит тестировать до готовности и выпуска в продажу (выполняем контроль качества).

Для начала, тестировщик должен выполнить ревизию документов и спецификаций к игре. Это проблема. В случае, когда дизайн-документ покрылся пылью и совсем не отражает текущее состояние игры, а главный гейм-дизайнер ничего не помнит, но точно знает, что вчерашняя версия игры не имеет ничего общего с сегодняшней версией. Это плохо. Тут тестировщики не помогут, нужен нормальный менеджер проекта. Пример работы с такой командой я рассматривать не буду, это будет не про тестирование.

Итак, тестировщик проводит ревизию документов. Что это за документы?

Дизайн-документ я уже называл, это перечень и описание всех элементов игры. Это то, с чего начинается разработка игры, продолжается и заканчивается. Но, это комплексный документ, т.е. не один документ. То есть не документ, а система документов. А вы думали будет просто? И самое интересное - никаких стандартов в подобной документации нет. Есть только цель!

Устав проекта. Большинство команд игнорируют этот документ, а зря. Он показывает, что именно мы разрабатываем, почему именно это, какой командой. В Устав проекта включается информация анализа рынка и выбор: внешний вид игры (изометрия, первое лицо, третье лицо, side-scroller и т.д.), жанр, суть игрового процесса, механики и основные особенности. Выбираются игры конкуренты, подчеркиваются преимущества перед ними. Дата релиза выбирается с учетом нескольких аргументов - нет конкурентов, удачный сезон продаж, мода на игры такого жанра. Грубо оцениваются продажи (количество копий). Выбирается игровой движок. Анонсируется состав команды. Устав проекта содержит не более 5-ти страниц текста. Разрабатывается до начала процесса разработки, фиксируется и более не меняется. В случае четкого разделения разработки на прототипирование и производство - разные отделы/команды, разный бюджет - понадобятся два Устава, это два разных проекта, пусть и на одну тему.

Для Snowrunner справедливо следующее: главный герой автомобиль (неожиданно), вид из кабины рассматривается как опция и не предполагает постоянную игру в таком режиме, основной режим игры камера от третьего лица. Масштаб автомобиля и его узлов максимально детальный с анимированными элементами, что позволит сосредоточить внимание игрока именно на модели машины. Это позволит проще продать другие настолько же детальные автомобили. Жанр: симулятор бездорожья, перевозка грузов. Основные механики: перевозка грузов на больших машинах с мощным мотором, с застреваниями и опрокидываниями. Конечная цель: выполнить все задачи в регионе, получить 100% выполнения. Конкуренты: Spintires, Mudrunner - это проекты с устаревшей графикой, мы значительно поднимем уровень графики, а в видах грузов добавим массу разнообразия. Надоевшие всем бревна уберем (а потом добавим). Добавим машин с внутриигровым магазином, с покупками за игровую валюту. Это позволит добавлять машины при выходе нового региона и выпускать дополнительные DLC с машинами. Дата релиза выбрана согласно чернового плана разработки без учета особых критериев. В связи с отсутствием конкурентов можно выпускать по готовности в любой момент. Желательно не попасть на предновогоднюю распродажу, там будет много конкурентов из других жанров. Игры жанра симулятор показывают стабильную популярность на рынке, ожидаем продажи в районе 1-2 млн. копий за первый год. Игровой движок выбран собственного изготовления, что минимизирует технические и финансовые риски. Ранее он использовался в <таких проектах>. Текущие возможности движка полностью соответствуют потребностям для реализации проекта Snowrunner. Команда: <перечислена команда>.

Концепт документ - краткий документ следующей структуры: термины игры, визуальный концепт (арт), история/сюжет, игровая модель (Core loop), описание игровой сессии, игровые механики, описание игровых систем. Главная цель концепт-документа - кратко и ёмко представить игру.

Питч-документ - документ, содержащий доклад для участников команды, для руководства Компании, для возможных инвесторов. Демонстрирует основные игровые механики, концепцию исследования в игре, конфликт/вызов для игрока, ценность для игрока. Отвечает на главный вопрос: в чём уникальность игрового опыта?

Документ ограничений и рисков (технические, финансовые, исторические, сюжетные и прочие) - документ описывает систему ограничений для проекта. Для Snowrunner - наличие/отсутствие лицензий на автомобили. Карта до 2х2 км., максимум 4 карты в регионе.

Документы игровых механик. Описывают подробно каждую механику. Являются основными документами для команды разработки. Скорее всего это будут целые разделы в местной вики. Без подобных документов разработка невозможна. Такие документы правятся и обновляются до моменты выпуска игры.

Таск-трекинг. Баг-трекинг. Доступ к системе регистрации задач позволит определить в каком состоянии в данный момент находится проект, какие задачи актуальны. Для тестировщика особенно важно знать какие баги найдены и находятся на исправлении. Бывает, что закрывают доступ в таск-трекинг разработки для тестировщиков, но это плохая практика. Утаивание любой информации от участника процесса разработки - это плохо.

Документ предположений - свободный документ, куда участники команды скидывают предположения, решения, статус, ссылки на диздок и прочее. Рабочий документ, который просматривается всеми участниками команды. Тим-лиды структурируют этот документ, консолидируют по группам разработки, фиксируют информацию в вышестоящих документах. Это позволяет не отвлекаться членам команды за неким обсуждением, можно написать предположение и чуть позже получить ответ. "В игре 30 машин, значит ли это что должно быть минимум 30 видов колёс? Ответ: Нет, колёса универсальные, подходят разным машинам, есть таблица по этой ссылке."

Я описал минимальный набор документов для разработки игры и к тестированию это не имеет отношения. Прямого не имеет, всё так. Тогда зачем? Есть вариант, когда из перечисленного ничего не будет - громкий закадровый смех. Так, совсем о грустном не будем. Если не будет какого-то документа, ничего страшного, тестировщик сделает его сам, пусть для себя. Для этого надо провести ревизию существующих документов, проанализировать их и создать для себя недостающие документы. После чего будет полезно завести привычку с определенной периодичностью свой документ актуализировать.

Я рассматриваю тестировщика как заинтересованного в работе сотрудника. Бывают и такие "пока чек-лист и билд не дадите, ничего делать не буду". Я таких рассматривать не буду. С ними тоже можно работать, но лучше не надо.

Переходим к главной части статьи, начинаем тестировать. Нет, рано еще тестировать. Выполняем декомпозицию задачи.

Декомпозиция в тестировании.

Для тестирования чего-либо лучше разбить его на части. Это ускорит поиск багов и упростит задачу. Любому человеку проще работать с чем-то простым и понятным.

Любая игра строится на балансе вызовов и наград. Какие вызовы в Snowrunner:

сложная дорожная обстановка, для этого используются несколько видов покрытия дорог: грязь, снег, лёд, вода, камни, корни, деревья.
слабая машина, лебедка, шины, двигатель.
участок карты не предполагался для передвижения на машине: скалы, лес, болото, глубокий водоём.
для покупки модуля или новой машины требуется внутриигровая валюта.
маленький уровень игрока, который блокирует часть машин или модулей.
другой регион, где есть бесплатный автомобиль, но регион сложнее стартового.

Против вызовов выступают награды игрока:

набор разнообразных высоко-детализированных машин.
множество модулей для оборудования машин.
многовариантность выполнения задания - выбор машин, модулей, маршрута.
счастье от успешного выполнения задания, получение внутриигровой валюты и опыта.

Разобрали вызовы и награды. Пришло время обсудить сценарии основных игровых механик. Без этого игры не существует.

В дело вступает гейм-дизайнер, где-то у него должны быть выписаны сценарии игровых механик. А может и нет у него ничего.

Если нет, делаем самостоятельно. Выше описаны вызовы/награды для игрока, основные механики должны применять всё перечисленное.

Основные игровые механики:

движение машины по бездорожью с разным покрытием, с возможностью застрять, опрокинуться, затопить машину, повредить машину.
манипуляции с грузом, погрузка краном и автопогрузкой, перевозка грузов на авто или на полуприцепе/прицепе, перевозка с одной карты на другую в одном регионе, перевозка груза на другой регион, сдача груза по заданию, упаковка и распаковка грузов.
при опрокидывании можно собрать груз краном, опрокинувшуюся машину можно поставить на колёса другой машиной, с помощью лебедки или крана. Можно использовать отдельный большой кран с повышенной грузоподъемностью.
использование лебедки для спасения в сложной ситуации. Позволяет вытянуть заведенную машину из грязи, уберечь от падения, тянуть за собой машину/прицеп. Есть отдельный вариант автономной лебедки, но только для скаутов.
смена конфигурации машины, смена модулей.
покупка новой машины в магазине.
выполнение заданий на карте с получением опыта и валюты. Изменение окружающей обстановки - починка мостов, починка производственных зданий с доступом к новым грузам.

Так мы получили первые объекты для тестирования. Запоминаем эти сценарии. Использовать их будем в регрессионном тестировании. Сломать можно всё, но основные сценарии должны работать.

С чем именно игрок взаимодействует большую часть игры? Пытаемся разбить игру на части:

машина: смена конфигурации, работа пунктов меню (V), повреждения модулей.
карта/уровень: декорации, точки интереса, триггеры: точки с грузом, задания/поручения и точки сдачи, переход на другую карту, освещение уровня, звуковое сопровождение.
гараж: смена конфигурации машины, магазин, стоянка, тюнинг. Это чуть больше любой постройки на уровне, поэтому вынесен в отдельную часть.
симуляция физики: застревание машин, опрокидывание и затопление, работа с краном, коллизии с объектами.

На самом деле можно выделить больше частей, но я сократил, чтобы не раздувать статью. Остальные части будем проверять в полноценном свободном тестировании.

А какие именно дефекты встречаются в играх? Проблемы с графикой и анимацией, Нарушение физических законов в игровом мире, Ошибки искусственного интеллекта видеоигры, Неточности в построении сюжета видеоигры, Некорректная работа игровых объектов.

Тестируем машину и никуда не едем.

По спецификации машины составляется чек-лист для проверки одной машины. Используются как позитивные, так и негативные тесты по сборке конфигурации.

Без спецификации придется тестировать отталкиваясь от собственного опыта и логики, что хуже и может не отражать видение гейм-дизайнера.

На машину ставятся разнообразные модули. Выполняется проверка можно поставить определенное сочетание модулей или нет. На модели проверяем наложение и однородность текстур. Проводится поиск пересечений модулей. Проверяются модули в кабине и раскраска, премиумная раскраска имеет приоритет для проверки. Машину выгоняем из гаража и проверяем под солнечным светом или наоборот, ночью.

Проверяем внешний вид модели в разных состояниях. Это стандартная модель и модели с повреждениями (несколько). Загрязненная, заснеженная модель. Возможно еще какие-то есть. Модель стоит проверить со всех сторон. Это можно будет сделать через редактор сохранений.

Проверяем работу фар, стоп-сигналов и проблесковых маячков.

Проверяем вид из кабины. Смотрим на текстуры, ищем возможные пересечения графических объектов.

Проверяем звук двигателя автомобиля, ездить не обязательно.

В случае отсутствия интерфейса игры на этом этапе и гаража в том числе. Необходим сторонний инструмент для правки конфигурации машины. Например, редактор файлов сохранений.

На этом всё, считаем, что машина проверена и прошла статическую проверку. Мы проверили смену конфигурации машины, работу основных функций.

Желательно на этом этапе найти как можно больше дефектов. Модель находится в производстве, все участники ничего еще не забыли. Этот процесс сильно облегчит дальнейшую работу.

Следующая подобная проверка будет выполняться при изменении спецификации машины или модулей.

Приоритет по машинам, составляем список появления машин в игре согласно регионов. Первые машины должны быть без замечаний. Чем позже игрок встретит баг, тем проще его воспримет. Если не успеваете, не укладываетесь в сроки, тестируйте то, с чем игрок повстречается в первую очередь (машины, уровень, интерфейс). Маловероятно, что новый игрок сразу прыгнет в последний регион и там сразу поймает баг.

Второстепенным приоритетом пользуются машины, поставляемые отдельными DLC.

Проверенные машины могут переходить на стадию проверки основных механик игры. Где нужно проверить анимацию узлов машины, физику, урон по модулям и прочие игровые механики.

Мы дошли до тестирования графики, это важная составляющая любой игры. Какие особенности тестирования графики в играх?

Составляющие графики: Уровни, Модели, 2d/3d графика, CGI графика, Текстуры, Коллизии, Анимации, Эффекты, Освещение сцены, Историческая достоверность.

Возможные дефекты: Отсутствие текстур, Ошибки LOD, Ошибки сетки коллизии, Ошибки области поражения, Прочие: несоответствие историческому прототипу; предметы, висящие в воздухе; видимый стык между текстурами; разрушение объектов; дефекты освещения, дефекты анимации, сбои визуальных эффектов.

Тестируем Карту/Уровень.

Тестируем карту или регион. Это большой объем работ, пересекающийся с другими частями игры. Для составления тест-плана необходимо получить спецификацию уровня, где перечислена полезная информация о задумке уровня, точках интереса, маршрутах и их сложности.

Потребуются инструменты для свободной камеры и перенос машины к точке камеры. Так можно будет быстро перемещаться по карте и проводить тесты зон на карте.

Проверяем объекты уровня на графические баги и размещение на уровне. Проверяем коллизию объектов и разрушаемость. Приоритетом являются объекты около дорог или предполагаемого движения игрока - главные маршруты.

Проверяем границы карты, что нельзя "вывалиться" с карты.

Проверяем работу уровней детализации. Без дополнительных инструментов тут не обойтись. Нужен инструмент для подсчета полигонов каждого кадра и сбора статистики. Покатавшись по уровню, можно собрать информацию по количеству графических примитивов. Это должно соответствовать некому бюджету полигонов, превышать который нельзя. При превышении бюджета полигонов в определенном районе уровня стоит зафиксировать дефект.

Проверяем дистанцию отрисовки мелких деталей на уровне. Детализация ландшафта, камни, мелкие декоративные объекты. Момент появления таких объектов на уровне желательно сделать незаметным для игрока. Это же касается механизма переключения моделей с разным уровнем детализации.

Проверяем звуковое наполнение уровня, касается фоновых звуков зон. Проверяем работу фоновой музыки на уровне.

Триггеры, необходимо выполнить все задания и проверить правильно ли работают условия выполнения. Хватает ли для выполнения заданий грузов. Соответствие описания задания ожидаемым действиям. Наличие и качество роликов при постройке мостов и заводов.

Триггер перехода на другую карту региона проверяется с учетом прицепов, полуприцепов, грузов и машин на платформе/прицепах (упакованных и не упакованных). Прицеп или машина, сопровождаемые на лебедке должны переходить на другую карту. Выбираются машины разного размера от самых маленьких, до самых больших. Должен ли не упакованный груз перемещаться на другую карту скажет гейм-дизайнер (см. документ предположений).

Бездорожье. В спецификации уровня должна быть представлена маршрутная информация, где именно предполагается движение машины. Маршруты необходимо оценить по сложности. Тестирование проводится только указанных маршрутов, остальное игнорируем. Обращаем внимание на текстуры, изменение и анимацию дорожного покрытия и машины. Проводим проверку оценки сложности маршрута. Есть смысл использовать несколько машин для одного маршрута. Если нет машин, прошедших статичную проверку, берем первую-вторую машину, которую встретит новый игрок при старте игры.

Проверяются экраны загрузки карт на регионе.

Объем тестирования уровня будет зависеть от готовности других частей игры. Стоит подходить разумно и тестировать существующие части игры. А по мере наполнения игры, актуализировать кейсы и проводить проверку с учетом новой функциональности.

Следующая проверка уровня проводится при изменении уровня или добавлении части игры, работа которой связана с работой уровня. Лучше отталкиваться от изменений спецификации уровня.

Состав игрового уровня: Структурная геометрия, Игровая среда, Освещение, Звуковое сопровождение, Игровой функционал.

Возможные дефекты: Геометрия, Недоступные места, Сложный игровой процесс, Баланс игрового уровня, Неуместные ограничения и условности, Повествование, Изменение цветового кодирования объектов.

Тестируем гараж.

С одной стороны это объект уровня. С другой, гараж предоставляет массу функций для игрока. А именно:

слоты для машин, куда можно загнать разные машины, переключаться между ними и проводить с ними операции. Несколько слотов, стоит проверить их работу, не теряются ли машины, что будет, если загнать машину при заполнении всех слотов. Количество одинаковое, но есть регион Мэн, который нарушает это условие. Поэтому максимальную вместительность необходимо проверить.
тюнинг машины: работа с конфигурацией машины, установить, снять, продать, посмотреть модуль не покупая.
магазин машин: фильтр по видам машин, режим предпросмотра, покупка машин.
стоянка: передача машин на хранение, продажа машин, вывод машин в слот гаража любого региона.
покинуть гараж: вывод машины из гаража.
для сложного режима проверить пункт "Ремонт".

Необходимо проверить каждую функцию гаража. Да, часть функциональности гаража будет проверена при тестировании машины и смены конфигурации. Но, там мы тестируем машину, а тут гараж и его функционал.

Это тестирование сильно пересекается с тестированием UI.

Физика и бездорожье.

Сложный кусок игры. Надо определить, что такое дефект в условиях проверки физики.

Дефект физики - ошибочное поведение физического движка в игре. Спецификация физики должна подсказать как именно обрабатывается физика, какие граничные условия, в каких ситуациях хорошо симулирует, а в каких не очень.

Пример: лебедка не тянет машину - это не дефект, зависит от условий и от спецификации лебедки. Колесо визуально не касается дорожного покрытия - подозрение на дефект. Машина вошла в саморезонанс, подлетела в воздух и самоубилась - дефект. Машина не глохнет при полном погружении под воду и двигатель не получает урона - дефект. Машина заглохла и двигатель получил урон, когда шноркель находится над водой - дефект. Не едет в горку - не дефект, смотрим спецификацию, пробуем поменять движок, коробку скоростей и колёса.

Для проведения проверок нужен тестовый уровень с гарантированными условиями. Проверка выполняется в связке уровень плюс конкретная машина. Какие-то препятствия машина проедет, какие-то нет. В отчете отражается пройден участок или нет.

Очень полезно записывать видео прохождения тестового уровня. Все замечания или подозрения на дефекты можно будет указывать точным временем в видео.

Важно проверять вариативность поведения машины. Менять конфигурацию и смотреть есть ли отличия в поведении машины. Так же стоит использовать разные грузы и пустую машину отдельно, с прицепом, с полуприцепом, с краном-манипулятором и без него.

Физику есть смысл тестировать с учетом системного тестирования. Используем минимальную конфигурацию ПК и рекомендуемую. Если есть различия в поведениях игровых объектов, плохо, это дефект. Игровой движок на конфигурации со слабым процессором может пропускать "кадры" обсчета физики, что будет накапливать ошибку расчета.

При оформлении дефектов физики не всегда получится указать шаги к повтору бага. В этом и сложность. Видеорегистрация происходящего очень полезна.

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

Любая игра это большой комплекс ресурсов и механик взаимодействия. Стандартного и универсального алгоритма для тестирования игр не существует. Приходится исходить из ситуации.

Пройдемся по видам тестирования и применим их к проверке работы игры.

Дымовое тестирование.

То, что выполняется в первую очередь я пишу где-то в середине. Каждая версия игры должна быть проверена на работоспособность. Данное тестирование состоит из минимального набора тестов.

Цель этого тестирования: можно ли брать версию в дальнейшее тестирование или сразу вернуть её команде разработки.

В рамках игры Snowrunner это бы выглядело так: установить игру, запустить, дождаться главного меню, начать новую игру, доехать до ближайшего триггера (задание, АЗС, вышка), проверить, что он работает, выйти из игры. Не должно быть никаких сообщений с ошибками.

Проверять лог файл или нет - это уже частности.

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

В случае, когда игра падает, оформляется баг, ждем следующую версию, а пока работаем над предыдущей.

Отлично, поехали дальше.

Регрессионное тестирование.

Проверка, что ничего не сломали, что до этого работало.

Я предлагаю использовать здесь проверку сценариев основных механик игры.

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

И для вариативности добавляем опции выбора задействованных объектов. Например, можно составить 5 списков машин на каждый день недели и менять их согласно текущего дня недели. Так же можно привязать смену уровня, на котором проводятся проверки основных механик (как только у нас появится несколько игровых уровней). Не уложимся в неделю - расписываем на две недели (10 дней). Балансируем между количеством ресурсов и количеством тестировщиков.

Такой подход позволит ротировать объекты, участвующие в тестировании и тестировать всё, но протяженно во времени и не привязываясь к текущей версии игры.

Функциональное тестирование.

Комплекс проверок для проверки работоспособности продукта в целом.

установка игры, казалось бы, при дымовом это уже проверили, но тут есть варианты: поставить игру на диск, где мало места; поставить по пути, содержащем русские буквы; поставить под учеткой с русскими буквами, прочие варианты (возможно безумные).
графика, соблюдение общего стиля графики, поддержка эстетического эффекта.
звук и музыка, проверка соответствия звуковых эффектов визуальным и своевременности звуков.
UI, UX тестирование, локализация: читаемость, понятность, удобство.
сетевой режим игры.
проверка работы устройств ввода - геймпад, руль.
проверка режимов сложности игры и экономической составляющей.
работа игры на консолях.

Многообразие звуков: Звуки окружающей среды, Голоса персонажей, Фоновое звуковое сопровождение, Звуковые эффекты, Различные звуковые объекты, Голосовые файлы.

Дефекты: Отсутствие звукового эффекта, Воспроизведение неправильного звука, Некорректное воспроизведение правильного звука

Нефункциональное тестирование.

Проверки не относящиеся к функциональности продукта.

системное тестирование: состав минимальных и рекомендуемых требований к ПК.
производительность продукта, стабильный и достаточный FPS, отсутствие фризов.
скорость запуска игры до главного меню.
скорость загрузки карт в игре.
работа игры, установленной на HDD и SSD - есть ли отличия и на сколько.
для консолей: проверка работы профилей производительности.

Имеет смысл регистрировать замеренные параметры, чтобы видеть прогрессию продукта - ухудшаются показатели или улучшаются.

Конфигурационное тестирование.

Для выбора устройств и разрешений экрана можно использовать рейтинг от Steam.

проверка работы на устройствах с разным разрешением экрана.
использование разных устройства ввода.
видеокарты от разных производителей и разного ценового диапазона.

Можно выполнять регресс с разными вариантами конфигураций ПК.

Игровые контроллеры: Двуручный игровой контроллер (gamepad), Клавиатура и мышь, Игровой руль.

Дефекты с контроллерами: Устаревший драйвер игрового контроллера, Несовместимость модели игрового контроллера с игровым приложением, Дефект отдельного устройства или всей партии, Несоответствие игрового процесса инструкции.

Свободное тестирование.

Используются только игровые уровни. Казалось бы, вот оно, просто играть. Нет! Не играть, а продолжать тестировать. Да, это тестирование по игровому сценарию. Согласно правил и условий прописанных в сценарии.

Допустим, некая машина не может проехать по определенному маршруту, вот вязнет она там. Гейм-дизайнер меняет параметры машины и надо проверить, проедет или нет. И так несколько десятков раз.

Другой пример: есть состязание на время, надо замерить и установить временные шкалы для золота и серебра. Время не должно быть с большим запасом, но и маленький запас может вызвать проблемы у реального игрока. Один из вариантов, тестировщик катается на разных машинах и фиксирует свои успехи. Берется некое среднее значение и умножается на 1.15.

Еще пример: есть задание, в котором ранее нашли ошибку, требуется его проверить с момента загрузки машины грузом, довезти и сдать груз. С контролем, что задание засчитается без ошибок, доехать можно, груз будет принят.

В этот момент есть смысл проверить регистрацию урона по модулям и починку машины. С использованием сервисного прицепа или в гараже.

Этот процесс проверки ближе к игре, чем что-либо до этого.

Негативное тестирование.

Используются игровые уровни. Предпринимаются попытки сломать игру или игровые механики. Игра с нарушением всех правил. Нужно играть не как большинство игроков. Видеорегистрация обязательна, повторить такое будет сложно. А разработчикам это даст пласт полезной информации.

переворачиваемся на машинах, раскидываем груз, пытаемся поднять машину, собрать груз.
перевозим груз с перевесом, укладываем в штабеля на платформе/прицепе/полуприцепе. Используем кабину как площадку для груза, подвешиваем на кране и пытаемся везти.
врезаемся в объекты, с грузом, без груза, смотрим регистрацию повреждений. Падаем на машине с обрывов, тонем в реке.
используем самые невероятные пути для достижения цели. Вариант: краном спустить машину с обрыва и проехать по ущелью, в котором не предполагалось ездить. Прорваться через лес. Форсировать реку в неожиданном месте.

Пробуем всё самое невероятное в игре. Никаких правил. Регистрируем странное поведение игры. Пишем в отчете свои подозрения и замечания со ссылкой на видео. Это пока не дефекты, но есть подозрение.

Цели: уронить игру, сломать физику, собрать информацию о возможных повреждениях машин в игре, собрать информацию о альтернативных маршрутах и способах перевозки грузов.

Тестирование UI/UX и локализации.

Входит в функциональное тестирование, чуть подробнее распишу.

Тестируем интерфейс: правильно отображается или нет, читаемость описаний и другого текста.

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

В рамках UX тестируем удобство игры. Очевидное управление или нет, на сколько понятен интерфейс. Проверяем подписи кнопок согласно устройства ввода. Отмечаем все моменты, которые мешают игре.

Локализацию тестируем в части читаемости шрифтов. Нет ли обрезанных текстов в интерфейсе из-за различий в длине строк.

Процесс локализации включает две задачи: Интернационализация, Локализация.

Причины дефектов: Изображения, Звуки и саундтреки, Реалистичные или исторические сцены, Фразы или цитаты.

Возможные дефекты: Технические факторы, Перевод, Культурная адаптация содержимого.

Исследовательское тестирование.

Похоже на свободное тестирование. Выполняется с чек-листом или кейсом, который тестировщик разово пишет себе сам. Никто игру не знает лучше тестировщика, охота проверить какие-то моменты - вот как раз для этого существует отдельный вид тестирования.

Позволяет забрести в такие дебри, куда ни один тест-дизайнер не отправит.

Тестовое окружение.

Для работы тестировщик настраивает себе тестовое окружение. Это позволит облегчить работы или даже ускорить. Что будет полезным для тестирования Snowrunner?

Файлы сохранений игрового процесса с заранее заготовленными конфигурациями машин.

Тестовый уровень, не игровой, используется только для тестирования. Полигон.

Тестовый уровень состоит из:

препятствий - грязь, снег, лёд, асфальт, вода и т.д.
препятствий с комбинациями, грязь с плавающими камнями, грязь с корнями, лужа с корнями и утонувшими поваленными деревьями и т.д.
поперечных уклонов с разными углами, с разным покрытием - асфальт, твердый грунт, лёд, грязь, камни.
подъемов и спусков под разными углами, с разным покрытием.
точек зацепа для лебедки.
точки с грузами, желательно все типы грузов с автопогрузкой и ручной погрузкой.
гаража со всеми машинами и модулями и магазина прицепов.
каждое препятствие должно быть пронумеровано и параметры отражены в спецификации к уровню. Есть возможность каждое препятствие объехать и пропустить.

Такой уровень не содержит задания, тут они не нужны. Карта должна быть минимального размера. Желательно с интерфейсом, пусть без оформления, текстур и иконок, но с функционалом.

Инструменты:

отдельный режим игры пролета по карте камерой.
возможность телепорта активной машины на место камеры.
редактор файлов сохранений.
CapFrameX или аналог, для записи видео и анализа FPS и других параметров.
OBS и свободное дисковое пространство.
программа редактирования видео.

Процесс тестирования.

Много написано, давайте соберем это всё в кучу. Ранее я говорил, что новая версия у нас будет каждое утро.

Не слишком ли это часто? Может быть раз в неделю?

Не часто, нормально. Версия на каждое утро решает несколько вопросов:

далеко не каждая версия пройдет дымовое, а следующая будет через сутки, что не долго.
ежедневная версия несет небольшой инкремент как в коде, так и ресурсах игры. Что проще для тестирования, ведь простые вещи или изменения проще протестировать.
в отсутствии новой версии идет работа над предыдущей. Например: не прошла дымовое.
при наличии новой версии, все тесты переключаются на новую версию, прошедшую дымовое.

Теперь представьте то же самое, только в при сборке раз в неделю. Там дымовое никто не пройдет, т.к. инкремент огромный. Новую версию ждать очень долго. И все уже забыли, что было в прошлой версии, новая совсем другая игра.

Как построить процесс тестирования в этих условиях. Первым делом рассчитываем тайминги. Сколько у нас идет дымовое, сколько тестирование объектов, тестирование основных механик и т.д. Можно оценить что есть и выстроить примерно такую схему на неделю.

описано 6 рабочих часов в день. 2 часа в резерве, на встречи, на ревизию и актуализацию артефактов тестирования. Думаю, даже 6 часов это много, реально надо сокращать до 4-х часов в день. Тогда стоит этот план размазать на две недели.
выполняется дымовое, при наличии больше чем 1-го тестировщика, стоит дымовое выполнить как можно раньше. Далее, если не прошло, тестируем предыдущую версию, если прошло переключаем все тесты на новую версию. На вики на отдельной специальной стартовой страничке большими буквами и цифрами пишется версия для теста. Кто проводит дымовое, тот и диктует какую версию будем тестировать. Остальные тестировщики это время могут потратить на другие тесты или работу с документацией/артефактами.
ретест, выполняется проверка ранее найденных и исправленных багов. По картинке на него отведено всего полчаса, что может быть мало. Учитываем, что дымовое маловероятно займет целые полчаса, т.е. фактически на ретест будет минут 50.
тестирование объектов. Проведено распределение объектов на неделю. Учитываю, что машин у нас очень много, поэтому машины тестируют каждый день. Тестирование машины отключается до изменения в спецификации машины или до изменений в модуле, который на нее ставится. После чего, машина снова возвращается в пул теста. Машина, прошедшая статичное тестирование переходит в свободное тестирование или тестирование любых других механик, где стоит обращать внимание на анимацию машины.
регресс, потребуются исходные данные для выполнения проверок основных механик. А именно, машина, её конфигурация, карта/уровень, маршруты. Сюда можно включить ретест, если не уложился в отведенное время и дополнить начальные условия. Обязательно отразить в отчете все начальные условия.
если машин будет больше чем возможности группы тестирования. За неделю не удалось протестировать все машины и пошли изменения по протестированным машинам. Следует расписать перечень машин на 2 недели. Да, будет медленнее. Если хотим всё и сразу - требуется расширение группы тестирования.
стоит помнить, этот план гвоздями не прибит, если не удается укладываться его нужно корректировать.

Актуализация документов тестирования как важный процесс прогрессии разработки. В режиме разработки игры неизбежны дополнения или полный пересмотр частей игры. Что делает существующую документацию не актуальной. Чек-листы, кейсы и планы нужно будет править согласно изменений.

На протяжении всей недели отслеживаются новые версии. И в какой-то определенный день. Руководитель группы тестирования (тим-лид, тест-дизайнер) разбирает все изменения за неделю и вносит правки в артефакты тестирования. После чего, отдельным письмом, оповещает всю группу, какие документы и на сколько поменялись. А на ближайшей встрече стоит обсудить изменения и прислушаться к замечаниям от тестировщиков. Главное, этот процесс не упускать, собрать изменения за две недели будет уже в два с половиной раза сложнее.

Рациональность при тестировании.

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

Нужно тестировать дальше. Скорее всего баг будет групповой. Нужно сделать предположения и проверить еще пару-тройку раз. Не повторяется ли дефект в других, но похожих условиях.

Нужно постараться дать команде разработки как можно больше информации. Это сложно, но к этому нужно стремиться. Такой подход позволит массово уничтожать баги.

Сложности, проблемы и частные случаи необходимо обсуждать внутри группы тестирования, а так же с командой разработки. Разработчики должны понимать, что проще тестировать, что быстрее, а что сложно и долго. Так, они смогут какие-то моменты упростить или помогут автоматизировать какие-то процессы.

Задача сделать так, чтобы повторные баги исчезли, а встречались только новые. Как это сделать, надо смотреть на месте, это потребует взаимодействия всех участников разработки. И это задача всей команды разработки.

Заключение.

Качество игры (продукта). Как измерить качество текущей версии игры?

Оценка со стороны дефектов. Есть категории дефектов: критичный, блокирующий, важный, не важный, визуальный, косметический и т.д. Каждая команда вырабатывает свою классификацию дефектов. Фиксируем числовые показатели дефектов по версиям игры, убираем починенные, добавляем найденные. Смотрим в прогрессии - баги уменьшаются? Нет критичных? Нет блокирующих - качество улучшается. Появились? Ухудшается качество.

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

Статья получилась огромная, на этом всё. Хотелось еще рассказать как тестировать проект честным QA, как решать баги ДО их возникновения. Как использовать автотестера. Но, это получится еще такой же объем. Кто это всё читать будет...

У кого какие вопросы, задавайте в комментариях, постараюсь ответить. Тем более, если я где не прав и всё не так - буду рад услышать комментарии.

Snowrunner сложная игра, как сочетание физики, узлов машины и уровня игры с бездорожьем. И это простая игра. В ней нет ИИ поведения актёров, нет сюжета и сюжетных поворотов, нет массы NPC с симуляцией дневного жизненного цикла и кучей анимаций, нет многообразия брони, оружия и заклинаний, которые надо уравновешивать между собой, нет особых навыков персонажа игры. Много чего нет, а то что есть - должно быть проверено и протестировано.

Как и где выучиться на тестировщика?

Я предлагаю пройти тест https://www.rstqb.org/ru/istqb-downloads.html?file=files/content/rstqb/downloads/ISTQB%20Downloads/ISTQB_CT-GaMe_SampleExam_Release_v1.0.1_RU.pdf&cid=35886

Запишите ответы и сравните с правильными https://www.rstqb.org/ru/istqb-downloads.html?file=files/content/rstqb/downloads/ISTQB%20Downloads/ISTQB_CT-GaMe_SampleExam-Answers_Release_v1.0_RU.pdf&cid=35886

Я без подготовки набрал 72%, вы наберете точно больше. После этого уже и решайте интересно вам этим заниматься или нет. Можете посмотреть программу обучения https://www.rstqb.org/ru/istqb-downloads.html?file=files/content/rstqb/downloads/ISTQB%20Downloads/ISTQB_CT_GaMe_Syllabus_Release_v1.0.1_RU.pdf&cid=35886

Или просмотрите все доступные документы https://www.rstqb.org/ru/istqb-downloads.html

Затем, можно сдать экзамен на сертификат, если есть такое желание. Не совсем просто, но можно.

Баги Snowrunner:

(физика) дикий урон по модулю при касании плит или мусорных куч, не может машина чуть коснувшись преграды потерять всю подвеску, колесо и половину бака.
(физика) шоссейные шины на асфальте не работают.
(физика, механика) кустики из адамантия и ветки деревьев, которые отталкивают грузовик. Могут опрокинуть многотонный грузовик. Кустики еще любят массово плодиться. Я встречал такой баг на Висконсине, когда под машиной начали расти кусты. Спас машину эвакуацией, дергать не стал.
(физика) дорожные знаки, протыкающие машину и методично убивающие её.
(UX) электрические опоры без точки зацепа лебедки. Это же опоры, они довольно глубоко вкопаны. Это столбы, зацепиться не должно быть никаких проблем.
(UX и механика) автопочинка, автозаправка модулей в гараже на сложном режиме игры при переборе модулей или при смене и установке вновь. Можно поменять колёса и "починить" подвеску или двигатель.
(UI, UX, механика) отсутствует ремонт корпуса машины на сложном режиме по отдельной кнопке. Вариант: сделать починку внешнего вида при стоянке машины в гараже, допустим за игровые сутки. Как я устал ездить на жёванных машинах.
(UX) дерганье камеры при проезде по мостам или рядом со зданиями.
(UI, UX) неудобная камера крана. Максимально неудобно управлять большим краном. С манипулятором еще более-менее. У крана нет фары для освещения рабочей области (ни у одного крана). И надо убрать скачки камеры рядом со зданием и её привычку, чуть что отпрыгивать в здание.
(UX) убрать механизм автопереключения заданий при переходе с карты на карту, я сам знаю какое задание делаю и сам переключу, если надо будет. Да, проблема есть с поручениями, привязанными к карте - сделать их глобальными по региону с отметкой на какой карте задание.
(UI, UX) при выполнении этапа состязания убрать оповещение в виде черной полосы прям на активной части экрана. Необходимо её переместить, сделать полупрозрачной, убрать совсем. Я тут в гонке участвую, а мне шарфом глаза закрывают.
(UI, UX) метки точек зацепа для лебедки и крана должны отличаться по цвету: прочные деревья, кустики, другая техника, груз. В мешанине листвы сложно выловить прицеп или машину пока не передергаешь все кустики.
(UX, механика) автоматическая лебедка, исправить алгоритм выбора цели, хочется более адекватного выбора цели и прицеливания.
(UI) цифра найденных машин в профиле игрока частенько "ошибается".
(механика) меньше гонок и ферм, больше перевозки грузов по бездорожью. Эксперименты возможны, но они должны быть оправданы. Возможно часть игроков со мной не согласятся, я видел любителей гонок в Snowrunner. Любители фермы не попадались.
(UI, UX, механика) необходим механизм взаимодействия в сетевом режиме, пусть это не будет полноценный чат, пусть будет набор иконок со статусами, что бы твой напарник видел какое задание ты выполняешь, какой груз везешь, какие у тебя сложности в данный момент, нужна помощь или нет и т.д. Горючку везти, запчасти или кран.
(UX) отсутствует информация какой полуприцеп какое седло требует.
(UX) отсутствует информация какой груз сколько слотов занимает.
(UX) показатели машин A+, B-, S ничего не показывают. Ладно, S показывает, типа топ, некуда стремиться. А остальные просто буковки.
(механика) при игре в коопе теряется одно задание, а именно одно состязание, а конкретнее на Амуре и на Аляске. Состязание на перевозку машин или бочек отваливается.
(AI?) машина на лебедке следует за ведущей машиной, а не за точкой зацепа. Можно следить за следом ведущей машины. Ведешь машину и собираешь все столбы у дороги.
(графика) отображение следов машин вызывает конфликт с ландшафтом (z fighting)
(UI, UX) Меню машины (V):

при управлении краном делать элементы интерфейса прозрачными. Надо лебедку зацепить, точка зацепа попадает под элемент интерфейса - мучайся. Надо груз зацепить краном, а специальная панель внизу треть экрана закрывает. Мучайся, лови точку между элементами интерфейса.
добавить информацию по машине, а именно полная информация по тюнингу. Отдельно, статистика по машине - пробег всего, в этом регионе, количество выполненных заданий, заработано денег и опыта, съедено сколько топлива, наиграно сколько часов, именно на этой машине. Часть информации дублировать в кабине, как пробег.

(UI, UX) карта:

гараж должен находиться вверху списка.
машины игрока должны находиться вверху списка.
задания... из первой вкладки убрать или перенести в группу, закрытую по умолчанию. Понятно, что это навигация по точкам интереса на карте. Лучше бы убрать, я не вижу ни одного сценария использования перечня заданий на первой вкладке карты.
прицепы, квестовые машины... убрать или перенести в группы, закрытые по умолчанию.
точки с грузом, перенести в группу, закрытую по умолчанию.
окно информации по машине загораживает карту, попробуйте рассмотреть на карте машину, за этой табличкой ничего не видно, попробуйте поставить навигационную метку рядом - не получится.
сложно выбрать одну машину, когда две рядом стоят или рядом с гаражом.
добавить функцию эвакуации машины прямо с карты, поможет эвакуировать машины не переходя на карту.

Отдельный ворох багов при сетевой игре.
Второго и третьего сезонного пропуска у меня нет, дальше без меня.

В общем, поработать бы разработчикам над UI, UX и физикой и конфетка получилась бы.

Всем удачи!

#gamedev #testing #gametesting #qa #qc #snowrunner