Стратегия тестирования

July 12, 2019

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

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

С чего начать изучать игру?

Задайтесь вопросом, какие у вашей игры бизнес-цели, простыми словами - чего хотят добиться по результатам её релиза те, кто принимает ключевые решения. Заработать много денег, скажете вы (или они). Привлечь миллионы игроков. Неплохо, но мало! Ваша цель - понять, в чём идея, какой опыт игра должна передать, как именно и какими средствами развлекать и вовлекать игрока. Зачем это вам? В первую очередь это должен знать и понимать product owner, но вам важно работать в связке с ним, иначе вы будете изучать что-нибудь не то, искать риски не там, пропускать критичные баги.

Какая ЦА? Попытайтесь изучить её всеми доступными способами, от общения с маркетологами до личного знакомства. Постарайтесь думать как ЦА. Что для неё важно? Всегда держите это в голове и из этой позиции не выходите. Регулярно обновляйте свои о ней знания и понимание - через общение с игроками, плейтесты, изучение аналогичных игр. Потому что важно не то, чтоб вы нашли какие-нибудь баги, а чтобы ваши критичные баги не нашли игроки и не бросили играть после этого. А чтобы это предотвратить, нужно самому стать игроком.

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

Что для игры уже готово?

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

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

Теперь смотрим, как в команде составляются требования.

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

Сделать главное меню.

Главное меню открывается по клику на кнопку и нажатие F10.

В главном меню такие-то пункты, при нажатии на которые происходит то-то.

[Макет / референс / скриншот]

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

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

Почему я не пишу "подготовьте тест-кейсы" или "сделайте чеклисты"? Потому что этого мало и начинаем мы тестировать не с них.

Дальше займёмся тест-аналитикой ваших требований. Эту тему я тоже затрагивала, но давайте подробнее. Что ищем?

Логические несостыковки. Можно ли вообще сделать то, что описано? Разместить кнопку там, где ожидается? Пойти текущей локации в ту, что описана в квесте? Эта механика развлекает? Если не очень, была ли такая цель? Укладывается ли этот NPC в лор? Передаёт ли фича нужный экспириенс? Юзабилен ли интерфейс? Не взорвите себе голову, но главные для вашей аудитории вопросы точно нужно выделить и задать.

Вот о чём работа тестировщика. О том, чтобы постоянно задаваться вопросами, сомневаться, валидировать. Изучать. Хотя часто принято хохмить, что мы игры ломаем (или всерьёз думать так, госпадя).

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

Код

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

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

Игровой процесс

Здесь сильно зависит от того, что именно у вас за игра, но у всех игр есть core loop. Сходите к своему геймдизайнеру, чтобы узнать, из чего он состоит. Например: взятие квеста - поиск NPC - убийство монстра - сбор лута - сдача квеста NPC. Распилите его на отдельные системы, с которыми взаимодействует игрок в процессе. Хорошо, если это уже сделано, а если нет, составьте схему, как это происходит. Все эти системы вы будете тестировать и не помешает провести интеграционное тестирование взаимодействия между ними (но в отдельных случаях это могут автоматизировать разработчики).

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

Текстуры, коллизии, модели, шейдеры

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

Интерфейс

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

Начало и завершение игры, сохранение, загрузка

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

Баланс

Какие циферки и где. Гляньте, как в табличках у гд считается урон, за что выдаются награды, какие виды оружия и как работают, какие монстры есть, какие нейтральные существа. Всё это тоже нужно проверять. Системно - скорее всего автоматизацией и вероятно, на стороне гд, в контексте игрового процесса - уже через тестирование. Здесь с вас ещё и всякие философские вопросы, вроде того, не велика ли эта цифра на таком-то уровне сложности и этапе, легко ли читается в интерфейсе и не злит ли красный (но за этим уже почти наверняка понадобятся плейтесты).

Возрастные ограничения, информация о билде, локализация

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

Каждый ваш билд должен корректно подписываться текущей версией, которая принята по вашему внутреннему версионированию. Он должен инсталлироваться и запускаться на выбранном и предусмотренном языке. В нём не должно быть материалов, которые закопирайчены другими компаниями или не подходят под целевые возрастные ограничения - скажем, глубокие V-образные вырезы в одежде в игре 8+ вы не пропустите. Не пропустите же, правда?

Важное. Если вы загружаете игру на какую-либо площадку - EGS, Steam, GOG, что угодно - обязательно проверьте, что после этого она скачивается, запускается и ваш смоук-тест продолжает быть "зелёным".

Про смоук-тест и регресс

Happy path составили? Берёте его и по нему пилите смоук-тест. Самые критичные тесты, все шаги, по которым обязательно-обязательно пойдёт ваш игрок. И снова - игра запускается, начать её получается, кор луп на одном примере работает, главные фичи интерфейса, тарампампам. А в регресс суём то же самое, плюс всё остальное, если влезет. Это если коротко. Возможно, ещё напишу об этом подробно. И про автоматизацию. И про нагрузку.

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

Спасибо за внимание!

Канал Тестирование пандорова ящика https://t.me/qa_yashik

Поддержать на patreon и подписаться на выпуски раз в 10 дней https://www.patreon.com/qa_yashik

Второй канал про игры и сериалы https://t.me/bringinyourgames