Александр Торговкин

Тестирование видеоигр, или Легкий способ попасть в геймдев

© Торговкин А.А., текст, 2024

© Оформление. ООО «Издательство «Эксмо», 2024

* * *

Благодарности

Автор выражает признательность людям, оказавшим помощь при подготовке этой книги.

Компании Saber Interactive[1] и лично:

Виктору Гляненко

за веру в проект подготовки специалистов в области игрового тестирования, за поддержку при подготовке материалов и рецензирование книги;

Нине Резниченко

за массу полезных замечаний и жизненных историй, которые, несомненно, сделали изложение материала более интересным;

Даше Касимановой

за оценку материала, независимое мнение и помощь в структурировании материала;

Максу Филиппову

за энтузиазм при рецензировании материала и примеры из жизни тестировщика, без которых не удалось бы раскрыть всю суть профессии.

Компании Bytex[2] и лично:

Вадиму Луковатому

за апробирование материала еще до публикации книги и подтверждение правильности изложенных в ней мыслей на практике;

Сергею Унгеру

за экспертизу при описании специфики тестирования на разных игровых платформах;

Наталье Шевяковой

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

RSTQB[3]

и лично:

Андрею Конушину

за вдохновение и демонстрацию того, что можно добиться многого при желании и правильной организации дела;

Александру

«Дедушке русского тестирования» Александрову за мудрость, демонстрацию абсолютного спокойствия в любой ситуации и десятки часов совместной работы над силлабусом ISTQB® GaMe Tester;

Павлу Шарикову

за энтузиазм и массу бесподобных примеров для подготовки по программе ISTQB® GaMe Tester, которые позволили сфокусироваться и не расплескать мысль при обработке материала.

Моей дочери Маше

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

А также всем, без кого публикация этой книги была бы невозможной.

От автора

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

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

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

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

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

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

Желаю удачи!

Глава 01. Путь в тысячу ли начинается с первого шага

– А далеко до этой комнаты?

– По прямой – метров 200. Да только тут не бывает прямых.

S.T.A.L.K.E.R.

• Почему игры необходимо тестировать?

• Чем отличается игра от другого программного обеспечения?

• Чем занимается тестировщик игр?

• Что нужно знать, чтобы стать тестировщиком?

• В чем смысл 7 принципов и 5 мифов тестирования?

Практически на любом промышленном предприятии был отдел, который назывался ОТК. В нем, как правило, трудились люди, проработавшие на этом предприятии очень солидное время и знавшие от и до не только выпускаемую продукцию, но и все нюансы ее производства. Название отдела расшифровывалось как «отдел технического контроля», а его сотрудники каждый день приходили на работу, чтобы искать в продукции, которую выпускало их любимое предприятие, не полезные качества, которые помогли бы ее продать, а… дефекты и недостатки. Солидные дяденьки и тетеньки брали детский велосипед, присоединяли колесо передачей к двигателю и наблюдали, как оно вращалось по много часов подряд, имитируя долгую поездку на дачу и обратно. Если в процессе испытаний происходило что-то, не похожее на нормальную работу велосипеда (а о том, как ДОЛЖЕН работать велосипед, эти люди знали все), сотрудники ОТК скрупулезно фиксировали эти случаи в специальных документах, попутно добавляя информацию о том, по каким причинам такое могло произойти и что стало причиной брака.

А ты помнишь старые велосипеды? Стальная рама, кованая «звездочка», «неубиваемые» педали, цепь, которая удержит и быка. И через 30 лет такой велик скрипит, но едет без единой поломки. Новый велосипед, с его тридцатью тремя скоростями, пневмоподвеской, подшипниками, звездочками и тормозами, над которыми трудились десятки инженеров, хотя и позволяет нам ехать гораздо быстрее, однако более подвержен различным «болезням». Это и понятно. Чем сложнее система, чем больше в ней элементов, чем чаще они взаимодействуют друг с другом, тем более она уязвима для различных поломок.

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

Развиваются не только велосипеды; развивается вообще все. Все становится сложнее, быстрее, технологичнее. И компьютерные игры – главная цель обсуждения в этой книге – не исключение. Стремительное развитие игровой индустрии привело к их распространению на множестве различных платформ. Игры стали масштабнее, реалистичнее и требовательнее к техническим ресурсам. Как и все люди, разработчики компьютерных игр допускают ошибки в работе, а чем затейливее становятся применяемые технологии, тем больше дефектов может возникнуть при их использовании. В то же время аудитория игроков значительно увеличилась, стала более искушенной и требовательной к качеству. Они хотят еще большей реалистичности, новых технологий, новых ощущений! И поскольку они платят за это довольно большие деньги, они вправе ожидать качественный продукт.

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

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

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

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

• Графическая подсистема

• Звуковая подсистема

• Подсистема игровой логики

• Подсистема искусственного интеллекта

• Физическая подсистема

• Подсистема взаимодействия с пользователем

• Подсистема хранения данных и др.

А еще не забудь про историческую достоверность в играх, соответствие прототипу и локализацию.

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

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

Ты скажешь: «Получается, что стать игровым тестировщиком невероятно сложно?» И да и нет! Всему можно научиться, все знания систематизировать и каталогизировать, если подойти к этому процессу правильно.

После выхода Cyberpunk 2077 пользователи базовых версий PlayStation 4 и Xbox One пожаловались на практически неиграбельные версии продукта. В версиях для обеих консолей наблюдались графические артефакты, падения частоты кадров и частые подзагрузки окружения и текстур. По данным Digital Foundry, Cyberpunk 2077 на PlayStation 4 работает с разрешением 720–900p (для сравнения, на PlayStation 4 Pro разрешение игры держится в районе 1080p), а частота кадров при этом в некоторых местах падает до 15.

14 декабря 2020 года компания CD Projekt RED официально прокомментировала ситуацию, извинившись за проблемный старт и анонсировав работу над двумя большими обновлениями, которые должны были выйти в январе и феврале 2021 года и были призваны исправить самые серьезные проблемы игры на консолях предыдущего поколения. Также студия пообещала вернуть всем желающим средства, потраченные на покупку игры.

Чтобы понять, чем занимается игровой тестировщик и кто это такой, давай попробуем разобраться с одним из определений этой профессии. «Тестировщик – это специалист, который занимается тестированием программного обеспечения с целью выявления ошибок в его работе и повышения уровня общего качества продукта». Если честно, понятнее не стало. Может быть, нужно почитать определение тестирования? «Тестирование – это процесс проверки соответствия заявленных к продукту требований и реализованной функциональности, осуществляемый путем наблюдения за его работой в искусственно созданных ситуациях и на ограниченном наборе тестов, выбранных определенным образом». О! Это уже лучше, и можно попробовать разобраться. «Процесс» означает, что мы занимаемся этим некоторое время и в рамках этого занятия происходит последовательная смена различных состояний.

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

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

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

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

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

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

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

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

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

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

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

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

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

Если ты мечтал попасть в геймдев, чтобы создавать, то, став тестировщиком, ты должен быть готов услышать факт № 2: твоей основной задачей будет разрушать, находить способы «сломать» игру, обнаруживать в ней изъяны – и чем больше, тем лучше. Но, разрушая игру, ты делаешь ее лучше, избавляешь ее от зловредных багов, находясь на первом рубеже защиты.

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

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

1.1. Как устроена профессия?

Нужно понимать, что тестирование – это профессия и, как любая другая профессия, требует времени для овладения ею. Овладение профессией в долгосрочной перспективе проходит по нескольким этапам.

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

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

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

Конечно, не любой может стать тестировщиком. Давай посмотрим, какие качества и знания могут помочь сделать первые шаги в профессии. Выше я говорил о том, что тестирование – это, по сути, поиск расхождений между ожидаемым результатом и фактическим при эксплуатации какого-либо объекта в определенных условиях в ограниченных временных рамках. Хотя некоторые специалисты не согласны с таким определением, считая, что пользователь имеет право ожидать всего чего угодно и на основании своих «хотелок» записывать в дефекты то, что таковым не является. Но я исхожу из того, что пользовательские ожидания от игры основаны не на оторванных от реальности фантазиях, а на чем-то связанном с:

1. игровым опытом;

2. пониманием жанровых особенностей игры;

3. здравым смыслом;

4. общими (фоновыми) знаниями.

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

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

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

• более опытные коллеги, которые могут подсказать и помочь в сложной ситуации;

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

• похожие между собой игры (Doom, Quake, Unreal и т. д.);

• ранние версии игры (серии игр Diablo, Warcraft, Call of Duty и т. д.);

• общие знания (например, в области физики, химии, истории и т. д.);

• знания в области игровой разработки (например, понимание процесса создания 3D-моделей, анимации, гейм-дизайна, левел-дизайна и т. д.).

Как ты догадываешься, все вышеперечисленное помогает нам лишь понять, что ждать от конкретного игрового продукта, что является его «нормой». Это как норма частоты сердечных сокращений или показатели артериального давления, с которыми мы сравниваем свои измерения и, если они отличаются, начинаем беспокоиться и идем к врачу. То есть для того, чтобы сделать вывод о том, имеем ли мы дело с дефектом, нам нужно получить реальный результат для сравнения с ожиданиями. А еще определить, в каких подсистемах игры чаще всего бывают скопления багов. А еще организовать свою работу так, чтобы потратить минимум времени при наилучшем тестовом покрытии (то есть проверить в игре как можно больше). А еще… много чего еще.

Вадим Луковатый, заместитель руководителя отдела Bytex

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

Тут тебе пригодятся знания в следующих областях.

• Теория тестирования (нужно знать методологию, разные виды тестирования, терминологию и многое другое).

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

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

• Инструменты тестирования (например, для поддержки и управления процессом тестирования или снятия скриншотов с экрана, записи видео или сохранения необходимой информации).

• Модели разработки (чтобы понимать место тестирования в процессе разработки).

1.2. 7 принципов и 5 мифов тестирования

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

1. Тестирование демонстрирует наличие дефектов, а не их отсутствие

Это означает, что, потратив 150 часов на тестирование игры, ты все равно не сможешь сказать, что в ней нет дефектов. Как ни тяжело это признавать, но ты просто на текущий момент не нашел их. Уверен, что у тебя для этого были веские причины: не было всего нужного оборудования (во всех его многочисленных конфигурациях) или не было достаточно времени. Одним словом, гарантировать, что в игре нет багов или того, что они не появятся на каком-то оборудовании или при каких-то очень специфических обстоятельствах ты, к сожалению, никак не можешь. Задача тестировщика – придумать такие сценарии использования игры и в таком количестве, при котором они максимально полно покроют ее функциональную и нефункциональную области и позволят найти дефекты в них.

2. Исчерпывающее тестирование недостижимо

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

3. Раннее тестирование сохраняет время и деньги

Большинство проектных менеджеров подтвердят, что ресурсов всегда не хватает. Не хватает квалифицированных сотрудников, необходимого аппаратного обеспечения, денег и времени, чтобы с минимумом проблем завершить проект. Они также подтвердят, что ошибка, сделанная на раннем этапе разработки, может привести к серьезным последствиям на более поздних этапах. А учитывая то, что ресурсов и так не хватает, последствия ранних ошибок могут стать катастрофическими. Одна из главных задач и одно из самых ценных умений тестировщика – понимание и обнаружение первопричин дефекта, то есть самых ранних действий, которые и привели к возникновению в игре бага. И поскольку любой проект развивается в рамках определенных стадий, то можно только представить, к каким последствиям приведет ошибка, сделанная на этапе разработки требований. Все усилия разработчиков по реализации задач, основанных на ошибочных требованиях гейм-дизайнера, будут перечеркнуты, поскольку они будут также ошибочными по определению. Есть ли выход из подобной ситуации? Конечно! Тестирование должно начинаться как можно раньше. В разработке игр – часто даже раньше разработки требований, еще на этапе концепции (идеи), а иногда и еще раньше – на этапе гипотезы, когда принимается решение о том, стоит ли вообще начинать разработку продукта на текущем этапе.

4. Кластеризация дефектов

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

5. Парадокс пестицида

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

Виктор Гляненко, QA-директор Saber Interactive

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

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

6. Тестирование зависит от контекста

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

7. Заблуждение об отсутствии ошибок

Даже если представить невозможную ситуацию, при которой были найдены и исправлены 100 % дефектов (мы помним, что такое невозможно в принципе!), не будет никаких гарантий того, что тестируемая нами видеоигра будет успешной у пользователей. Наша работа – обеспечить качество продукта, но привлекательность самого продукта мы обеспечить не в силах.

Ты скажешь: «Ладно, я понял, что не все так просто и что тестирование – это настоящая профессия, которая, как любая другая, требует времени на овладение и приобретение опыта, чтобы стать настоящим профессионалом. Но скажи честно: я что, буду тестировать игры до 60 лет? Я с трудом представляю себе дедушку, который увлекается тем же, что его внуки, и днями напролет торчит в компьютере, играя и тестируя, тестируя и играя».

Среди моих коллег есть поговорка: «Нет ни одного тестировщика, который не хотел бы стать разработчиком». И это вовсе не значит, что тестировщики стоят на более низкой ступени эволюции в игровой индустрии. Это значит, что ребята, которые стремятся любым способом попасть в игровую индустрию, не понимают, что тестирование – это важная и неотъемлемая часть разработки, без которой последняя невозможна, и имеют весьма отдаленное представление о связях профессий в индустрии. Кроме того, у большинства разработка ассоциируется с программированием и заблуждением о том, что программисты – это и есть люди, которые целыми днями занимаются креативом. На самом деле это миф № 1 в игровой индустрии, который необходимо развеять.

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

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

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

Миф № 2: лучшие тестировщики получаются из лучших игроков. Это не так. Да, тестировщики проводят сотни и тысячи часов за игрой, но, как правило, у них нет предпочтений, они «всеядны». Они исследователи. Им нравится копаться в играх, развиваться и получать достижения, а не совершенствоваться в искусстве дуэли. Тестирование – это дисциплина, умение переключаться в режим, в котором получение удовольствия от игрового процесса не является больше основным. Это способность проходить один и тот же путь десятки раз, отслеживая на нем малейшие дефекты. Кроме того, ты должен быть довольно настойчивым, потому что собираешься играть в сломанную и, возможно, скучную и часто незаконченную игру просто потому, что хочешь, чтобы она была качественной и доставляла удовольствие другим людям. Геймеры, которые ставят перед собой цель добиться победы и стать лучшим на игровой арене, скорее, испытают разочарование от такой работы.

Миф № 3: тестировщики – в подавляющем большинстве случаев мужчины. По собственному опыту скажем, что это утверждение не имеет под собой никаких оснований. По моим наблюдениям, пропорция скорее выглядит как 65 к 35 или даже 60 к 40 в пользу мужчин, но при этом девушки часто гораздо более успешны в профессии. Возможно, это связано с большей устойчивостью женской психики к стрессам, большей внимательностью к деталям, терпеливостью и настойчивостью.

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

И, наконец, миф № 5: игровое тестирование – это удел молодых людей, пока еще не получивших образования и могущих себе позволить образ жизни, сочетающий несложную работу и развлечение. На самом деле это совсем не так. В последние годы игры стремительно меняются: они становятся сложнее, технологичнее и, самое главное, становятся очень-очень похожими на реальный мир. Во время тестирования таких игровых продуктов в качестве ожидаемого результата часто выступает наша реальность со всеми ее законами. И нужно очень хорошо понимать, как устроена эта реальность. Без жизненного опыта это, увы, невозможно. Возможно, именно поэтому средний возраст тестировщика сейчас приблизился к 25–26 годам (а зачастую и гораздо больше).

Освободившись от этих навязчивых мифов, ты теперь можешь приступить к освоению нелегкого ремесла игрового тестировщика. Я помогу тебе освоиться с важнейшими, фундаментальными принципами и подходами в нашей профессии, помогу даже подготовиться в сдаче экзамена и получения международного сертификата игрового тестировщика ISTQB® Certified Tester Game Testing. Но опыт ты должен будешь приобрести сам. И я очень рассчитываю, что по прошествии времени ты войдешь в число лучших специалистов в области игрового тестирования.

Глава 02. Самая большая ошибка – не исправлять ошибки

Чем больше надежд мы возлагаем, тем сильнее может быть разочарование…

Genshin Impact

• Что такое дефект?

• Чем дефекты отличаются друг от друга?

• Что такое баг-репорт и для чего он нужен?

• Что такое критичность дефекта и как ее правильно определить?

• Что такое приоритет дефекта?

• Что такое жизненный цикл дефекта?

• Когда и почему появляются дефекты?

• Как снизить риск их появления?

• Где место тестирования в разных моделях разработки?

• Как тестировщик взаимодействует с заинтересованными лицами проекта?

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

Пришло время поговорить о дефектах подробнее, ведь баг багу рознь. Один может запросто привести к крашу[10] игры, а другой будет выглядеть как «невинная» опечатка в слове на кнопке. «Какая разница? – скажешь ты. – Любой баг – это враг, которого нужно беспощадно уничтожать!» Это правда, но, как ты помнишь, над игрой могут трудиться множество людей, которые заняты множеством важных дел. И, наверное, они не будут очень рады, если каждый раз, получая от тебя отчет о дефектах, они будут видеть там бескомпромиссное «Свистать всех наверх! Бросайте все дела и срочно исправьте опечатку в меню!» Дефекты можно классифицировать по ряду признаков. Зачем это нужно? Чтобы лучше понимать, насколько большую опасность для проекта они представляют и как нужно с ними бороться. Другими словами, чтобы правильно определять их критичность.

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

2.1. Отчет о дефекте (баг-репорт)

Отчет о дефекте (также известный как баг-репорт) – это документ, который описывает ошибку, неисправность или проблему, найденные в программном продукте, в том числе игровом. Это важный инструмент для команд разработки и тестирования, поскольку он помогает им понять, исправить и отслеживать проблемы в продукте. Это документ, который ты должен научиться разрабатывать в первую очередь. Отчет создается только для ОДНОГО дефекта.

2.1.1. Атрибуты отчета о дефекте

Описание дефекта, а фактически задача для разработчика, как правило, содержит следующие обязательные атрибуты.

1. Краткое описание (Summary)

2. Подробное описание (Description)

3. Шаги воспроизведения (Steps)

4. Ожидаемый результат (Expected Result)

5. Фактический результат (Result)

6. Критичность (Severity)

7. Приоритет (Priority)

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

Краткое описание (Summary) – название атрибута говорит само за себя. Задача тестировщика – максимально кратко и в то же время понятно описать найденный дефект. Иногда тестировщики говорят: «Всегда есть Description, где можно описать баг во всех деталях», но разработчики считают суперабилкой тестировщика именно его способность описывать баги кратко и понятно. Это объясняется простым фактом: в Jira и других баг-трекерах разработчик видит задачи списком, каждая задача представлена кратким описанием. Теперь представь, что таких задач (баг-репортов) несколько сотен, больше половины из которых непонятны без прочтения Description. Представь только, сколько времени потеряет разработчик для вникания в суть проблемы. И как он будет называть при этом тестировщика. Кроме того, при грамотном написании Summary в огромном списке задач довольно легко находить дубликаты.

Способность описать дефект в рамках поля Summary – действительно одно из главных достоинств и профессиональных навыков специалиста по тестированию. Есть несколько способов обучения этому навыку. Приведем три самых действенных и простых.

Метод «Что? Где? Когда?»

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

1. Что произошло и в чем суть неполадки?

2. Где был обнаружен дефект?

3. Когда и при каких обстоятельствах возник дефект?

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

Метод выделения ключевой информации

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

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

2. Внимательно прочитай свое описание и выдели из него ключевую информацию, то есть самые важные моменты.

3. Попробуй сложить эти ключевые моменты вместе.

То, что получится в итоге, и будет составлять Summary.

Метод тождественности атрибутов

Составь описание дефекта по следующей схеме.

1. Шаги воспроизведения

2. Ожидаемый результат

3. Полученный результат

Если все описано правильно, то «Полученный результат» и будет являться Summary дефекта. Если нужно, можешь добавить пару важных деталей.

Но вернемся к прочим атрибутам дефекта.

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

Следующие два атрибута – Шаги (Steps) и Ожидаемый результат (Expected Result) – берутся непосредственно из твоего тест-кейса[11], с помощью которого ты обнаружил дефект. Это и понятно. Разработчик должен сделать абсолютно то же самое, чтобы увидеть этот баг. О том, как проектировать тест-кейсы, я расскажу тебе чуть позже.

Фактический результат (Result) – это описание того, что ты увидел своими глазами, выполнив необходимые для проверки Шаги. Если он не отличается от Ожидаемого результата, мы можем быть уверены, что система функционирует как нужно. Любое отличие между Ожидаемым и Фактическим результатом будет означать только одно: перед тобой дефект.

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

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

Про эти два важнейших атрибута я расскажу более подробно чуть ниже.

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

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

Могут быть и другие атрибуты баг-репорта, крайне полезные для разработчика.

Повторяемость (Reproducibility)[12] – этот атрибут важен для определения Приоритета дефекта и показывает, насколько часто появляется дефект в определенных обстоятельствах, определяет его «назойливость». Он также дает понимание, что то, что ты описываешь, – действительно баг, а не однократный сбой неясной этимологии. С этим атрибутом необходимо быть очень внимательным. Часто тестировщики не видят разницы в оформлении повторяемости в процентном или числовом отношении. Однако есть разница, если баг имеет повторяемость 20 % (из 5 проверок) и когда он повторяется 2 из 5 раз. В первом случае повторяемость дефекта будет равной 1 из 5 раз, а во втором – в два раза чаще.

Дарья Касиманова, QA-менеджер Saber Interactive

Аналогом Reproducibility является Repro Frequency (частота воспроизведения) в описании дефекта компьютерной игры. Это мера, которая указывает на то, как часто возникает или воспроизводится определенный дефект или проблема в игре. Это важный параметр при тестировании и отладке игр: он помогает разработчикам определить, насколько критична проблема и как срочно ее необходимо решать.

Чем выше Repro Frequency, тем более часто возникает проблема и, возможно, тем более важно ее устранение, особенно если это критический дефект, который может повлиять на игровой процесс или создать негативное впечатление у игроков. Разработчики игр стремятся уменьшить Repro Frequency до минимума, чтобы обеспечить более стабильный и приятный опыт игры для всех пользователей.

Вложения (Attachments) – это материалы, иллюстрирующие проблему.

Для начала посмотрим, что именно может быть использовано в качестве Вложений.

1. Изображения

2. Видеофрагменты

3. Логи (файлы системных журналов)

4. Звуковой файл

5. Другие файлы

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

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

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

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

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

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

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

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

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

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

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

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

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

В идеале после чтения саммари бага и просмотра вложения (прикрепленный файл – скриншот, видео, логи и т. д) должно быть понятно, в чем проблема и как ее фиксить. Если при взгляде только на прикрепленный к багу файл понятно, в чем баг, то поздравляю, вы достигли вершины искусства. Не стоит пренебрегать скринами даже, казалось бы, в простых проблемах. Сделать скрин и прикрепить его к багу занимает всего пару секунд, а бонус выходит +100 к ясности.

Часто можно встретить баги с названиями вроде «Неправильное отображение иконки». У меня к таким багам сразу вопрос: что значит неправильное? А как правильно? Или «Работает некорректно». Хорошо, а как корректно? Почему бы сразу не написать, в чем проблема, избегая выход на такие абстракции?

Уточнив, в чем проблема (например, иконка отображается лоу-резно, с темными краями и т. д.), и прикрепив дополнительно скрин или видео, вы сэкономите время как себе (потому что за уточняющим вопросом придут к вам), так и исполнителю.

Мой совет: всегда старайтесь уйти от широких понятий или давайте конкретные числа и данные, если все же их используете. Например, вы описываете баг про Low FPS. Укажите в цифрах, сколько это Low – 10–15 (5 и т. д.)? Кому-то и 60 мало:)

2.1.2. Критичность дефекта (Severity)

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

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

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

2. Степень заметности для пользователя – насколько дефект заметен для большинства игроков[14].

3. Степень влияния на удобство использования – насколько дефект ухудшает удобство игрового процесса.

Только анализ всех этих факторов вместе позволит получить правильное представление о критичности бага.

С точки зрения критичности принято выделять следующие виды дефектов.

Blocker (Блокирующий, Блокер) – самый критичный и самый заметный дефект, который вызывает самые большие трудности при использовании игрового продукта. Более того, блокер, как правило, – это такой дефект, который не позволяет нам больше играть, и обойти это препятствие не представляется возможным. Помнишь синий экран смерти в Windows? Вот это как раз пример блокера! Другими примерами могут стать «вечный» фриз, утечка памяти и многие другие неприятные вещи. Но есть и хорошая новость для тестировщика: ты никогда не пропустишь блокер, если увидишь его, это просто нереально. Ты внезапно теряешь контроль над игровым процессом и получаешь его назад только после полной перезагрузки. Хотя и в этой ситуации, если подходить строго, блокеры можно разделить на софтлок (softlock) и хардлок (hardlock).

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

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

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

Critical (Критический) – этот баг очень похож на предыдущий. Он тоже может превратить игровой процесс в кошмар и выглядит как начало Армагеддона, но, в отличие от предыдущего дефекта, предполагает некий способ выхода из ситуации. Например, появляющееся каждые пять минут окно с ошибкой, останавливающее игровой процесс, можно закрыть, нажав Alt+F4, и продолжить игру.

В той же комнате, в которой ты оказался в первый раз, кроме запертой двери есть окно, в которое можно с трудом выйти. Люди не должны выходить в окна, но это альтернативный приемлемый выход из ситуации, не так ли?

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

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

Minor (Незначительный). Обычно такие баги не относятся к функционалу игры или влияют на него в очень незначительной степени. Тем не менее баг заметен и очевиден для тестировщика и для пользователя. Чаще всего так определяется дефект, который затрудняет нам удобство использования игрового продукта, раздражает игрока или связан с недочетами интерфейса. Очень часто в эту категорию попадают мелкие рендер-баги[15], отсутствие коллизий с какими-то неважными объектами на сцене и т. п.

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

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

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

2.1.3. Приоритет дефекта (Priority)

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

Как правило, приоритет дефекта бывает трех видов.

1. High (Высокий)

2. Medium (Средний)

3. Low (Низкий)

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

• Финансовые потери компании

• Репутационные потери компании

• Воспроизводимость дефекта

• Увеличение сроков разработки либо трудозатрат

Установка приоритета – это довольно сложный процесс, который отличается от определения критичности и относится к техническим аспектам. Приоритет вполне легко может быть определен по совокупности технических параметров. Давай рассмотрим несколько примеров.

Пример № 1. В игре только у одного персонажа имеется изображение свастики. Это дефект локализации; нужно определить его критичность и приоритет.

Дефект вообще никак не влияет на техническую сторону игрового процесса. Он малозаметен (есть только у одного персонажа) и не ухудшает удобство использования продукта. Здесь мы будем выбирать между Minor и Trivial в зависимости от того, насколько сложно найти этого персонажа в игре.

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

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

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

Еще один пример – высокая повторяемость дефекта. Если незначительный дефект становится чересчур назойливым для большого количества пользователей, то, скорее всего, стоит повысить приоритет и исправить его, пока это не переросло в более серьезную проблему. Как раз для этого и служит атрибут Reproducibility или Repro Frequency.

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

2.1.4. Признаки плохого баг-репорта

Отчет о дефекте – это фактически задача для разработчика по устранению выявленного тестировщиком дефекта. Для того чтобы задача была решена эффективно и быстро, она должна быть корректно сформулирована.

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

1. Персонаж погибает

2. Противник не атакует

3. Транспортное средство отказывается ехать[16]

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

1. Непредоставление точной информации, которая может помочь в устранении дефекта.

2. Непредоставление критически важной информации, например в какой тестовой среде проводилась проверка.

3. Обнаружение дефекта в функционале, не предназначенном для тестирования.

4. Предоставление в любых полях баг-репорта недостоверной информации.

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

6. Дефект содержит критику в сторону разработчиков.

7. Выставление заведомо неверного уровня критичности.

8. Отчет содержит большое количество языковых ошибок, не позволяющих понять смысл.

9. Непредоставление вложений: логов, дампов, скриншотов, без которых разработчик не видит дефекта.

10. Тестировщик не смог убедить разработчиков в критичности дефекта.

Сравни два примера ниже. Это два реальных баг-репорта, написанных тестировщиками-новичками. Какой из них ты считаешь более правильным?

Пример № 1

Пример № 2

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

2.2. Жизненный цикл дефекта (Defect Life Cycle)

Жизненный цикл дефекта – это период существования бага с момента, когда он был найден и описан тестировщиком, до момента, когда дефект был исправлен одним из игровых разработчиков. Схема ЖЦД важна для понимания того, что может произойти на этом пути. Часто эту схему называют модным словом workflow.

Жизненный цикл дефекта

Хотя из приведенной схемы все довольно понятно, давай рассмотрим ее детально.

Первый статус, который получает дефект после обнаружения и описания, – «Открыт». Этим ты ответственно заявляешь, что обнаружил нечто, что ты считаешь дефектом, и ставишь задачу по его исправлению одному из разработчиков. Дальше ты должен выбрать того разработчика, которого считаешь ответственным за появление этого бага в игре, и поставить эту задачу ему (выбрав из списка Assigned To). Потом наступает момент истины. Разработчик может отклонить баг по разным причинам, в том числе заявив, что это вообще не баг. А может быть, он просто не смог найти его по твоему описанию. Или ты назначил эту задачу не тому разработчику. Как бы то ни было, далее есть два пути: 1) согласиться с разработчиком и закрыть задачу и 2) не согласиться, внести исправления в задачу, если нужно, и переоткрыть (ReOpen) ее, назначив этому же или другому специалисту. Далее часть, описанная выше, может повторяться до тех пор, пока дефект не будет принят в работу (In Work). Кстати, в жизни это происходит гораздо быстрее, чем тут написано. Казалось бы, дальше у дефекта не остается ни одного шанса на выживание, и он получает статус «Исправлен» (Resolved). Но иногда при повторном тестировании тестировщик видит, что дефект не был исправлен или был исправлен не до конца, и тогда баг снова переоткрывается. Если же мы больше не обнаруживаем дефект после проведения повторного тестирования, то задача закрывается, а дефект помечается как исправленный.

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

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

2.3. Первопричины дефектов

Как видишь, определять критичность дефекта можно научиться довольно быстро. Но что делать дальше? Настоящий специалист по тестированию, кроме способности определить критичность (серьезность) дефекта, должен уметь четко сформулировать задачу по его исправлению и по возможности указать причину появления дефекта в игровом продукте[17]. От правильного определения первопричины дефекта зависит то, насколько точно он будет адресован конкретному специалисту для исправления и сама скорость его исправления, то есть приоритет дефекта.

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

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

Pre-Production (Подготовка к производству). Разработка любой игры начинается здесь. В течение этого этапа, который может длиться довольно долгое время, разработчикам нужно ответить на три главных вопроса.

• Что за игру мы собираемся делать?

• Зачем мы собираемся ее делать?

•Что нужно для ее создания?

Если мы не рассматриваем ААА-игру, то команда на этом этапе довольно небольшая. Это могут быть продюсер, гейм-дизайнер, художник и, может быть, программист (а в некоторых случаях это вообще один и тот же человек). Задачей продюсера на этом этапе будет управление проектом в целом и обеспечение его необходимыми ресурсами. Задача гейм-дизайнера – творчество; все его идеи воплощаются в документе, который так и принято называть GDD (Game Design Document), который станет основным игровым сценарием. А концепт-арт (то есть наброски, эскизы, ранние визуальные эффекты и т. д.) необходим для того, чтобы сформировать «художественный язык», «графический фон», или визуальную составляющую игры.

Давай подумаем, могут ли на этом этапе быть сделаны ошибки. Еще какие!

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

Если даже такая работа по проверке гипотезы была проведена тщательно и ответственно, нет никакой гарантии, что на этой стадии возможных ошибок удалось избежать. Представь себе, что перед тобой сидят четыре художника, которые получили от тебя задание нарисовать орка. Насколько будут совпадать их рисунки? Я думаю, что совпадение будет очень близко к 100 %. Орки – это часть вселенной Warcraft, и практически каждый игрок «в теме» скажет, что орк – это огромный, накачанный персонаж с клыками и пирсингом (даже на клыках), одетый в кожаный доспех, с огромным топором или молотом в руках и верхом на волке.

Орк, как его видят подавляющее количество пользователей

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

Поэтому концепт-арт создается также и для того, чтобы художники и моделлеры, подключаемые к проекту на последующих этапах, могли иметь общее представление о стиле и техники исполнения. На этом этапе важно провести художественное тестирование стиля концепт-арта для того, чтобы позже не получить набора не сочетающихся по стилю 3D-моделей[18].

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

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

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

Создание прототипа на этой же стадии нужно не только для того, чтобы продемонстрировать вашу идею инвестору, но и чтобы как следует протестировать ее. Большинство идей хоронятся как раз на этом этапе, поскольку не проходят тестирование и не дают нам ответа на вопрос: «Является ли идея рабочей и стоит ли это пытаться реализовать?» Хотя инвестор – как раз тот человек, который способен протестировать вашу идею и прототип беспристрастно и очень профессионально, ведь на кону будут стоять его деньги.

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

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

2. FPP (First Playable Product). В отличие от прототипа, дает гораздо лучшее представление о внешнем виде и игровом процессе. Конечно, он очень далек от финальной версии, но в нем «заглушки» уже заменяются нормальными моделями, добавляются интересные детали.

3. Vertical slice. Это фактически демоверсия игрового продукта, фрагмент игры. Играя в него, можно понять, как будет выглядеть игра целиком и какие механики в ней будут использованы. Как правило, такой продукт используется в маркетинговых целях или для представления инвесторам.

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

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

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

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

Для лучшего понимания сути давай посмотрим на то, как создаются и тестируются игры типа Angry Birds. Чтобы продемонстрировать суть игры, нам не нужны модели (в данном случае изображения) птиц, свиней и игровых ассетов. Всю игровую механику мы можем запрограммировать, используя геометрические фигуры разного цвета: красный круг, который увеличивает скорость при тапе по экрану, белый овал, из которого при тапе по экрану будет вываливаться другой круг с эффектом бомбы, и т. д. Также мы можем запрограммировать свойства всех строительных материалов: льда, дерева и камня. В это же время нашему художнику параллельно процессу программирования и независимо от него нужно нарисовать спрайты анимаций птиц в трех разных состояниях: обычном, слегка поврежденном и сильно поврежденном. На этом же этапе мы можем провести проверку и программной части, и моделей независимо друг от друга. А затем просто заменить красный круг в игровом движке на спрайты красной злой птицы. Нам останется только проверить, не возникло ли каких-либо дефектов при такой интеграции. Потом мы добавим и синхронизируем с действиями персонажей и объектов на сцене звуки. А после этого мы можем проводить тестирование игры как полноценной системы.

Пример программирования физики и коллизий без реальных моделей персонажей

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

Post-Production. На этом этапе нужно исправлять баги, которые находят пользователи, пока команда разработки продолжает работу по поддержке проекта. Если планируется выпускать дополнительный загружаемый игровой контент, тестировщику надо приготовиться к проведению повторного и регрессионного тестирования.

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

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

Стандартная модель коммуникации выглядит примерно так:

Адресант – это тот, кто передает сообщение, а адресат – тот, кто его получает. В процессе общения эти роли постоянно меняются, поскольку коммуникация – это не только передавать сообщение (например, говорить), но и получать его (слушать). Если человек не меняет роли, то коммуникация осуществляется с трудом или не осуществляется вовсе, поскольку для принятия решений требуется получение информации извне и ее критическая обработка. Отсутствие коммуникации приводит к возникновению ошибок, о которых я говорил в случае с рисованием дракона.

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

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

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

Сообщения передаются в какой-то среде, которая зачастую наполнена помехами. Это могут быть настоящие помехи на канале радиосвязи, из-за которых твой собеседник не слышит тебя и не понимает сути того, что ты стремишься сказать. А могут быть и более «хитрые» – например, слухи, которые распускают конкуренты для того, чтобы дезинформировать вашу команду и заставить сделать неправильные шаги.

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

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

Важно убедиться, что собеседник тебя хорошо понимает

В некоторых ситуациях, когда забывают сообщить об изменениях, это может стать фатальным

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

Еще одна причина появления дефектов в игровом продукте – ошибки разработчиков. Мы все люди, и нам свойственно ошибаться. Попробуй просто печатать пару страниц текста, например текста этой книги, в редакторе. Я поячти на 100 % уверрен, что в тектсе будут содержаться опечатки. А программист пишет сотни строк кода каждый день, пытаясь реализовать игровую логику, да еще оптимально использовать вычислительные ресурсы PC игрока.

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

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

1. «Графики» – 3D-моделлеры, риггеры, скиннеры, аниматоры, художники – занимаются реализацией графической части, одной из важнейшей в любой игре, воздействующей на игрока через органы зрения.

2. «Звуковики» – звукоинженеры, композиторы, аудиодизайнеры спецэффектов, аудиопрограммисты, актеры озвучки – полностью погружены в процесс формирования звуковой подсистемы игры, записывая и внедряя в игровой процесс все необходимые звуки.

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

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

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

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

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

Ошибки, возникшие на ранних этапах проекта, со временем начинают стоить слишком дорого

I – это идеальный проект, практически отсутствующий в природе. В нем не было допущено ни одной ошибки ни на одном этапе.

II – проект, в котором ошибки допущены только при непосредственной разработке. Говорит о том, что команда программистов была очень слабой. Впрочем, такая ситуация тоже практически невозможна.

III – в этом случае первые ошибки появились на этапе проектирования. Разработка, основанная на ошибочном проекте, ошибочна по своей сути. Нужно исправить ошибки проекта и провести разработку заново.

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

V – на этапе концепции не были выявлены дефекты. Это привело к ошибочным требованиям. Далее количество дефектов росло как снежный ком. Получившийся продукт не соответствовал ожиданиям клиентам и даже его создателей.

VI – самый печальный случай, но, к сожалению, распространенный среди инди-разработчиков. Гипотеза не была протестирована и то, что получилось, в конце оказалось никому не нужно.

2.4. Как снизить риски возникновения дефектов

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

2.4.1. Использование моделей и методологий разработки

В разработке программного обеспечения, в том числе и игрового, традиционно применяются три подхода.

1. Классические модели

2. Гибкие модели[19]

3. Сочетания классической и гибкой моделей

У каждого из подходов, как часто бывает в жизни, есть свои достоинства и недостатки. Давай разберем каждый из них подробнее.

Для начала нужно сказать, что ты, возможно, никогда не увидишь все существующие модели «вживую». Для этого есть масса причин: для применения некоторых необходимы определенные условия, например очень профессиональная, самоорганизующаяся команда «мастеров на все руки» или очень гибкий бюджет. Кроме того, некоторые из этих моделей существуют только в воображении их авторов или никогда не выходили за пределы конкретной компании. Еще одна причина – определенная путаница в головах у некоторых «продюсеров», которые зачастую путают понятия «философия» и «методология». Например, они отождествляют понятия Agile и Scrum, хотя последнее – лишь один из подходов-методологий при использовании гибкой модели.

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

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

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

Последовательная модель (на примере Waterfall model и V model)

У этой модели есть два свойства: 1) она известна человечеству с древнейших времен. Думаю, что постройка египетских пирамид велась с ее использованием, хотя описана она была только в 1970 году в качестве решения для управления усложняющейся разработки программного обеспечения; и 2) она похожа на водопад или водный каскад, хотя, как ты понимаешь, это сделано специально, чтобы дать ей запоминающееся название. Расположив фазы горизонтально или вертикально, мы не поменяем в этой модели ничего, кроме того, что на водопад она больше похожа не будет.

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

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

Использование этой модели предполагает знание ее плюсов и минусов.

Водопадная модель

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

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

Другой минус использования «водопадной» модели – высокая цена ранних ошибок. Другими словами, если на этапе тестирования ты обнаружишь дефект, связанный с проектированием, то все работы по разработке, вероятно, придется выполнять заново, поскольку функционал был разработан на ошибочных требованиях. Я говорил о таких ситуациях выше. Как же с ними можно бороться?

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

V-модель

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

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

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

Спиральная модель (Spiral Model)

Спиральная модель

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

Разработка продукта на каждой стадии (витке спирали) разработки программного обеспечения проходит всегда по четырем этапам.

1. Определение целей

2. Оценка рисков

3. Разработка и тестирование

4. Планирование

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

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

Совершенно противоположный по идеологии подход к разработке принято называть гибким (Agile). Считается, что он изначально появился как ответ на невозможность использования «водопадной» модели в сложных творческих проектах по разработке ПО. Один из центральных постулатов Манифеста Agile, на положениях которого основана вся философия гибкой разработки проектов, таков: изменения в проекте допустимы на любой стадии реализации. Для менеджеров – приверженцев классического подхода, как ты понимаешь, это делает управление проектом похожим на ад: все бюджетирование «идет лесом», сроки реализации проекта туманны, требования неясны. Но, если вдуматься, это и есть признаки типичного проекта по разработке видеоигры. Отчасти это и делает применение «гибких» методик в сфере разработки игр весьма распространенным.

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

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

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

Гибкая модель (на примере Scrum)

Когда речь заходит о гибких методологиях, практически у 90 % менеджеров в голове возникает одно слово – Scrum. Это одна из наиболее популярных итерационных моделей разработки ПО, относящихся к Agile. Методология хорошо задокументирована, и ты легко найдешь подробный материал для ознакомления. Я лишь кратко постараюсь осветить основные положения и процессы.

Основных ролей в Scrum три.

1. Владелец продукта (Product owner)

2. Команда разработки (Development team)

3. Scrum-мастер (Scrum master)

Владелец продукта (ВП) – это заказчик или представитель заказчика. Он обладает техническими знаниями в такой мере, чтобы формулировать требования к разрабатываемому продукту. Владелец продукта отвечает за формирование видения (vision) продукта и принятие окончательных решений. Инструмент ВП – Журнал Продукта (Product Backlog), который используется для записи требований к продукту в порядке их приоритета. В этом же журнале прописываются критерии готовности реализации требований (Definition of Done).

Роль Scrum-мастера отличается от менеджера продукта; это, скорее, капитан команды (кстати, термин scrum был заимствован из регби, где им обозначают схватку команд при розыгрыше мяча). Его основная задача – обеспечить выполнение требований методологии и постоянный ритм работы, а также уберечь команду от внешних мешающих работе воздействий. При этом он также разработчик и выполняет задачи по реализации проекта.

Команда разработки (КР) состоит из специалистов, задача которых – реализация задач по проекту и разработка финального продукта. Согласно идеологии Scrum к команде предъявляются следующие требования.

1. Команда должна быть способна к самоорганизации (и это понятно, ведь начальника в виде менеджера проекта или продюсера над ними нет).

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

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

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

Инструмент команды – Журнал Спринта (Sprint Backlog), в котором требования ВП преобразуются в конкретные задачи.

Итерация (стадия, временной отрезок), в рамках которой производится разработка продукта в Scrum, называется спринтом (Sprint). Спринт обычно составляет 1‒4 недели (40‒160 рабочих часов), и его продолжительность неизменна на всем протяжении разработки. Изменение продолжительности спринтов неизбежно приводит к потере командой рабочего ритма и снижению эффективности ее работы. Каждый спринт должен заканчиваться новой версией продукта (инкремент).

Итерация в Scrum

Спринт начинается с планирования, в ходе которого команда должна найти ответы на два вопроса: 1) какой объем работы можно выполнить в предстоящем спринте и 2) как она будет выполняться.

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

В течение спринта команда собирается на ежедневные «летучки»-совещания (Daily scrum), чтобы обсудить текущие проблемы.

Спринт завершается Обзором Спринта (Sprint Review), в рамках которого Владелец продукта предъявляет инкремент, то есть новый билд продукта с разработанным в рамках спринта функционалом.

После этого команда проводит Ретроспективу Спринта (Sprint Retrospective). На ней определяются области работы, требующие улучшений.

Такой порядок повторяется в конце каждого спринта.

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

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

2. правильно оценивать время выполнения задачи;

3. отслеживать прогресс по спринтам.

Для оценки времени на выполнение задачи ты можешь использовать любой из методов, изложенных в параграфе «Планирование ресурсов». А для отслеживания прогресса по спринтам неплохо подходит диаграмма сгорания (Burndown chart). Она сравнивает планируемую скорость работы команды с реальной.

Особенность Scrum – упор на самоорганизующуюся, многофункциональную команду. Это позволяет снизить затраты на координацию и управление, но может привести к повышению затрат на отбор персонала, его мотивацию и обучение.

Пример диаграммы сгорания

Кроме того, несмотря на кажущуюся простоту, Scrum часто используют неправильно. Для таких случаев существует даже особое понятие – Ограниченный Scrum (ScrumBut); это использование лишь части принципов Scrum. Такой подход приводит к существенному ухудшению производительности по сравнению даже с отсутствием методологии. Классические примеры ScrumBut:

1. отсутствие критериев готовности (Definition of Done);

2. неодинаковая длительность спринтов;

3. длительность спринта более 4 недель;

4. проведение «летучек» (Daily Scrum) не каждый день;

5. отсутствие ретроспектив и т. д.

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

Один из примеров такого подхода – использование V-модели для создания прототипа игры с последующим переходом к Scrum для цикличного наращивания функционала и развития проекта. В этом случае роль группы обеспечения качества возрастает: тестирование проводится с самого начала проекта и далее тестируется результат каждой итерации (спринта).

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

2.4.2. Использование ветвления (Branching)

Разработка в разных ветках (branching) – это методология, которая позволяет команде разработчиков работать над различными версиями кода в отдельных ветках, которые могут быть слиты в основную (main branch) после того, как функциональность будет разработана и протестирована. Это позволяет разработчикам изолировать свои изменения от других членов команды, ускорить процесс разработки и снизить вероятность конфликтов в коде.

Ветки могут создаваться для различных целей.

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

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

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

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

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

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

Пример ветвления при разработке

Ниже приведены некоторые преимущества и недостатки ветвления в разработке программного обеспечения.

Преимущества

• Изоляция изменений. Каждая ветка – это изолированная линия разработки, что позволяет разработчикам работать над изменениями без влияния на другие части кода. Это позволяет снизить количество конфликтов при слиянии изменений в основную ветку.

• Параллельная разработка. Можно работать над разными частями приложения одновременно, что ускоряет процесс разработки.

• Управление версиями. Каждая ветка может быть отдельно версионирована, что упрощает управление версиями приложения.

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

Недостатки

• Увеличивает сложность управления кодом, поскольку каждая ветка может иметь свои особенности и уникальные изменения.

• Увеличивает необходимость в тестировании и интеграции каждой ветки перед ее объединением с основной веткой.

• Может привести к проблемам слияния веток, если различные члены команды вносят изменения в одни и те же файлы.

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

2.4.3. Взаимодействие тестировщика с заинтересованными лицами

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

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

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

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

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

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

• Прямые и косвенные пользователи напрямую используют игру (то есть они конечные пользователи).

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

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

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

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

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

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

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

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

Пример предоставления информации о дефектах

Сергей Унгер, QA-менеджер Bytex

QA – это про общение. Много общения. Рядовые QA обычно взаимодействуют со своим непосредственным руководителем – лидом (QA Project Lead) и с разработчиками (кодерами, левел-дизайнерами, UI/UX-программистами и т. д.) через системы отслеживания ошибок (баг-трекеры) или напрямую через мессенджеры/почту/звонки. Бывают случаи, когда рядовые QA тоже находятся в прямом контакте с продюсерами, но обычно в этом нет острой необходимости.

Если ты лид (или тест-менеджер), основное общение происходит на соответствующем уровне – с продюсерами, лидами и менеджерами других отделов, работающих над проектом. Лиды есть практически у всех рядовых сотрудников, у программистов, у дизайнеров и т. д. Это основное ответственное лицо, отвечающее за работу команды. А продюсер (или project manager) выполняет роль связующего звена всех работающих над проектом отделов. В игровой индустрии все подозрительно схоже с кинематографом…

Глава 03. Чтобы все хорошо сделать, нужно все хорошо организовать

Хочешь ходить по воде – научись сначала плавать.

Dragon Age 2

• Как устроена работа тестировщика?

• Зачем нужно планировать работу?

• Как предвидеть риски?

• Зачем нужно проектировать тесты?

• Зачем нужно устанавливать сроки начала и окончания тестирования?

• Как оптимизировать время тестирования?

• Какие документы готовит тестировщик?

• Что такое чек-лист, тест-кейс и тестовый набор?

• Когда и как нужно завершать тестирование?

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

Этот алгоритм состоит из четырех основных этапов.

1. Планирование

2. Проектирование

3. Реализация

4. Завершение

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

Фундаментальный процесс тестирования

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

Максим Филиппов, QA-менеджер Saber Interactive

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

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

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

3. Выполнить тестирование оптимальным способом. Не всегда стоит нестись сломя голову и просто проверять все свои гипотезы на фиче. Самая частая ошибка, которую я встречал в работе: QA получает задачу, что он должен протестировать N сущностей и получить N логов о работе сущностей. QA тестирует N сущностей и получает 0 логов. Потому что стоило бы после проверки первой сущности проверить, возможно ли получить логи вообще: баги могут быть везде.

Легко сделать неправильно, сложно сделать хорошо. Но хорошо сделать приятнее!

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

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

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

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

В зависимости от ситуации и проекта возможны разные подходы к разработке плана тестирования. Существуют стандарты, подробно описывающие план тестирования и его содержание, – международный стандарт ISO/IEC/IEEE29119–3:2013 и российский ГОСТ Р 56922–2016. Рекомендую тебе ознакомиться с ними более подробно, лишним это точно не будет. Хотя нужно сказать, что в подавляющем большинстве случаев тебе не придется писать многостраничные планы, соблюдая все требования стандартов. Достаточно хорошо проработанный план может занять всего 2–3 страницы и при этом быть отличным руководством для работы.

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

1. Что именно нужно тестировать? (Нужно описать объект тестирования, то есть сам игровой продукт. Это не только поможет быстрее адаптировать нового члена команды, но и во многом заменит отсутствующую документацию.)

2. Что будет тестироваться? (Тот функционал игры, который ты собираешься протестировать с максимальным покрытием.)

3. Как именно будет проводиться тестирование? (Нужно описать виды тестирования и типы проверок в рамках избранной стратегии тестирования и метрики для осуществления эффективного мониторинга.)

4. Когда именно будете проверять? (Это фактически информация о сроках и этапах тестирования.)

Кроме этого, в плане обязательно нужно отразить информацию о:

1. критериях начала и окончания тестирования;

2. программно-аппаратной части, используемой для тестирования (тестовой платформе);

3. потенциальных рисках продукта и проекта и плане управления ими.

Ну, и, конечно, тест-план должен учитывать и быть основанным на документе более высокого порядка – проектном расписании. Если изменения вносятся в него, то должен поменяться и тест-план.

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

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

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

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

Функциональное тестирование – это проверка соответствия реализованного игрового функционала формальным требованиям и спецификациям, а если их нет – требованиям и ожиданиям пользователя. Это проверка того, ЧТО можно делать в игре.

Нефункциональное тестирование – это проверка того, КАК работает продукт, то есть определение характеристик ПО, которые могут быть измерены различными величинами. К нефункциональному тестированию традиционно относят следующее.

• Основные виды тестирования производительности:

· нагрузочное тестирование (Performance and Load Testing)

· тестирование стабильности или надежности (Stability/Reliability Testing)

• Тестирование установки (Installation Testing)

• Тестирование удобства пользования (Usability Testing)

• Тестирование на отказ и восстановление (Failover and Recovery Testing)

• Конфигурационное тестирование (Configuration Testing)

• Тестирование безопасности (Security and Access Control Testing)

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

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

Матрица трассируемости – это, по сути, таблица, в которой отображается связь тестируемых сущностей или проектных требований и спроектированных для такой проверки тест-кейсов. На пересечении соответствующих строки и столбца устанавливается отметка, означающая, что функциональность или выполнение требования покрывается тест-кейсом. Обычно матрица используется, когда имеются четко сформулированные требования, и проверка выполняется с целью тестирования выполнения программным продуктом этих требований. Но в случае с тестированием игр в качестве требований могут использоваться ожидания пользователя (и, естественно, твои как опытного пользователя и знатока игр) от игрового функционала, то есть так называемые «пользовательские истории» (user stories). Они могут быть объединены в укрупненные группы на основании определенной логики. Например, могут проводиться объединенные проверки функционирования оружия персонажа, состоящие из нескольких тест-кейсов (см. таблицу). Как правило, эти «пользовательские истории» используются в качестве атрибута «ожидаемый результат» проектируемого тест-кейса. Но об этом позже.

Матрица трассируемости – крайне полезная штука, поскольку дает нам ответ на два важных вопроса.

1. Остался ли в игре непокрытый тест-кейсами функционал или области?

2. Не будет ли проводиться избыточного тестирования, если по одному требованию / «пользовательской истории» есть несколько пересечений?

Она позволяет:

• визуализировать актуальное состояние реализации проекта;

• разбивать требования на более мелкие (атомизировать требования) и структурировать их;

• отслеживать, есть ли требования, на которые еще не запланирована разработка;

• отслеживать, реализовано ли требование в данный момент;

• отслеживать, покрыто ли требование тест-кейсом;

• наглядно отображать приоритизацию требований.

Кроме того, матрица трассируемости в чуть более сложном виде позволяет проследить связь между задачами разработчика, требованием / «пользовательской историей», приоритетом его реализации в проекте, критериями приемки и тест-кейсом для проверки его функционала. Это существенно упрощает управление проектом и экономит огромное количество ресурсов.

При разработке матрицы трассируемости можно выделить следующие этапы.

1. В начале требования дробятся на более мелкие и/или преобразуют в конкретные задачи для выполнения командой тестирования (декомпозируют). Также команда QA устанавливает очередность проведения этих проверок в зависимости от ситуации (приоритизирует). Результатом этапа становится структурированный и приоритизированный список всех требований по данной функциональности – список «пользовательских историй».

2. Второй этап – общение с командой разработки и проставление в матрицу задач на разработку к соответствующим требованиям. В результате получается трассируемость требований и задач на разработку. На этом же этапе устанавливаются критерии приемки реализованных требований и приоритет требования в проекте.

3. Третий этап – разработка тест-кейсов. Она проводится непосредственно перед тестированием.

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

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

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

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

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

В плане тестирования отражаются еще два важных критерия – начало и окончание тестирования.

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

Ты скажешь: «А что тут сложного? Берем проект и начинаем работать!» Хотелось бы, чтобы все в жизни было так просто, но как говорил Ежи Лец: «В действительности все совершенно иначе, чем на самом деле». Представь, что в палату заходит хирург и между ним и медсестрой в присутствии пациента происходит следующий диалог.

Хирург: Ну что? Мне все ясно! Будем оперировать.

Медсестра: Начинаем готовить пациента к операции?

Хирург: А чего тут готовить? Давайте скальпель, здесь все и сделаем.

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

Ниже приведены критерии начала тестирования.

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

2. Наличие спецификаций/требований к продукту, «пользовательских историй» или моделей, если используется стратегия тестирования на основе моделей.

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

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

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

1. Все запланированные тесты выполнены.

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

3. Подтверждение соответствия продукта установленным критериям. То есть тестирование подтверждает, что продукт функционален, надежен, безопасен и т. д.

4. Превышение бюджета.

5. Истечение срока, отведенного на тестирование.

6. Решение заинтересованных лиц о выводе продукта на рынок.

7. Закрытие проекта.

3.1.2. Планирование ресурсов

Представь, что ты решил сделать ремонт в квартире. Что тебе для этого понадобится? Деньги для покупки материалов? Инструменты? Время для проведения ремонта? Помощники? А что случится, если чего-то из списка выше нет? Или есть, но недостаточно? Добьешься ли ты цели при отсутствии или недостатке ресурсов? Вряд ли.

Ресурсы – это источник покрытия проектных нужд. Они могут быть разными, и они требуют тщательного планирования.

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

• конкретных исполнителей задач;

• длительности задачи с учетом ограниченной доступности ресурсов;

• потребности в ресурсах в тот или иной период исполнения проекта;

• календарный график с учетом ограничений (недостаточности) ресурсов.

Проект по тестированию игрового продукта не может быть реализован без:

1. трудовых ресурсов – это команда тестировщиков и другие специалисты, участвующие в проекте;

2. материальных ресурсов – это оборудование, программы, мебель, коммунальные услуги и т. д.;

3. финансовых ресурсов – это те денежные средства, на которые приобретаются почти все остальные виды ресурсов;

4. информационных ресурсов – вся документация, требования и т. д., а также информация, получаемая из других источников, в том числе на различных планерках;

5. временных ресурсов.

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

Воспроизводимые ресурсы могут быть внутренними и внешними.

На ресурсы можно смотреть по-разному

Поговорим о разных ресурсах подробнее.

Трудовые ресурсы

Трудовые ресурсы – это ты и твои коллеги, а в широком смысле все работающие над проектом люди. Я не буду уделять много времени вопросу планирования трудового ресурса для проекта; об этом ты подробнее можешь прочитать в специальной литературе. Отмечу только, что нужно понимать, что трудовой ресурс на проекте, как и почти любой другой ресурс, обладает двумя важными характеристиками.

1. Количественной. Сколько специалистов нужно привлечь для реализации проекта?

2. Качественной. Какими знаниями и навыками должны обладать эти специалисты?

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

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

Зависимость производительности команды от времени формирования

1. Формирование

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

Производительность команды на этом этапе довольно низкая.

2. «Штормовая»

Это этап появления первых конфликтов, которые, если ими не управлять, станут для группы последними.

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

Производительность команды на этом этапе очень низкая.

3. Нормирование

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

Производительность команды на этом этапе – средняя с тенденцией к росту.

4. Деятельность

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

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

Производительность команды на этом этапе на пике.

5. Дезинтеграция

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

Производительность команды на этом этапе – высокая с тенденцией к снижению.

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

Материальные ресурсы

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

• Аппаратное обеспечение и комплектующие

• Программное обеспечение

• Средства связи

• Рабочее место сотрудника

• Объекты бытового назначения и т. д.

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

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

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

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

При планировании себестоимости[20] проекта нужно учитывать необходимые для его реализации материальные ресурсы.

Временные ресурсы

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

При планировании проекта нужно учитывать то, что время – невоспроизводимый ресурс, правильно учитывать время выполнения задач и связанные с ним риски.

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

Ниже приведены методы определения времени, необходимого для выполнения задачи.

1. Экспертная оценка, основанная на опыте (если команда работала на аналогичных проектах и выполняла похожие задачи, то в рамках планирования время для выполнения задачи может быть оценено исходя из опыта членов команды или самого руководителя тестирования).

2. Метод оценки по трем точкам (дается оценка реализации задачи с точки зрения времени по трем сценариям – пессимистичный (П), оптимистичный (О) и средний (С)). Оценка по всем сценариям дается с использованием экспертного метода (п. 1) и выражается в часах или днях. Затем полученные значения подставляются в формулу (П+О+4С)/6. Такая формула позволяет с одной стороны учесть возможные позитивные и негативные сценарии, а с другой – сгладить их влияние и получить более реальное значение оценки.

3. Оценка по аналогиям (в данном случае оценка проводится путем сравнения задачи с аналогичной из прошлого опыта команды или руководителя тестирования).

4. Метод триангуляции (часто используется в моделях гибкой разработки, таких как Scrum). Этот метод похож на предыдущий (п. 3), но сочетает в себе два подхода: метод аналогий и экспертную оценку. Задачи разбиваются на три типа:

• мелкая;

• средняя;

• крупная.

Каждой из них присваивается некоторое количество баллов. Например, мелкая – 1 балл, средняя – 3 балла, крупная – 5 баллов. При этом 1 балл равен некоторому количеству времени. Затем команда берет на себя обязательство по выполнению задач на некоторое количество баллов в течение одной итерации и в соответствии с этим строится диаграмма сгорания (Burndown Chart).

Информационные ресурсы

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

Информация – это то, что помогает мониторить и контролировать работы по проекту на всех его этапах. Обмен информацией происходит в рамках коммуникации между всеми участниками проекта и не только (о том, как это происходит и что получается, если коммуникация осуществляется неправильно, я расскажу ниже).

В рамках проекта тестировщик взаимодействует (получает и передает устную и письменную информацию) с разными специалистами.

• Разработчики (программисты, художники, гейм-дизайнеры, звукоинженеры, переводчики и проч.)

• Менеджеры проекта и продюсеры

• Руководители проектных групп (лиды)

• Коллеги, внешние эксперты

• Другие заинтересованные лица

Вся получаемая и передаваемая информация обладает важными свойствами.

1. Актуальность. Она может быть оценена по степени необходимости и важности информации для решения конкретной задачи в конкретный момент времени.

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

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

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

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

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

4. Полезность. Получатель информации должен определить нужность информации для себя в конкретной ситуации для решения конкретной задачи.

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

5. Достоверность. Информация может считаться достоверной, если она отражает реальную ситуацию. Достоверность информации очень сильно влияет на качество принимаемых решений. Примеры недостоверной информации – дезинформация (преднамеренное искажение) и искажение в результате воздействия «помех».

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

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

Финансовые ресурсы

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

3.1.3. Планирование рисков

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

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

Вероятность – это степень возможности наступления некоторого события, зависящая от разных факторов, к которым можно отнести:

• сложность технологии и команд;

• личностные проблемы и проблемы подготовки среди членов команд;

• конфликт внутри команды;

• слабое управленческое или техническое руководство;

• время, ресурсы, бюджет и давление менеджмента;

• отсутствие мероприятий по обеспечению качества;

• высокие темпы изменений;

• высокий темп выявления ранних дефектов.

Критичность – серьезность эффектов для пользователей, потребителей или других заинтересованных лиц. Факторы, влияющие на воздействие рисков проекта и продукта, включают:

• частоту использования затронутой функции;

• критичность функции для достижения целей;

• ущерб репутации;

• потенциальные финансовые потери;

• отсутствие разумных обходных путей и др.

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

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

Идентификация рисков

Цель этого этапа – выявить некоторое количество неизвестных рисков проекта. Часто в управлении рисками вероятность возникновения и критичность риска рассматривается с точки зрения «причина – риск – эффект».

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

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

Анализ рисков

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

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

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

Карта рисков

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

Планирование рисков

Цель этого этапа – создание стратегии управления риском, которая устранит или уменьшит его последствия. Есть три основные стратегии.

1. Перенести ответственность за последствия риска на третью сторону (заказчика, компанию партнера, страховую компанию и т. д.). Стратегия используется, если нельзя повлиять на существующий риск.

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

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

Мониторинг и контроль рисков

Мониторинг и контроль рисков – это постоянный процесс поддержания информации о рисках в актуальном состоянии, который в упрощенном виде выглядит как:

• выполнение ревизии списка рисков, обновление их оценки и обновление устаревших планов;

• выявление случившихся рисков, принятие решения о внедрении запасных планов и обновление плана тестирования.

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

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

3.2. Проектирование тест-кейсов

Тест-кейс (он же контрольный пример в ГОСТе, он же тестовый случай и т. д.) – это алгоритм действий для получения ожидаемого результата, включающий начальные условия и входные данные для проверки.

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

Во время этапа проектирования условия тестирования преобразуются в тест-кейсы и наборы тест-кейсов (тест-суитов). Таким образом, анализ и планирование отвечают на вопрос «Что тестировать?», а проектирование – «Как тестировать?».

Проектирование базово включает в себя:

• проектирование и приоритизацию тест-кейсов и наборов тест-кейсов;

• проектирование тестового окружения и определение необходимой инфраструктуры и инструментов.

3.2.1. Чек-листы

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

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

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

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

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

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

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

Объективность. Используя чек-лист, тестировщик имеет точные критерии для оценки продукта. Это уменьшает вероятность субъективного восприятия и позволяет проводить более объективные оценки.

Систематизация. Использование чек-листа обеспечивает структурирование процесса тестирования и упорядочивает проверку каждого пункта.

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

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

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

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

3.2.2. Тест-кейс

Как и остальные документы тестирования, тест-кейсы имеют свою структуру и основные атрибуты.

• Идентификатор (ID) – номер кейса.

• Приоритет (Priority) – степень необходимости прохождения тест-кейса. Может варьироваться от «Умри, но выполни» до «Забей», потому что на каждом проекте названия и важность этого атрибута будут определяться индивидуально. Приоритет тест-кейсов помогает оценить жизнеспособность продукта. Например, три непройденных тест-кейса при проверке элементов интерфейса, имеющих низкий приоритет, не так критичны, как один тест-кейс, проверяющий загрузку клиента игры.

• Название (Title). Необходимо написать так, чтобы другим специалистам было понятно, о чем речь и что будет проверяться.

• Предусловия (Precondition) – состояние игры, необходимое для начала проведения проверок. Например, необходимо быть залогиненным под определенным аккаунтом на сервере и должен быть выбран определенный персонаж или включен графический режим Ultra.

• Шаги (Steps). Действия, выполняемые в процессе проверок, которые должны привести к «Ожидаемому результату». То есть в буквальном смысле – Выбрать персонажа 1, перейти в окно выбора оружия, выбрать оружие 1.

• Ожидаемый результат (Expected Result). Состояние игровой системы, в которое она должна перейти. Например, при нажатии клавиши W персонаж идет вперед и т. д.

• Статус (Status) – результат проверки. Он содержит в себе обозначения вроде Passed, Failed, In Progress, Blocked, Untested.

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

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

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

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

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

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

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

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

Тест-кейсы бывают двух типов – позитивные и негативные.

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

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

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

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

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

Испечь пирожки по такому рецепту обычному человеку вряд ли получится. Из кулинарной книги 1886 года

Разберем написание тест-кейса на примере перехода игрока между лигами в игровой рейтинговой системе. Важно: игроки не могут «перескакивать» через несколько лиг за раз, перемещение происходит последовательно.

Все игроки начинают игру с нулевым рейтингом. Для определения стартовой лиги используются отборочные матчи. Выиграв 3 матча, игрок попадает в золотую лигу, 2 победных матча – в серебряную, 1 или менее побед – в бронзовую.

Напишем тест-кейс о переходе игрока в бронзовую лигу.

• ID: BL01

• Priority: Must Do

• Summary: переход игрока в бронзовую лигу при поражении.

• Precondition: запущенный режим лиг на сервере.

• Steps:

1. перейти в рейтинговые бои;

2. сыграть три отборочных матча, проиграв каждый из них;

3. открыть интерфейс рейтинговых боев

• Expected Result: Игрок помещен в бронзовую лигу.

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

1. Passed – фактический результат равен ожидаемому.

2. Failed – фактический результат не равен ожидаемому. Найдена ошибка.

3. Blocked – выполнение теста блокировано, если после одного из шагов продолжение теста невозможно. Найдена ошибка. Или функционал не реализован и не может быть протестирован.

Пример структуры проекта (ее части)

Хорошо составленный тест-кейс можно использовать при описании бага. Конечно, его нужно будет дополнить фактическим результатом, подробным описанием и прочими атрибутами дефекта типа критичности, но шаги (STR) и ожидаемый результат (Expected Result) у вас уже готовы.

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

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

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

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

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

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

4. Обязательно прикладывай необходимые аттачи[21], особенно если без скриншота непонятно, как этот тест-кейс проходить.

5. Подробно прописывай шаги и ожидаемый результат после выполняемых действий.

6. Тест-кейсы должны быть простыми для понимания, см. п. 3. Тест-кейс, написанный тобой, может выполнять новый сотрудник на проекте, поэтому тест-кейсы должны быть легко читаемыми и понятными для любого тестировщика.

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

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

3.2.3. Тест-дизайн

При проектировании тест-кейсов необходимо подумать о возможности и необходимости применения техник тест-дизайна – методик оптимизации ресурсов при проведении тестовых активностей. Своевременное и уместное применение техник тест-дизайна помогает серьезно сократить трудозатраты и время на само тестирование.

То есть тест-дизайн – это процесс, который позволяет создать оптимальное тестовое покрытие объекта при минимально возможных трудозатратах, используя определенные техники. Давай разберем некоторые из них.

Предугадывание ошибок (Error Guessing)

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

• знание того, как приложение работало в прошлом;

• знание того, какие типы и виды дефектов традиционно допускаются во время разработки;

• знание дефектов, которые были найдены в похожих приложениях.

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

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

Техника предугадывания ошибок (Error Guessing) в тестировании компьютерных игр предполагает использование опыта и интуиции тестировщика для предвидения потенциальных ошибок или проблем, которые могут возникнуть в процессе использования игры. Вот пример использования этой техники.

Пример. Тестирование многопользовательского режима в компьютерной стратегической игре.

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

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

1. Предположение: проблемы синхронизации игрового состояния.

• Предположим, что сетевая синхронизация игрового состояния между игроками может привести к несоответствиям или задержкам в игровом процессе.

• Изучить сценарии игры, которые могут создать перегрузку сети или проблемы с передачей данных.

2. Предположение: ошибки в балансе игровых персонажей.

• Предположим, что некоторые игровые персонажи или единицы могут быть слишком мощными или слабыми по сравнению с другими.

• Проверить балансировку уровня и силы игровых единиц в различных сценариях игры.

3. Предположение: проблемы совместимости между версиями клиента и сервера.

• Предположим, что изменения в клиентской или серверной части могут привести к несовместимости версий.

• Проверить, что клиент и сервер работают корректно после обновлений или патчей.

4. Предположение: проблемы с обработкой большого количества одновременных действий.

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

• Провести тестирование с максимально возможным количеством игроков и действий на экране.

5. Предположение: нарушения правил игрового процесса.

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

• Провести проверку наличия и эффективности античитовых механизмов.

Ожидаемый результат

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

Причина-следствие (Cause/Effect)

Метод предполагает проверку того, что ввод комбинаций условий (причин) приводит к получению определенного ответа от системы (следствие).

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

Каждый столбец этой таблицы – по сути, готовый тест-кейс.

Техника «причина-следствие» (Cause-Effect Testing) в тестировании компьютерных игр позволяет идентифицировать и проверять причины и следствия определенных событий или действий в игре. Рассмотрим пример использования этой техники на практике.

Пример. Тестирование эффектов падения здоровья персонажа в компьютерной игре.

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

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

1. Падение здоровья от атаки противника.

• Провести тест, в ходе которого персонаж будет атакован противником.

• Проверить, что здоровье персонажа уменьшается при успешной атаке противника.

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

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

3. Падение здоровья от повреждений окружающей среды.

• Испытать персонажа на падение с высоты, контакт с огнем, ядовитыми облаками и т. д.

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

4. Восстановление здоровья от лечения.

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

• Проверить, что здоровье персонажа восстанавливается после использования лечебных средств.

5. Проверка смерти персонажа при полном исчерпании здоровья.

• Провести тест, в ходе которого здоровье персонажа будет снижено до нуля.

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

Ожидаемый результат

После выполнения тестов на основе техники «причина-следствие» все причины и последствия падения здоровья персонажа в игре должны соответствовать ожидаемому поведению.

Эквивалентное разбиение (Equivalence Partitioning)

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

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

Пример. Тестирование управления автомобилем в компьютерной игре.

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

Эквивалентные классы

1. Тип контроллера

• Клавиатура

• Геймпад

• Руль с педалями

2. Тип управления

• Управление направлением (повороты)

• Управление скоростью (газ, тормоз)

• Управление специальными функциями (нитро, ручной тормоз)

Тест-кейсы

1. Тестирование управления направлением.

• Для каждого типа контроллера провести тестирование управления поворотами автомобиля вправо и влево.

• Проверить, что автомобиль поворачивает корректно и плавно при использовании каждого типа контроллера.

2. Тестирование управления скоростью.

• Для каждого типа контроллера провести тестирование управления газом и тормозом.

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

3. Тестирование специальных функций.

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

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

Ожидаемый результат

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

Граничные значения (Boundary Value Analysis)

Техника граничных значений основана на том предположении, что много ошибок возникает на границах эквивалентных классов. Она связана с техникой эквивалентного разбиения и поэтому часто используется с ней в паре. Часто проблемы возникают, когда возрастные категории указаны «внахлест» (например, 0–18, 18 и старше). Например, игра содержит платный контент, и игрок может приобрести внутриигровую валюту или игровые предметы за реальные деньги. При этом оплату могут произвести игроки в возрасте от 18 лет. Тестировщику будет необходимо проверить, как система обработает запрос от совершеннолетнего игрока. То есть при использовании позитивных тест-кейсов нужно проверить: «пустое» значение, значение в диапазоне 1–17 (для несовершеннолетних игроков), 18 и любое значение больше 18 для совершеннолетних. То есть граничными значениями будут 0, 1, 18, 19. Графически решение этой задачи можно изобразить так:

Есть два подхода к определению граничных значений: двухточечный и трехточечный анализ. При использовании первого мы берем одно значение внутри диапазона значений (класса эквивалентности) и одно ближайшее значение вне диапазона. При втором – два значения внутри диапазона значений и одно ближайшее вне диапазона.

Давай рассмотрим пример с проверкой поля ввода возраста пользователя.

В этом случае мы рассматриваем следующие классы эквивалентности.

1. Класс 1 – валидные значения от 18 и больше

2. Класс 2 – невалидные значения от 1 до 17

3. Класс 3 – невалидные значения от ∞ до 0

4. Класс 4 – невалидные данные (не числа)

Все эти классы делятся на три типа.

1. Класс, который имеет только нижнюю границу (Класс 1)

2. Класс, который имеет нижнюю и верхнюю границы (Класс 2)

3. Класс, который имеет только верхнюю границу (Класс 3)

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

Для Класса 1:

• верхней границы нет;

• нижние значения – 18 (внутри класса) и 17 (ближайшее вне класса).

Для Класса 2:

• верхние значения – 17 (внутри класса) и 18 (ближайшее вне класса);

• нижние значения – 1 (внутри класса) и 0 (ближайшее вне класса).

Для Класса 3:

• нижней границы нет;

• верхние значения – 0 (внутри класса) и 1 (ближайшее вне класса).

Как видно из примера выше, некоторые значения совпадают, а значит, не стоит проводить одни и те же тесты. Проверяем:

1. – 1 (проверяем Класс 3);

2. 0 (проверяем Класс 2 и Класс 3);

3. 1–17 (проверяем Класс 2 и Класс 3);

4. 18 (проверяем Класс 1 и Класс 2);

5. 19 (проверяем Класс 1);

6. буквы, спецсимволы и т. д. (проверяем Класс 4).

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

Второй вариант определения граничных значений – трехточечный анализ.

Для Класса 1:

• верхней границы нет;

• нижние значения – 18 и 19 (внутри класса) и 17 (ближайшее вне класса).

Для Класса 2:

• верхние значения – 16 и 17 (внутри класса) и 18 (ближайшее вне класса);

• нижние значения – 1 и 2 (внутри класса) и 0 (ближайшее вне класса).

Для Класса 3:

• нижней границы нет;

• верхние значения – 0 и –1 (внутри класса) и 1 (ближайшее вне класса).

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

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

При проверке условия, при котором х ≥ 18, где х – возраст пользователя с использованием двухточечного анализа, мы проверим значения 17 (негативный тест) и 18 (позитивный тест). Представь, что разработчик по ошибке поставил вместо знака ≥ просто =. Проверка в случае использования двухточечного анализа не выявила бы этой ошибки, потому что при проверке с 17 обнаружилась бы ошибка, а тест с 18 завершился бы успехом. А вот использование трехточечного анализа, при котором проверялось бы еще значение 19, эту ошибку выявил бы, потому что проверка закончилась бы ошибкой, а ее быть не должно.

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

Допустим, мы тестируем компьютерную игру с большим количеством уровней или миссий. Одна из техник тест-дизайна, которую мы можем применить, – метод граничных значений (Boundary Value Analysis, BVA). Давай рассмотрим пример применения этой техники для тестирования функции здоровья персонажа в игре.

Задача. Протестировать функцию здоровья персонажа в компьютерной игре.

В игре здоровье персонажа может иметь пределы, например от 0 до 100 единиц.

Граничные значения: 0 (минимальное значение), 1 (меньше минимального), 50 (среднее значение), 99 (больше минимального), 100 (максимальное значение), 101 (больше максимального).

Создание тест-кейсов

Тест 1. Проверка, что здоровье персонажа уменьшается правильно при получении урона до 0.

Тест 2. Проверка, что персонаж умирает, когда его здоровье достигает 0.

Тест 3. Проверка, что персонаж не может иметь отрицательное здоровье.

Тест 4. Проверка, что здоровье персонажа увеличивается правильно при лечении до максимального значения.

Тест 5. Проверка, что персонаж не может иметь здоровье выше максимального значения.

Тест 6. Проверка, что здоровье персонажа уменьшается правильно при получении урона после достижения максимального значения.

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

Попарное тестирование (Pairwise Testing)

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

Давай разберем это на примере тестирования совместимости. Задача тестировщика – протестировать игру на предмет обнаружения ошибок с отдельными аппаратными конфигурациями.

Ниже приведены исходные данные для составления конфигураций.

Видеокарта (GPU)

1. AMD Radeon HD6570

2. NVidia GeForce RTX 2070

3. NVidia GeForce GTX 1060

Оперативная память (RAM)

1. 8 МB

2. 16 MB

3. 32 MB

Процессор (CPU)

1. Intel i7 4790

2. Intel Core i5-3330

3. AMD A10 7890K

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

Количество конфигураций = 3 х 3 х 3 = 27.

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

Суть ее в том, что можно взять только комбинации пар каждых значений (отмечено в таблице зеленым) вместо комбинаций всех значений. То есть мы должны найти уникальные сочетания (не повторяющиеся в других строках) значений каждой строки столбца CPU с GPU, CPU с RAM и GPU с RAM.

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

• Выбираем параметр с самым большим количеством значений.

• Составляем уникальные пары со следующим параметром.

• Сравниваем остальные параметры с последним.

• Удаляем лишние пары.

• Добавляем необходимые проверки в случае необходимости.

Но в большинстве случаев нет необходимости вручную комбинировать каждую такую пару. Можно использовать готовые программные решения, в которых нам нужно указать только параметры и значения, а дальше приложение рассчитает все само. В числе таких приложений можно назвать PICT (Pairwise Independent Combinatorial Tool) от Microsoft.

Используя их, мы получаем 9 комбинаций для проверки вместо 27. Неплохо!

Чем больше параметров используется в системе, тем эффективнее будет применение данного метода.

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

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

Пример использования техники тест-дизайна (Pairwise Testing) для системы управления в компьютерной игре:

Цель тестирования. Проверить корректность системы управления персонажем в компьютерной игре.

Входные данные

• Движение клавиш (WASD)

• Нажатие клавиш для атаки (левая кнопка мыши)

• Нажатие клавиши для прыжка (пробел)

• Действия мыши (вращение камеры, направление атаки и т. д.)

Применение техники тест-дизайна

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

Пример комбинаций

• Нажатие клавиши W (движение вперед) + Нажатие клавиши D (движение вправо) + Нажатие левой кнопки мыши (атака)

• Нажатие клавиши S (движение назад) + Нажатие клавиши A (движение влево) + Пробел (прыжок)

• Нажатие клавиши W (движение вперед) + Нажатие клавиши D (движение вправо) + Движение мыши влево (вращение камеры)

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

Тестирование на основе сценариев использования (Use Case Testing)

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

При этом тестовое покрытие мы определяем как процент протестированных вариантов поведения к общему числу вариантов.

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

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

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

Действующие лица

Пользователь, Система регистрации и авторизаци

Цель

Пользователь: зарегистрироваться в системе и начать работать

Система: внести пользователя в базу данных и идентифицировать его права доступа

Предусловие

Пользователь не имеет учетной записи в системе

Успешный сценарий:

1. Пользователь запускает систему в первый раз. Система открывает сессию пользователя и предлагает зарегистрироваться.

2. Пользователь вводит логин, пароль, должность, e-mail и контактные данные в соответствии с условиями, обозначенными над полями ввода.

3. Система проверяет, есть ли данные пользователя в базе данных.

4. Если данные о пользователе в БД не дублируются, система высылает письмо на указанную электронную почту и просит подтвердить регистрацию через e-mail. При дублировании данных система предлагает вспомнить старую учетную запись.

5. После подтверждения регистрации система создает запись в истории авторизаций (IP-адрес пользователя, логин, дата, рабочая станция) и присваивает права в соответствии с должностью.

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

7. Пользователь заходит в систему, ему доступны разделы, соответствующие его правам.

Результат

Учетная запись пользователя была создана, права соответствуют должности. Информация о пользователе появилась в БД

На этой основе создаются тестовые сценарии.

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

Пример. Тестирование функционала боя в компьютерной игре.

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

Сценарии использования

I. Сценарий: начало боя с одним противником

Шаги

1. Встретить одного противника на локации.

2. Начать бой с противником.

3. Использовать различные атакующие приемы: удары, блоки, уклонения.

4. Проверить, что атаки и защита работают корректно и герой реагирует на действия противника.

5. Проверить, что противник реагирует на действия игрока.

II. Сценарий: бой с несколькими противниками

Шаги

1. Встретить группу противников на локации.

2. Начать бой с группой противников.

3. Использовать тактические приемы, такие как фокусировка на одном противнике или использование специальных атак.

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

5. Проверить, что ИИ противников работает адекватно при бое в группе.

III. Сценарий: бой с боссом

Шаги

1. Достичь конца уровня, где находится босс-противник.

2. Начать бой с боссом.

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

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

Ожидаемый результат

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

Диаграмма перехода состояний (State & Transition Diagram)

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

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

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

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

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

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

Таблица перехода состояний (State Transition Table) часто применяется в тестировании компьютерных игр для описания и проверки различных состояний игры и переходов между ними. Рассмотрим пример использования такой таблицы на практике.

Пример. Тестирование переключения между экранами меню в компьютерной игре.

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

Таблица перехода состояний

Описание переходов

1. Пользователь может перейти из главного меню на экран выбора уровня, нажав кнопку «Играть».

2. После выбора уровня и нажатия кнопки «Старт» пользователь переходит к началу игрового уровня.

3. Во время игрового процесса пользователь может нажать кнопку «Пауза», чтобы открыть меню паузы.

4. Из меню паузы пользователь может выбрать продолжение игры или выход в главное меню.

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

Проверка перехода с главного меню на экран выбора уровня.

1. Нажать кнопку «Играть» в главном меню.

• Проверить, что появляется экран выбора уровня.

• Проверка перехода от экрана выбора уровня к началу игрового уровня.

2. Выбрать уровень и нажать кнопку «Старт».

• Проверить, что игровой уровень начинается.

• Проверка перехода в меню паузы во время игры.

3. Начать игровой уровень.

• Нажать кнопку «Пауза» во время игры.

• Проверить, что появляется меню паузы

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

• Нажать кнопку «Продолжить» или «Выйти в главное меню» в меню паузы.

• Проверить, что игровой процесс возобновляется или игра возвращается в главное меню.

Ожидаемый результат

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

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

• процесс тестирования предполагает множество однотипных действий;

• мы стремимся разработать тесты, которые помогут найти наиболее серьезные ошибки;

• мы хотим минимизировать количество необходимых тестов для проверки продукта при сохранении оптимального тестового покрытия;

• мы хотим избежать лишних трат времени и денег (то есть всегда!).

3.2.4. Наборы тест-кейсов (тест-суиты)

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

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

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

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

3. Мониторинг и контроль прогресса выполнения работ. При выполнении тестирования мы можем ясно видеть прогресс и проблемы, возникающие при реализации проекта.

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

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

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

Еще один способ комбинирования тест-кейсов – сценарий тестирования. Это последовательные тесты, при прохождении которых можно проверить внушительный набор функций. Сценарий тестирования может (и в идеале должен) ссылаться на остальные тест-кейсы, написанные для всех функций через поле Reference. Сценарий тестирования не получится сделать, просто накидав тест-кейсов из разных категорий: почти нереально подобрать из готовых тест-кейсов последовательность так, чтобы результат прохождения одного тест-кейса становился условиями (preconditions) для прохождения следующего.

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

3.2.5. Как проектировать эффективные проверки

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

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

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

Для этого, приступая к проектированию проверки, ты должен задать себе следующие вопросы.

1. Что за продукт ты собираешься тестировать? К какому жанру он принадлежит? Это позволит тебе определиться с главными областями функциональных и нефункциональных проверок.

2. Какая у него целевая аудитория? Что эти люди ожидают от игры? Это позволит понять, что ждут от продукта разные игроки в соответствии со своим игровым опытом.

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

4. Как продукт может работать неверно в проверяемых областях? Это поможет создать наборы негативных тест-кейсов.

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

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

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

3.3. Выполнение тестирования

На этой стадии наборы вышеописанных тестов запускаются в соответствии с расписанием. Основными активностями тестировщика тут будут:

• выполнение тестов вручную или с помощью специальных инструментов;

• сравнение фактических и ожидаемых результатов;

• анализ обнаруженных отклонений для установления вероятных причин их возникновения (анализировать баги мы будем в последующих главах);

• составление отчетов о дефектах на основе получаемых результатов;

• протоколирование результатов выполнения тестов (например, пройден, не пройден, блокировка);

• повторение тестов, в результате которых были обнаружены отклонения в рамках запланированного тестирования (например, выполнение исправленного теста) и/или регрессионного тестирования.

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

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

Сторонники теории «исправь сразу или забудь навсегда» аргументируют свою позицию следующим.

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

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

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

Случай № 1. Не слишком умный менеджер ввел правило оценивать тестировщиков по количеству найденных ими дефектов. А его коллега всячески поощрял разработчиков, когда они исправляли обнаруженные тестировщиками дефекты. Вскоре тестировщики договорились с разработчиками, что последние специально будут делать ошибки в коде, чтобы тестировщики фиксировали их в баг-трекинговой системе, и все могли получать бонусы. Стоит ли говорить, что никого уже не волновал создаваемый продукт и его качество?

Случай № 2. Еще один менеджер предложил систему финансового стимулирования тех тестировщиков, кто нашел и завел в систему баг-трекинга больше всех дефектов. Через некоторое время количество записей о найденных дефектах резко возросло, и каждая запись указывала на несоответствие требованиям. Казалось бы, так и должно быть, однако оказалось, что эти несоответствия были не дефектами, а… улучшениями или дубликатами с разным описанием.

Случай № 3. Не лучше оказался подход и третьего менеджера. Он ввел KPI для тестировщиков, по которому они должны были ежедневно находить и заносить в систему баг-трекинга минимум 10 дефектов. Очень скоро тестировщики поняли, что к чему, и стали придерживать «лишние» дефекты. И даже если в один день тестировщики находили 20 багов, они «репортили» (заводили в системе баг-трекинга) только по 10, чтобы на следующий день… ничего не делать.

Сторонники этого подхода предлагают сосредоточиться на предотвращении дефектов, а не фиксации багов для исправления их в будущем (например, с помощью методологии разработки через приемочное тестирование (acceptance test driven development, ATDD)). ATDD развивает идеи разработки через тестирование (test driven development, TDD). Общий смысл этой методологии таков: прежде чем что-то делать, надо придумать критерии выполненной работы и критерии того, что работа выполнена правильно. Эти критерии позволяют на самом раннем этапе понять, что именно требуется сделать, как это сделать и что именно считать результатом.

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

Цель приемочного тестирования – показать, как изменяется тестируемая система в конкретном случае. Для этого в сценарии необходимо описать изначальное состояние системы, затем внешнее или внутреннее действие, которое эту систему меняет, и ожидаемый пользователем результат такого воздействия, то есть новое состояние системы. При этом систему мы видим как «черный ящик»: мы не знаем, как она устроена внутри и с чем взаимодействует снаружи, а критерием успешности считаем переход системы в новое состояние.

Для разработки приемочных тестов используется метод Given – When – Then (GWT).

• Given описывает что «дано», то есть изначальное состояние системы.

• When описывает воздействие (обычно пользователя) на систему изнутри или извне, которое должно привести к результату.

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

Тебе не кажется все это уже знакомым? Присмотрись! У тебя есть (Given) рабочий из космической стратегии, когда (When) ты даешь ему приказ мутировать, указав место здания, кликнув на карте, он (Then) начинает движение к этому месту и, достигнув его, начинает мутировать в выбранное тобой здание. Ты можешь использовать табличное описание следующего вида.

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

Метод Given – When – Then позволяет описать все случаи поведения системы. Для этого нужно:

1. определить все состояния, которые могут быть заданы, то есть все Given;

2. определить все виды воздействия, то есть все When;

3. определить все Then, что именно должно произойти;

4. комбинаторно перемножить списки.

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

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

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

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

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

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

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

Большинство команд, занимающихся тестированием игр, особенно те, кто работают на аутсорсе[22], в настоящее время используют традиционные методы, подразумевающие совместную итеративную работу тестировщиков и разработчиков с использованием баг-трекинговых систем. Формально ни одна из перечисленных систем не является специфическим ПО для проведения тестирования. Это системы совместного доступа для управления проектами и задачами.

3.4. Завершение тестирования

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

Активности по завершении тестирования принято недооценивать. И действительно, зачем что-то специально готовить? Все тесты выполнены. Баги найдены или не найдены. Работа завершена. Всем спасибо, все свободны.

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

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

2. Передача «наследия». Другими словами, любые ценные продукты тестирования должны быть переданы заинтересованным лицам: дефекты в полном объеме ответственным за их исправление лицам, наборы регрессионных тестов – команде поддержки, тестовое окружение и документация – команде тестирования на стадии поддержки. Кроме того, вся документация должна быть сохранена и проверена для последующего использования и находиться в структурированном и понятном виде.

3. Ретроспектива и рефлексия. Организация встреч для улучшения процессов тестирования: насколько точен был план тестирования и какие изменения могли бы быть внесены, насколько точны были оценки рисков, выбор программно-аппаратной части для тестирования, насколько эффективен был анализ дефектов, насколько соответствовали требованиям проекта квалификация членов команды и т. д. Результатом таких встреч должен стать документ, который часто называют постмортем (Postmortem).

4. Формализация. Разработка, подписание и передача всех необходимых документов.

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

После того как подтверждение получено, нужно подготовить список материалов и артефактов тестирования, которые надо передать команде поддержки, и тех материалов, которые необходимо сохранить для использования в будущем. Почему это важно? Потому что ядро тест-кейсов не меняется при тестировании игр одного жанра. Если ты тестировал Duke Nukem, то большое количество тест-кейсов подойдет и для тестирования последнего Doom: движение персонажа, подбор оружия, стрельба, переключение оружия, его перезарядка, нанесение урона, поведение мобов и т. д. Все это будет требовать проверки в любом FPS без исключений. Так зачем каждый раз изобретать велосипед, если можно использовать лучшие практики?

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

3.4.1. Отчетные документы

1. Отчет о результатах тестирования (Test Result Report)

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

2. Отчет о выполнении теста (Test Execution Report)

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

3. Отчет о ходе тестирования (Test Progress Report)

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

4. Аналитический отчет о тестировании (Test Evaluation Report)

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

5. Итоговый (сводный) отчет о тестировании (Test Summary Report)

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

Кроме этих документов, в разных компаниях могут быть приняты и другие виды отчетности, например отчеты о прохождении «вех» проекта (MS Report), отчет, который позволяет создавать различное ПО: системы управления тестированием или баг-трекеры.

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

И, наконец, на этом же этапе готовятся формальные документы, которые необходимо передать заинтересованным лицам. К таким документам относят прежде всего отчет о тестировании (Test Result Report, TRR), где дается оценка тестируемому продукту и проекту. Первый вопрос, на который нужно дать ответ себе, – для кого создается отчет?

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

1. Разработчики. Их приоритеты – количество и критичность выявленных багов и общее состояние продукта. Информация необходима для планирования процесса разработки.

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

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

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

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

1. Краткое описание. В краткой форме отражает основные достижения, проблемы, выводы и рекомендации. В идеале прочтения краткого описания должно быть достаточно для формирования полноценного представления о происходящем, чтобы не читать весь отчет.

2. Состав команды – список участников проектной команды, задействованных в обеспечении качества, с указанием их должностей и ролей.

3. Срок, за который составляется отчет.

4. Описание процессов тестирования, то есть какие работы были выполнены за отчетный период.

5. Расписание тестовых работ всей команды тестировщиков и/или личные расписания конкретных членов команды.

6. Статистика по дефектам. Это таблица, в которой представлены данные по обнаруженным за все время существования проекта дефектам. Как правило, в этот же раздел добавляется график, отражающий такие статистические данные.

7. Критичные и блокирующие проблемы, а также принятые меры по их устранению.

8. Результаты регрессионного тестирования (опционально).

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

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

1. Выводы нужно делать, помня о целях, отраженных в плане тестирования.

2. Выводы должны быть краткими и информативными для целевой аудитории отчета.

3. Если делаются выводы, нужно добавить рекомендации.

4. Рекомендации должны быть краткими, выполнимыми и содержащими алгоритм действий и целей, к которым эти действия должны привести.

5. Рекомендации также необходимо обосновывать.

6. Обоснование строится на объективных фактах, а не на предположениях и интуиции.

Кроме этого, на этапе завершения тестирования тебе может пригодиться умение пользоваться некоторым дополнительным ПО.

3.5. Мониторинг и контроль тестирования

Это не отдельный этап проекта, а постоянная работа руководителя тестирования (лид, тест-менеджер) для отслеживания хода выполнения проекта по тестированию со сравнением ситуации на проекте с планом. Контроль прогресса обычно проводится на контрольных точках проекта, которые называются вехами (milestones)[23]. При этом мониторинг осуществляется в постоянном режиме с использованием специальных метрик. Метрики – это показатели, которые позволяют менеджеру делать выводы о ходе выполнения проекта и его состоянии.

3.5.1. Метрики тестирования

Пропуск дефектов

а. Количество пропущенных дефектов (Bugs Leakage). Используется для анализа причин ненахождения дефектов.

б. Процент (%) дефектов, найденных не тестировщиками (Bugs Reported Not by Testers). Используется для анализа того, почему другие участники процесса разработки находят пропущенные тестировщиками дефекты. Это может быть признаком недостаточной квалификации специалистов по тестированию.

в. Пропуск дефектов по категориям (Bugs Leakage by Category). Необходима для анализа, в каких областях нужно развивать компетенции тестировщиков. В качестве категории могут выступать функциональные области, уровни тестирования и т. д.

Тестовое покрытие

а. Покрытие требований тестами (Requirements Coverage). Используется для анализа и отслеживания полноты тестового покрытия. В этом случае обязательно установление критерия «Требование к тестам» – например, хотя бы один тест на требование. Для вычисления этой метрики можно использовать матрицу трассируемости.

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

Следование плану работ

а. Срывы сроков по задачам (Schedule Slippage). Используется для выявления среднего срока срывов начала выполнения задач и включения его в план управления рисками.

б. Отклонение от плана работ (Schedule Variance). Позволяет рассчитать величину отклонения реального выполнения работ на проекте от плана. Используется для контроля выполнения проекта.

в. Превышение трудозатрат (Estimation Changes). Используется для проверки корректности проводимых плановых оценок трудозатрат по проекту.

Дефекты в продукте по категориям

а. В этой группе представлено несколько метрик для мониторинга количества дефектов в продукте по разным категориям: критичность, функциональная область, тип тестов и т. д.

Результаты тестирования

а. Пройденные/непройденные тест-кейсы (Passed/Failed Test Cases). Показывает процент работающей функциональности, качество и стабильность продукта.

б. Запущено тестов (Executed Test Cases). Показывает процент оставшихся работ по тестированию проекта.

Работа с дефектами

а. Процент исправленных дефектов (Bugs Fix Ratio). Используется для определения процента исправленных дефектов.

б. Процент неисправленных дефектов (Bugs Reject Ratio). Используется вместе с предыдущей метрикой для определения причин НЕисправления дефектов и оценки квалификации специалистов по тестированию.

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

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

3.5.2. Оценка проекта на вехах (контрольных точках)

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

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

Проверки по критериям могут быть отнесены к трем базовым группам.

1. Проверка готовности (Readiness check). Объект оценивается с точки зрения формальных признаков готовности.

2. Проверка на соответствие минимальным критериям (Must-meet criterion). Проверка того, что объект отвечает минимальным требованиям (например, системным).

3. Проверка на соответствие желаемым критериям (Should-meet criterion). Проверка того, что объект отвечает желаемым (рекомендуемым) требованиям.

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

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

Ответь на вопросы теста. Ответы ты найдешь в конце книги.

1. К каким ключевым шагам фундаментального процесса тестирования принадлежат следующие задачи и активности и в какой последовательности они выполняются?

• Сравнение фактических и ожидаемых результатов

• Определение необходимых тестовых данных для поддержки тестовых условий

• Создание сводного отчета по тестированию

• Определение целей тестирования

• Анализ требований

2. Одно из полей формы содержит текстовое поле, которое принимает целые числовые значения в диапазоне 10≤ × ≤50. Какие граничные значения будут справедливы для проверки этого условия?

3. Что из перечисленного должно быть сделано на этапе завершения тестирования?

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

• Написание итогового отчета для заинтересованных сторон.

• Передача тестируемой программы организации обслуживания.

• Определение необходимой инфраструктуры и инструментов.

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

5. Какая информация из отчета о дефекте наиболее эффективна при определении срочности и усилий по исправлению этого дефекта?

A. Дата создания отчета

B. Подробное описание дефекта

C. Ожидаемый и фактический результат

D. Приоритет дефекта

E. Имя тестировщика, обнаружившего дефект

F. Рекомендации по исправлению дефекта

Глава 04. Когда не знаешь, с чего начать, начинай с сути

Война. Война никогда не меняется.

Fallout

• Кто разрабатывает игры и зачем это знать тестировщику?

• Какие бывают игры?

• Как исследовать объект тестирования?

• Как тестировать ключевые функциональные области?

• Как тестировать ключевые нефункциональные области?

• Как тестировать требования?

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

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

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

• предпочтениями пользователей (фэнтезийный сеттинг, разные типы оружия и т. д.);

• жанровыми особенностями (наличие оружия и огромного количества врагов обязательно для FPS, диалоги с NPC – для RPG, препятствий – для платформеров и т. д.);

• сюжетными линиями (характерные для разных жанров);

• целями, которые нужно достигнуть в игре;

• характеристиками игровых персонажей (пираты, викинги, первобытные люди, бандиты, маги, военные и т. д.);

• временем действия (Средневековье, настоящее время и т. д.);

• техническими ограничениями аппаратной части игровой платформы;

• и т. д.

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

4.1. Какие бывают игры?

PRG, role-playing game (Ролевая игра)

Задача игрока в играх этого жанра – общение в широком смысле слова (разговор, сражение, союз, торговля) с разными категориями персонажей. Для общения с каждой категорией персонажей (враги, союзники, торговцы, работодатели, прохожие и проч.) используется свой метод, который зависит от роли персонажа игрока. Цель общения – решение конкретной задачи для продвижения персонажа игрока по сюжетной линии. Персонаж может перемещаться по карте, но эти перемещения происходят по схеме сюжетной линии и не дают полной свободы.

Open RPG (Ролевая игра с открытым миром)

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

Session RPG (Сессионная ролевая игра)

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

MMORPG (Массовая многопользовательская ролевая онлайн-игра)

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

Roguelike (Рогалик)

Название типа игр появилось от названия первой игры – Rogue. В них все случайное, кроме героя: локации, враги, предметы. Задача игрока – защищать локацию, состоящую из случайно сгенерированных уровней (комнат), в которых находятся случайные враги и случайные предметы. После гибели героя прогресс, как правило, не сохраняется и нужно начинать все заново. Хотя иногда может быть место, где можно сохранить часть прогресса.

Browser RPG (Браузерная ролевая игра)

Задача игрока – общаться и вступать во взаимодействие (сражение, союз). Игрок выбирает свое поведение, исходя из поведения персонажа, с которым вступает во взаимодействие и который может быть врагом, союзником и т. д. Глобальная цель – прокачка своего героя.

Adventure (Приключение)

Игры, относимые к этому жанру, часто называют «бродилками» или point-and-click. Важнейшее действие в подобной игре – решение разнообразных загадок, получаемых игроком после общения с различными игровыми персонажами. Чаще всего загадка решается путем применения ранее найденной или созданной героем вещи. Для нахождения вещи игрок должен очень тщательно осматривать места, которые посещает, а для переноса таких вещей у него есть небольшой инвентарь.

Puzzle (Головоломка)

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

Open Action (Боевик с открытым миром)

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

Action (Боевик) / Shooter (Шутер)

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

Arcade (Аркада)

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

Sport (Спорт)

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

Fighting (Файтинг, драка)

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

Platformer (Платформер)

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

Racing/Battle Racing (Гонки/гонки-сражения)

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

Simulator (Симулятор)

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

Stealth Action (Шпионский боевик, хоррор)

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

Slasher (Слэшер, рубилово)

Основа геймплея – сражения в ближнем бою от третьего лица с применением холодного оружия. Иногда игроку позволяют использовать огнестрельное или метательное оружие, но это скорее исключение или дополнительная возможность. Частый признак – использование комбинаций и связок ударов (комбо), которые становятся доступны по ходу игры.

MMOFPS (Сетевой экшен)

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

Survival (Выживание)

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

TBS (Пошаговая стратегия)

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

RTS (Стратегия в реальном времени)

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

Tower Defense (Защита башни)

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

Cardgame (Карточная ролевая игра)

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

Economic Strategy (Экономическая стратегия)

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

Wargame (Военная игра)

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

MOBA (Многопользовательская боевая арена)

Главная отличительная черта жанра – командное сражение нескольких игроков на арене. Каждый игрок управляет одним персонажем с уникальными особенностями, которые становятся доступны по ходу матча. Цель каждой игры – прорвать оборону противника и уничтожить его главного здание.

Global Strategy (Глобальная стратегия)

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

Logic (Логическая игра)

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

Building (Строительство)

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

Life Sim (Сим, симулятор жизни)

В основе жанра лежит наблюдение и частичное управление одним или несколькими персонажами в их повседневной жизни. Игрок должен следить за основными параметрами своего подопечного, чтобы он был сыт, здоров и весел. Другие доступные игроку возможности – постройка дома, обстановка его мебелью, смена одежды и внешнего вида персонажа. Явно выраженной цели здесь нет: игрок сам придумывает себе задачи и пути их решения.

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

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

4.2.1. Тестирование игровых механик

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

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

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

Практически в любой игре есть ключевые и второстепенные механики. Ключевые механики составляют основу геймплея любой игры, ее core gameplay loop – основной игровой цикл. Именно эти механики повторяются раз за разом, и именно они должны вводить игрока в состояние потока. Поэтому их работа тестируется особенно тщательно.

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

Игровой тестировщик должен уметь отличить основные механики от второстепенных. Каждый игровой жанр, как правило, характеризуется определенным набором ключевых механик. Знание и умение выделять эти механики помогут тебе выбрать проверки для включения в smoke-тест[25], определить очередность и важность тестов. Хороший тестировщик понимает, какие базовые тесты необходимо проводить для той или иной игры, даже не видя ее.

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

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

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

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

Были выделены три основных игровых жанра по действиям, которые игроки совершают в игре.

1. Игры общения (действия связаны с получением информации, общением, изучением мира).

2. Игры действия (действия связаны с перемещением в пространстве, использованием техники и оружия).

3. Игры контроля (действия связаны с контролем, добычей ресурсов, управлением, распределением средств).

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

В таблице ниже показано, как распределяются игры по жанрам.

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

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

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

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

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

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

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

Например, в ЛЮБОМ однопользовательском FPS (first person shooter), согласно таблице и нашему опыту, пользователь может совершать следующие действия.

Функциональное тестирование (критические функциональные области)

1. Перемещаться по уровню, используя кнопки управления (в случае PC).

Описание. Перемещение персонажа в игре происходит в следующих направлениях и способами: вперед, назад, шаг влево, шаг вправо, стрейф[26] влево, стрейф вправо, прыжок, присед.

2. Подбирать разные виды оружия.

Описание. Подбор оружия, как правило, происходит, когда персонаж проходит «сквозь» него.

3. Подбирать аптечки здоровья.

Описание. Аптечка подбирается, если количество очков здоровья (HP, health points) составляет менее 100. Персонаж подбирает аптечку, проходя «сквозь» нее. При подборе аптечки количество HP в HUD (head-up display) увеличивается на количество HP аптечки, но не более 100 в общем.

4. Подбирать патроны/снаряды/ammo.

Описание. Снаряды подбираются, если их количество для определенного вида оружия составляет меньше, чем определено в игре. Персонаж подбирает снаряды, проходя «сквозь» них. При подборе снарядов количество зарядов в HUD (head-up display) увеличивается на количество зарядов ящика со снарядами, но не более установленного для данного вида оружия в общем.

5. Уничтожать разных мобов или разрушать объекты на уровнях игры.

Описание. Разный урон наносится в зависимости от типа оружия. При этом выстрел из оружия должен сопровождаться: а) анимацией оружия (отдача – recoil, перезарядка – reload), б) спецэффектом (вспышка – muzzle flash), в) звуком, синхронизированным с анимацией.

6. Проходить на другие уровни.

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

7. Получать урон от противников разного уровня, погибать и возрождаться в игре.

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

…

Функциональное тестирование (некритические функциональные области)

8. Избегать прямого контакта с неигровыми персонажами (non-player character, NPC), если это обязательно по сюжету игры.

Описание. Финальную цель игры можно/нельзя достигнуть, не вступая в контакт с NPC и мобами.

9. Не накапливать / игнорировать игровую добычу (Loot), если она не необходима для прохождения игры.

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

10. Отказаться от выполнения дополнительных заданий, если это не необходимо для достижения финальной цели.

Описание. Финальную цель игры можно/нельзя достигнуть, не выполняя дополнительные задания.

…

Нефункциональное тестирование (критические области)

1. Иметь возможность установить продукт на конкретный PC с определенными системными требованиями.

Описание. Произвести успешную установку на конкретный PC.

2. Иметь возможность использовать игровой продукт на совместимой программно-аппаратной части.

Описание. Использовать игровой продукт на какой-то из игровых платформ (PC, игровая приставка или смартфон и т. д.) со стабильным показателем FPS и т. д.

3. Сохранять и загружать ранее сохраненную игру с сохранением игрового прогресса и достижений.

Описание. Произвести сохранение игры и последующую загрузку игры с сохраненным прогрессом и достижениями.

4. Взаимодействовать с игровым продуктом, включая использование настроек продукта в пользовательском интерфейсе (UI).

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

5. Использовать адаптированный игровой продукт, имеющий корректный перевод на язык пользователя.

Описание. Использовать продукт, отвечающий требованиям законодательства, моральным и этическим нормам страны и культуры пользователя.

…

Нефункциональное тестирование (некритические области)

6. Иметь возможность продолжить игровой сеанс на другой платформе с использованием единого аккаунта пользователя (кроссплатформенное сохранение).

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

7. Иметь возможность настраивать игру в соответствии с собственными представлениями об удобстве пользования.

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

Представим полученную схему проверки критических функциональных областей FPS (first person shooter) в виде матрицы трассируемости.

В качестве другого примера можно рассмотреть более сложный жанр – RPG.

Функциональное тестирование (критические функциональные области):

1. Игрок управляет одним или несколькими уникальными персонажами.

2. Игрок играет определенную роль своего персонажа.

3. Игрок улучшает характеристики персонажа(ей), используя очки опыта, полученные за выполнение определенных действий.

4. Игрок улучшает характеристики персонажа(ей), используя элементы снаряжения.

5. Игрок находит новые игровые области (исследует мир).

6. Игрок находит предметы и хранит их в инвентаре персонажа(ей).

7. Игрок получает информацию (общаясь с другими персонажами, находя подсказки, решает головоломки и проч.).

8. Игрок выполняет сюжетные задания.

9. Игрок взаимодействует (общается, сражается совместно или против) с другими персонажами (игроками и компьютером).

…

Функциональное тестирование (некритические функциональные области)

10. Игрок создает дополнительных персонажей.

11. Игрок должен планировать развитие персонажа(ей).

12. Игрок выбирает путь из нескольких вариантов.

13. Игрок воздействует на игровой мир (открывает сундуки, обыскивает убитых врагов и проч.).

14. Игровой мир воздействует на персонажа игрока (опасные зоны, ловушки и проч.).

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

16. Сюжет зависит от решений и выбора игрока. Часть этих выборов имеют последствия для сюжета.

…

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

Можно подвести итог.

1. Игры одного жанра «устроены» примерно одинаково и совпадают в геймплейных элементах (см. схему выше).

2. Определив жанр игры, мы можем определить «ядро» ее геймплейных элементов и механик.

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

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

Задание. Тестирование ключевого функционала игрового персонажа в RPG.

Персонаж и его характеристики

Игровой персонаж (герой) имеет основные характеристики: здоровье (HP), уровень (Level), опыт (Experience), сила (Strength), ловкость (Agility), интеллект (Intelligence), а также другие специфические характеристики (если применимо).

Персонаж может выполнять различные действия в игре: атаковать, использовать заклинания (если доступны), перемещаться по миру игры, взаимодействовать с объектами и NPC и т. д.

Задачи для тестирования

1. Тестирование боевых характеристик

2. Тестирование управления и взаимодействия

3. Тестирование системы прокачки и опыта

4. Тестирование анимаций и звуков

5. Тестирование сохранения и загрузки игры

Укажи, какие области и аспекты ты протестируешь в первую очередь по каждой из задач.

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

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

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

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

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

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

4.2.2. Тестирование уровней (игровых карт)

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

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

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

Концептуальный дизайн. На этом этапе дизайнер уровней обдумывает все особенности локации, которые сделают процесс игры интересным и увлекательным. Как правило, на этом же этапе художник делает набросок уровня. Выделяются различные зоны: места спавна[27] персонажей, места крафта ресурсов, интерактивные элементы и проч.

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

Пример greybox

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

Диспропорция укрытий

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

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

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

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

1. Пропасти в карте (Map holes)

2. Невидимые стены (Invisible walls)

3. Застревания (Stuck points)

4. Дефекты измененного ландшафта (Landscape changes defects)

5. Видимые стыки между текстурами (Visible texture seaming)

6. Дефекты разрушаемого окружения (Destructible environment defects)

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

Проваливание персонажа «под карту». WWZ © 2019, Saber Interactive

Например, в игре Fortnite: Save the World в одном из подземелий долгое время был «разрыв» на карте, куда персонаж мог провалиться и погибнуть.

«Разрыв» на карте. Fortnite: Save the World © 2017, Epic Games

Еще один пример map hole – неплотное примыкание скал и поверхности в игре Apex Legends. В эту дыру время от времени проваливались игроки.

Разрывы геометрии моделей на карте. В данном случае «пол» не примыкает к «стенам». Apex Legends © 2019, Respawn Entertainment

Невидимые стены (Invisible Walls) – как правило, результат неправильного моделирования объектов. Часто они появляются, когда видимая модель объекта не совпадает с моделью коллизий, то есть физической моделью объекта, которая придает осязаемость объекту.

Невидимая стена. Marvel’s Spider-Man © 2018, Insomniac Games

Иногда невидимые объекты в игре позволяют даже повиснуть на них. Assassin’s Creed: Unity © 2014, Ubisoft

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

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

«Застревания». Дефекты, связанные с застреваниями, могут быть вызваны различными причинами. Одной из причин может быть перестройка уровня и нарушение при этом использования навигационной сетки[28] (Navigation Mesh) или ее автоматической генерации. Например, при перестройке уровня были передвинуты модели, но навигационная сетка осталась старой. Как следствие, NPC могут «идти в стену» или любой другой предмет, который они не смогут обойти, и застрянут там (это как раз и есть один из случаев застревания – stuck point).

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

Склон сделали более пологим, а персонажи «повисли» в воздухе. Black Desert © 2015, Pearl Abyss

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

«Шов» между текстурами. WWZ © 2019, Saber Interactive

Дефекты разрушаемого окружения. Если окружение в игре не интерактивное, то есть игрок не может с ним взаимодействовать, уровень реалистичности такой игры остается довольно низким, даже если объекты окружения проработаны с безупречной точностью и четкостью. Понятие «разрушаемое окружение» относится к различным объектам: ландшафту (для этого существует специальный термин – деформируемый ландшафт), растительности, интерьеру, зданиям и сооружениям и т. д. Обычно особое внимание созданию разрушаемого окружения уделяется в играх, где это становится важной частью геймплея или даже игровыми механиками. Например, в игре Worms W. M.D., как и в ее предшественнице, разрушаемые уровни позволяют вносить в геймплей дополнительные возможности для игрока, влияя на его стратегию, и добавляют в игру изрядную долю веселья.

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

К дефектам разрушаемого окружения можно отнести следующее.

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

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

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

Деформируемый ландшафт может быть важной игровой механикой. Worms W. M.D. © 2016, Team 17

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

4.2.3. Тестирование моделей и анимации

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

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

1. модели (персонажи, предметы, транспорт и т. д.):

a. коллизии моделей;

b. анимация моделей;

2. визуальные эффекты (VFX);

3. освещение сцены, отражения и тени.

Рассмотрим эти области графической подсистемы подробнее.

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

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

Концепция (Concept). Здесь происходит выбор визуального стиля будущей модели. Именно на этом этапе закладывается фундамент для всей последующей работы.

Моделирование (High-poly). На этом этапе происходит создание 3D-модели в специальном редакторе[29]. Этот процесс может проходить по-разному, но в случае персонажей он похож на создание скульптуры, в котором мастер создает максимально реалистичную модель.

Ретопология (Low-poly). Игровая модель чаще всего состоит из полигонов, то есть многоугольников, угловые точки которых имеют точные координаты в 3D-пространстве и соединены между собой линиями. Чем выше детализация, тем большее количество полигонов должно быть использовано в моделировании (модели high-poly); чем она ниже, тем меньше нужно полигонов (модели low-poly). Этот этап предполагает упрощение геометрии модели и уменьшает количество использованных полигонов при сохранении достаточно высокого качества модели.

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

Пример low-poly, mid-poly и high-poly моделей

Развертка (UV mapping). Сетку полигонов, из которой состоит 3D-модель, необходимо «развернуть» в 2D-пространстве для последующего текстурирования. Другими словами, сопоставить X, Y и Z координатам 3D-модели координаты U и V «развертки» (буквы U и V используются, потому что X и Y уже заняты). UV-развертка похожа на детали выкройки, которые портной вырезает из ткани, чтобы потом сшить пиджак.

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

Текстурирование модели (Skinning), которое происходит на последующих этапах, заключается в наложении заранее подготовленных растровых текстур на 3D-полигональную модель для имитации рельефа, придания цвета и окраски.

На этом этапе могут возникнуть ошибки, связанные с:

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

• выбором некачественных текстур низкого разрешения;

• неверной настройкой прозрачности текстур, параметров отражения и преломления;

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

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

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

Дефекты моделей

Заметные швы между частями тела персонажа

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

Слишком большое количество полигонов

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

Несоответствие историческому (реальному) прототипу

Посмотри на изображение автомата на картинке дальше. Ничего странного не замечаешь?

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

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

Из такого АК-47 можно стрелять только в игре. Counter-Strike 1.6 © 2000, Valve

А вот T-34-85M полностью идентичен со своим прототипом. World of Tanks © 2010, Wargaming.net

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

Дефекты коллизий и хитбоксов

Ты наверняка замечал, что большинство случаев взаимодействия моделей основано на их касании друг друга. Чтобы игрок воспринимал такое взаимодействие как реалистичное, используются так называемые модели коллизий – объекты, невидимые игрокам, но обладающие физическими свойствами. Их называют коллайдерами (colliders). По сути, коллайдер – это невидимая упрощенная форма объекта, привязанная к нему, для расчета результата столкновения с другими объектами. Поэтому большинство объектов виртуального мира игры не проходят друг сквозь друга, а ведут себя естественно, а точнее, как их запрограммировал разработчик: персонажи не проваливаются сквозь землю и не проходят сквозь стены, потому что сами содержат коллайдер с настройками физики.

Часто взаимодействие персонажей происходит агрессивно, то есть с нанесением физического урона. Поэтому модель коллайдера включает в себя так называемый хитбокс (hit-box). Хитбокс – это часть физической модели, при столкновении с которой запрограммированный объект (например, пуля, копье, меч или кулак) «наносит урон», а точнее, если запрограммированный на нанесение урона объект сталкивается с хитбоксом физической модели (коллайдера) другого объекта, из переменной здоровья второго объекта вычитается определенное количество единиц здоровья (health points). На практике это выглядит так: «Персонаж стреляет из лука в кабана, стрела попадает в кабана (но не в голову или сердце), кабан визжит от боли и начинает спасаться бегством. Повторное попадание стрелы в кабана, скорее всего, его убьет».

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

Дефект коллизии объектов. NHL 16 © 2015, EA Vancouver

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

Еще одна задача – проверка корректного размещения хитбоксов и урона, наносимого объекту при взаимодействии с ними. Ошибки тут могут вызвать фрустрацию у пользователей. Например, в игре Battlefield 2042 физическая модель с хитбоксами у одной из моделей (Falck) была шире, чем ее видимая модель, что приводило к более частым смертям персонажа.

Хитбоксы, не соответствующие модели персонажа, позволяют поражать врага, стреляя мимо него. Counter-Strike 2 © 2023, Valve

Дефекты анимации

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

Есть и другие примеры багов анимации.

Дефекты лицевой анимации (Facial Animation)

Лицевая анимация у модели может создаваться разными способами: на основе блендшейпов (Blend Shapes, форм для смешивания), а также мускульной или кластерной (на основе костей) модели. Распространенный способ с помощью блендшейпов подразумевает создание базовой модели лица персонажа с нейтральным выражением лица и производства на основе ее копий «выражений» (эмоций) в необходимом количестве с обязательным сохранением количества вершин полигонов и их нумерации (то есть их нельзя объединять, удалять или добавлять новые). Затем при создании анимации в редакторе указывается базовая модель и целевая модель (Target). После этого можно использовать управляющие элементы для плавного перехода от одной модели к другой (например, от нейтрального выражения до улыбки). Частный случай дефектов лицевой анимации – дефекты синхронизации губ (Lip Sync), когда отсутствуют блендшейпы отдельных фонем, используются неправильные последовательности блендшейпов или анимация отсутствует совсем.

Вибрация камеры (Camera Shake)

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

«Расчлененка» (Dismemberment Gore System, отрывы конечностей, разрыв тела)

Чтобы реализовать этот эффект, модель нужно подготовить – «разрезать» на мелкие части. Триггер эффекта – одновременное соблюдение некоторых условий.

1. Персонаж должен иметь менее определенного количества очков здоровья (health points).

2. Он должен получить урон из определенного вида оружия.

3. Выстрел из этого оружия должен быть произведен в определенную область персонажа.

При выполнении этих условий эффект выражается в отрыве части или «взрыве» модели с разлетанием ее частей и добавлением специальных эффектов крови и т. д.

К дефектам здесь можно отнести неестественный отрыв конечности, оставлением на месте одной или нескольких частей модели при «взрыве» тела, отсутствие спецэффектов.

Первые попытки реализовать расчлененку. Doom II: Hell on Earth © 1994, id Software

Переходы между анимациями

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

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

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

Дефекты, связанные с аппаратной частью

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

Разрыв экрана (Screen Tearing) – прямо не относится к проблеме графики, поскольку связан больше с аппаратной частью. Однако этот дефект имеет четкое визуальное воплощение – искажения в изображении сцены. Дело в том, что у каждого монитора есть такой показатель, как частота обновления экрана (характеристика, обозначающая количество возможных изменений изображения в секунду: 60 Гц, 144 Гц, 165 Гц, 240 Гц и т. д.). Если же видеокарта отправляет на монитор больше кадров, чем тот может отобразить, то кадры накладываются друг на друга, и получается «разрыв». В играх используется технология V-Sync, которая искусственно понижает FPS в игре, чтобы частота кадров в игре и частота обновления монитора совпадали.

Разрыв экрана. Слабая видеокарта или «тяжелая» сцена? MX Nitro: Unleashed © 2017, Saber Interactive

Неверный уровень детализации (Level of Detail) – на игровой сцене могут одновременно находиться много объектов, находящихся на разном «расстоянии» от камеры (для имитации перспективы). Для снижения нагрузки на аппаратную часть игровой платформы при разработке применяется технология, которая использует модели с разным уровнем детализации. Очевидно, что в играх нет необходимости воспроизводить каждый кирпич на стене удаленного объекта, если глаз все равно не в состоянии его различить. К тому же обработка данных о нескольких сотнях тысяч невидимых полигонов загрузит процессор бесполезной работой.

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

Модели с разным LoD для использования на разном «расстоянии» от камеры

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

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

Пример использования LoD. Half-Life © Valve, 1998

Дефекты, возникающие при использовании технологии уровня детализации, связаны с низкой производительностью системы. Разработчики стараются, чтобы увеличение детализации объекта или подмена модели происходили плавно и незаметно для игрока, хотя это не всегда так. В играх, работающих на слабом аппаратном обеспечении, низкополигональные модели могут не заменяться высокополигональными с достаточной скоростью. В результате игрок, «приближающийся» к объекту, сначала увидит «уродливую» модель, которая затем сменится на более качественную.

Ошибка LoD. The Elder Scrolls V: Skyrim © 2011, Bethesda Game Studios

Фантомная графика (Ghosting) – это не дефект игры, а явление, при котором на экране отображается несколько смещенных изображений объекта. Это происходит, когда предыдущее изображение продолжает появляться на экране вместе с последним даже при переходе к следующему кадру, что дает размытый, «призрачный» эффект. Причины такой фантомной графики – частота обновления экрана и время отклика. Частота обновления экрана – это скорость, с которой твой монитор обновляет изображение на дисплее, а время отклика – время, которое требуется процессору на вывод на дисплей нового изображения поверх старого. Слишком короткое время отклика не позволяет быстро сменить предыдущее изображение на текущее. Повторим: это не дефект игры, но ты можешь рассматривать его как некоторый дефект аппаратной части, который требует устранения. Особенно это актуально для динамичных игр, в которых нужны быстрая реакция и высокая скорость движения.

Мерцание (Flickering) – часто встречающийся термин при описании бага. Обычно имеется в виду то, что объект (текстура, частицы и др.) мерцает, мигает, пропадает и появляется с определенной периодичностью. Мерцание также может быть связано с настройками времени отклика.

Некоторые графические баги могут быть связаны с проблемами клиппинга, или обрезки. Клиппинг (Clipping) – это метод обработки и оптимизации изображения так, чтобы не рендерить части изображения, находящиеся вне пределов видимости пользователя. Это помогает существенно экономить вычислительные ресурсы видеокарты. Представь себе луч фонаря в темноте. Ты видишь только то, что попадает в зону луча; все остальное остается невидимым. Зона или, вернее, объем видимости обычно имеет вид усеченной четырехугольной пирамиды (фрустум) с виртуальной камерой в вершине, то есть ограничен шестью плоскостями. Плоскости, перпендикулярные камере, называются Near Plane (ближняя плоскость, NP) и Far Plane (FP, дальняя плоскость). Таким образом, объекты, не попадающие в указанный объем, не будут учитываться при рендеринге, и пользователь их не увидит. Точнее, не должен видеть.

Область видимости определяется шестью плоскостями отсечения. Объекты Б и В находятся вне объема видимости и будут отсечены при рендере

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

Ошибка клиппинга. WWZ © 2019, Saber Interactive

Кроме того, для оптимизации вычислительных ресурсов применяются и другие методы, позволяющие отсекать те части сцены, которые пользователь видеть не должен, – например, отсечение (culling). Впрочем, часто эти понятия (clipping и culling) используют как синонимы.

Окклюзивное отсечение (Occlusion Culling) – дефекты, связанные с некорректной работой алгоритмов обрезания невидимых объектов, а точнее, отображения того, что скрыто. Например, если мы видим два непрозрачных объекта, один из которых частично находится позади другого, то часть этого объекта нам не будет видна. В игре эта часть объекта должна быть исключена из процесса рендеринга еще до его начала для оптимизации ресурсов. Однако из-за неправильной работы графического процессора мы начинаем видеть ту часть объекта, которая должна быть скрыта. В жизни такое произойти не может. В компьютерной игре – запросто!

Все, что должно оставаться невидимым, стало видимым. Watch Dogs © 2014, Ubisoft

Сшивка (Z-Fighting, Stitching) – дефект рендеринга, при котором два примитива начинают попеременно перекрывать друг друга, вызывая мерцание на экране. Это происходит из-за того, что они оба находятся так «близко» к камере, что графический процессор не понимает, что он должен отобразить в конкретном пикселе на экране и какую информацию необходимо взять из Z-буфера, который отвечает за «глубину»; координаты примитивов очень близки или совпадают. При изменении сцены (например, когда игрок чуть отходит и снова приближается к этому месту) дефект проявляет себя как мерцание, графические шумы, потому что один из двух примитивов попеременно «выигрывает» борьбу, и его данные используются для окрашивания пикселей экрана.

Z-fighting во всей красе

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

Дефекты, связанные с «человеческим фактором»

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

Отсутствующие текстуры. Не подгрузились или их никогда там не было? Mount & Blade II: Bannerlord © 2020, TaleWorlds

Визуальные артефакты и графические «глюки» (Visual Artifacts and Graphical Glitches) – если честно, то это дефекты, которые я не могу отнести в вышеперечисленные группы. Иногда даже бывает сложно понять причину появления таких багов. «Глюки», как правило, связаны непосредственно с нестабильной работой графического процессора, его драйверов и др. К таким дефектам можно отнести «блуждающие пиксели» – артефакты, возникающие вокруг объектов и пропадающие при смене угла зрения.

Визуальный дефект. The Elder Scrolls V: Skyrim © 2011, Bethesda Game Studios

4.2.4. Тестирование визуальных эффектов (VFX)

Визуальные эффекты традиционно разделяют на:

1. геймплейные эффекты: визуализация магии, эффекты оружия, взрывы, разрушения и т. д.;

2. природные эффекты или эффекты окружений: водопады, туман, дождь, снег и т. д.

Чтобы ориентироваться в теме визуальных эффектов, тестировщику можно воспользоваться знанием принципов их создания.

1. Правило трех форм

Создатели визуальных эффектов считают, что эффект должен содержать в себе три формы: первичную, вторичную и третичную. Это помогает созданию у зрителя лучшего восприятия эффекта. Использование меньшего или большего количества форм – не обязательно дефект, но в данном случае я опираюсь на «классический» подход разработки.

Примеры визуальных эффектов, которые основаны на использовании трех форм

2. Правило трех цветов

Согласно этому правилу, эффект будет нескучным и произведет на зрителя впечатление, если специалист по спецэффектам будет соблюдать правило 70:30. То есть отношение основного цвета к вторичному и третичному вместе будет 70 к 30, а отношение вторичного к третичному – тоже 70 к 30.

3. Правило трех значений контрастности

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

Пример трехцветного визуального эффекта с тремя уровнями сатурации. Tanks a Lot! © 2018, Highcore Labs LLC

4. Принципы анимации

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

«Ожидание» эффекта поражения древней стрелой. The Legend of Zelda: Breath of the Wild © 2017, Nintendo Entertainment Planning & Development

«Действие» эффекта поражения древней стрелой. The Legend of Zelda: Breath of the Wild © 2017, Nintendo Entertainment Planning & Development

«Реакция» эффекта поражения древней стрелой. The Legend of Zelda: Breath of the Wild © 2017, Nintendo Entertainment Planning & Development

5. Вторичная и третичная анимация

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

Сравни эти взрывы. Какой тебе кажется эффектнее?

6. Время эффекта

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

7. Физические законы

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

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

Для примера разберем эффект, который называется Muzzle Flash (Вспышка выстрела).

Можно выделить примерные этапы данного эффекта.

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

• Основная вспышка – происходит в момент вылета пули и смеси разогретых газов из ствола оружия. Вспышка имеет разные цвет, форму и интенсивность.

• Искры – создаются несгоревшей частью пороха, вылетающего из дула, после выстрела.

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

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

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

Пример слишком высокой плотности «тумана»

4.2.5. Тестирование освещения, отражений и теней

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

Свет может быть искусственным и естественным, может иметь направление, отражаться, преломляться и иметь разную интенсивность.

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

Тени от объектов падают в разные стороны. Сколько в небе Солнц? Assassin’s Creed IV: Black Flag © 2013, Ubisoft Montreal

Здесь светильник слева светит, но ничего не освещает. WWZ © 2019, Saber Interactive

Реалистичное отражение на разных отражающих поверхностях – довольно сложный процесс. Для его реализации разработчики используют различные технологии: от «зеркальных» уровней и виртуальных камер (planar reflections) в очень старых играх до кубических текстур (cubemaps) и трассировки лучей (ray tracing) в современных проектах. В дальнейшем появятся и другие технологии для решения таких задач.

То, что игрок видит в зеркалах, – «виртуальные камеры» для имитации отражения

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

Кубические текстуры или кубическая карта (Cubemaps) – это методология создания отражений объектов на отражающей поверхности путем отображения координаты текстуры в трехмерном пространстве в тексель[30] (то есть получения изображения пикселя на экране, которое имеет свой цвет и другие характеристики и является отражением какого-то объекта на отражающей поверхности). Для этого используется развертка шести граней куба (подобная UV-развертке, о которой говорилось выше), на каждой из сторон которого заранее «запечена» текстура.

Пример кубической карты

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

Текстурная выборка из кубической карты с вектором направления «зрения» из центра куба

Преимущество такой технологии – существенное снижение нагрузки на аппаратную часть платформы, потому что текстуры на гранях куба рендерятся заранее. Но это преимущество может быть и недостатком. Поскольку cubemaps используют заранее «запеченные» изображения, динамические объекты в них не отражаются. И поэтому возникают проблемы с отрисовкой игрового персонажа: иногда персонаж может подгрузиться с запозданием, а иногда, наоборот, «отраженный» игрок загружается, а окружение – нет.

Иногда персонажи «превращаются в вампиров», забывая отражаться в зеркальных поверхностях. Watch Dogs © 2012, Ubisoft

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

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

Так устроен процесс построения модели с использованием трассировки лучей

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

Из-за высоких требований к вычислительным ресурсам отражениям не хватает детализации и объема. Marvel’s Spider-Man © 2018, Insomniac Games

К дефектам освещения можно отнести также нарушенную автоэкспозицию (Auto Exposure или Eye Adaptation). Представь себе, что ты выходишь из темного подвала, где провел полдня, на открытое ярко освещенное пространство двора. Ты непроизвольно жмуришься от обилия света до тех пор, пока глаза не адаптируются к освещению. В играх такой прием используется в аналогичных ситуациях, чтобы добавить реалистичности. Иными словами, уровень экспозиции сцены меняется, делая сцену или ее части ярче/темнее и имитируя адаптацию зрения. Это позволяет добавить реалистичности происходящему.

Еще один дефект освещения – неправильное использование или работа бликов (Lens Flare Effect). Блики используются для придания освещению сцены реалистичности и имитации очень ярких источников света.

Lens Flare Effect хорош, но кажется, что в глаза игрокам направлены сразу несколько очень мощных прожекторов, причем почти постоянно. Syndicate © 2012, Electronic Arts

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

Такой подход к тестированию называют художественным. Задачей специалиста здесь становится проверка:

• геометрии объектов;

• текстур;

• физических моделей;

• моделей коллизий.

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

Техническое тестирование призвано обнаружить дефекты, связанные, например, с:

• форматом графических файлов;

• наличием необходимых графических файлов в соответствующих каталогах;

• целостностью этих файлов;

• соответствием модели требованиям игрового движка с точки зрения ограничений на количество полигонов;

• другими техническими аспектами, например с проверкой дистанций для переключения моделей (LoD).

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

4.2.6. Тестирование звука

Звуковая подсистема игры – это один из очень важных игровых элементов, увеличивающих иммерсивность, то есть погружение игрока в сюжет.

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

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

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

2. Ориентация в пространстве. Такие звуки помогают игроку понять, находится ли он в закрытом помещении или на открытой местности.

3. Ориентация на местности. Игрок использует звуки для ориентации в пространстве, например, когда передвигается в различных средах: по воде, песку, снегу и т. д.

4. Оповещение. Звуки используются для сообщения о событиях, которые визуально не воплощаются на экране: например, игрок достигает определенного уровня.

5. Атмосфера. Это звуки окружения для усиления погружения в игровой процесс: звуки города, фермы, боевых действий и т. д.

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

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

Одни и те же звуки могут выполнять различные функции. Например, звуки, которые выполняют сигнальную функцию и функцию оповещения, могут использоваться и для создания определенной атмосферы в игре (вспомни «Killing Spree! – Rampage! – Dominating! – Unstoppable! – GODLIKE!» в Unreal Tournament).

Весь игровой звук можно разделить на шесть групп.

• Фоновая музыка

• Звуки интерфейса

• Звуки окружения

• Звуки персонажей

• Звуковые эффекты

• Голосовая озвучка персонажей

Музыка – своеобразная визитка игры. Она используется для создания и передачи определенного настроения. Кроме того, музыка в игре может влиять на действия игрока, побуждая ускоряться или, наоборот, замедлиться.

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

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

Звуки персонажей (Foley) – это все звуки, производимые персонажами, за исключением речи. Это могут быть звуки шагов, открывающихся дверей, звон ключей в связке и проч., то есть все те звуки, которые придают игре больше реализма. Эта группа звуков, как и профессия человека, занимающегося их производством (Foley artist), была названа в честь Джека Донована Фоули – одного из первопроходцев в области звуковых эффектов для кинематографа.

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

Голосовая озвучка персонажей (Voiceover) может быть записана для игровых и неигровых персонажей для увеличения звукового разнообразия. При этом у нее есть некоторые особенности.

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

2. Персонажи могут не быть озвучены вовсе, и это не повлияет на атмосферу игры. Например, главный персонаж в Quake или Half-Life не произносит ни единого слова за всю игру, а в The Legend of Zelda: Breath of the Wild не озвучен ни один NPC (non-player character).

Чтобы погрузить пользователя в атмосферу игры, специалисты по созданию звукового сопровождения часто используют различные приемы: от использования повышенного уровня звука в обычных сценах (например, громкость ударов и падений в драках) до сложных звуковых эффектов и тонкой настройки звуковых зон[31].

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

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

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

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

1. Отсутствие звука

2. Проигрывание неправильного звука

3. Неправильное проигрывание звука

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

Во втором случае мы имеем дело с неправильной настройкой звука (например, собака в игре начинает щебетать как птица, а лошадь – хрюкать как свинья) или несоответствием звукового сопровождения реальному прототипу (когда герои прошлого используют современный сленг или современный самолет издает звук аэроплана времен братьев Райт). Особенно это важно в тех случаях, когда аутентичность и историческая достоверность заявляются как ключевые особенности (key features) игры.

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

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

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

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

1. Наличие звука у конкретного игрового события.

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

• Стоя у водопада, игрок не слышит звука падающей воды.

2. Соответствие созданных звуков объекту, игровой ситуации и сеттингу игры (при условии, если это не гениальная задумка гейм-дизайнера).

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

• Эффекты накладываемых магических заклинаний будут звучать неуместно в игре про Вторую мировую войну.

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

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

3. Отсутствие неуместных звуковых включений и артефактов в звук события.

• К звуку взрывов примешаны голоса людей, которых нет в сцене.

• В звуке отсутствуют посторонние вкрапления: щелчки, стуки и т. д.

4. Отсутствие раздражающих игроков звуков (вроде звука трения пенопласта по стеклу).

5. Громкость созданных аудиофайлов.

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

6. Неправильное позиционирование звука в зависимости от его источника.

• Кузнец кует оружие в кузнице рядом с таверной, непрерывно ударяя молотом по куску металла. Однако игрок слышит этот звук из угла своей комнаты.

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

7. Неправильно настроена зона звукового покрытия.

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

• Все звуки производства пропадают, как только персонаж выходит за ворота фабрики.

8. Соответствие записанных актерами реплик персонажей игровому сеттингу и ожиданиям игроков.

• Голос актера не соответствует полу и возрасту персонажа.

• Голосовые характеристики актера озвучки не соответствуют ожиданиям игроков. Например, персонаж из страны Ближнего Востока говорит с выраженным ирландским акцентом.

9. Соответствие звуков звукам реальных прототипов (историческая достоверность).

• Голос исторического персонажа, известного публике, звучит совершенно не похоже на прототип.

• Звук граммофона звучит как звук современной аудиосистемы.

10. Сочетание всех звуков, включая музыку.

• Фоновая музыка заглушает важные для игрового процесса звуки.

11. Зацикливание, искажение, пропадание, задержки, прерывания.

• Игроки слышат, как звук начинает трещать или шипеть.

• При выстреле из орудия звук воспроизводится дважды.

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

12. Отсутствие необходимых эффектов, добавляющих реалистичности звуковому сопровождению.

• Персонаж, находясь в пещере, громко зовет напарника. При этом полностью отсутствует эхо.

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

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

Кроме контентно-аудиального тестирования, специалист обязательно должен проверить следующее.

• В игре можно включать и выключать звуки и/или музыку.

• Можно изменить громкость.

• Все аудиофайлы названы с соблюдением единого формата и распределены по каталогам в проекте.

• На игровой карте правильно расставлены источники звука и звуковые зоны.

• Звуки совместимы на разных аудиосистемах: наушники, колонки, мониторные колонки, 5.1, 7.1, домашний кинотеатр и другие используемые системы и технологии.

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

Критерии оценки звуковой картины, которые должны учитываться тестировщиком:

• созданное звуковое сопровождение не уменьшает количество FPS озвучиваемой сцены;

• созданное звуковое сопровождение не является причиной утечек памяти[32];

• установленные при разработке игры лимиты по звукам соблюдены (например, лимит на количество одновременно проигрываемых звуков);

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

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

4.2.7. Тестирование искусственного интеллекта (ИИ) персонажей

На словах «искусственный интеллект» в голове чаще всего всплывает образ некоего андроида или суперкомпьютера гораздо умнее и быстрее человека. Однако в играх все пока зашло не так далеко. То, что в играх называют искусственным интеллектом, – довольно сложный алгоритм действий, который создан так, чтобы имитировать поведение человека-противника.

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

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

Для сбора информации компьютерные персонажи, как и в реальной жизни, используют органы чувств: зрение, слух, реже обоняние. Конечно, игровой персонаж не может «видеть» в общепринятом смысле, поэтому для имитации «зрения» используются виртуальные рецепторы – зоны видимости, от примитивных конусов до комплексных сенсоров. Часто такие сенсоры позволяют персонажам «почувствовать», что кто-то находится у них за спиной. В еще более сложных алгоритмах может использоваться технология рейкастинга (похоже на рейтрейсинг, о котором я упоминал выше): из «глаз» персонажа исходят лучи и, если они пересекают несколько частей тела главного персонажа, противник поднимает тревогу или совершает иные действия.

Похожим образом устроены другие «органы чувств» – слух и обоняние.

Тело главного персонажа разделено на 8 частей. Если лучи, исходящие из «глаз» противника, пересекают две и более из них, то противник «видит» персонажа даже за укрытием. Tom Clancy’s Splinter Cell: Blacklist © 2013, Ubisoft

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

В старых играх ИИ представлен довольно примитивными алгоритмами, типа предопределенного набора правил (rule-based AI), как в Pac-Man. В более современных продуктах для принятия решений и совершения действий используются более сложные архитектуры и их модификации:

• конечный автомат (Finite State Machine, FSM);

• поведенческое дерево (дерево принятия решений, Behavioral Tree);

• различные миксы этих архитектур (например, иерархические конечные автоматы);

• служебный ИИ (Utility AI).

ИИ в Pac-Man был основан на простейшем алгоритме: один противник всегда поворачивал влево, второй – только вправо, третий – в обе стороны, и только четвертый преследовал игрока. Pac-Man © 1980, Nintendo

Конечный автомат – довольно простая архитектура игрового ИИ. Основной его элемент – состояние, то есть конкретное действие (или набор действий), которое персонаж выполняет в данный момент. Поведение персонажа определяется логикой определения действий и смены (или сохранения) состояния. При этом логика может быть простой или усложняться. На схеме ниже приведен пример логики поведения персонажа-охранника, патрулирующего местность.

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

Логика поведения персонажа определяется полученной информацией в том состоянии, в котором персонаж находится. В зависимости от новых условий (полученной информации) персонаж переходит в другое состояние.

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

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

Архитектура поведенческого дерева с использованием алгоритма Монте-Карло, когда ИИ выбирает наиболее подходящее состояние в текущей ситуации, исследуя разные ветки дерева

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

Когда персонаж, основная задача которого – патрулирование на автомобиле, теряет этот автомобиль (например, его уничтожает игрок) и после потери игрока из вида должен вернуться к патрулированию, он может «зависнуть», не найдя средство передвижения. Дерево поведения позволяет персонажу выбрать свое новое состояние и перейти на пешее патрулирование без всяких проблем. Это дает более плавный и более реалистичный переход между разными состояниями персонажа.

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

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

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

Один из способов динамического принятия тактических решений персонажами – система подсчета очков при оценке выгодности действий. Она позволяет ИИ совершать обдуманные тактические маневры без досконального знания игрового мира, выявляет доступные для ИИ действия и начисляет им очки в зависимости от складывающихся обстоятельств, тем самым выбирая наиболее выгодное. На этих принципах работает архитектура служебного ИИ (Utility AI). Другими словами, ИИ принимает решение о совершении какого-либо действия на основании того, насколько такое действие «выгодно» по сравнению с другими вариантами в текущей ситуации, то есть совершает действие, которое оценено в наибольшее количество очков.

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

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

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

Для обозначения пути, по которому может перемещаться персонаж, используются навигационные сетки (Navigation Meshes, NavMeshes). Это некоторая структура данных, которая описывает поверхности игрового мира так, что позволяет персонажу находить путь из одного места в игровом мире в другое (Pathfinding).

Ошибка с NavMesh приводит к тому, что персонаж не сможет перейти через «разрыв»

Таким образом, можно говорить о двух приоритетных типах дефектов, связанных с ИИ в играх.

1. Неправильное взаимодействие персонажа с ИИ с игровыми объектами и игроком. Как правило, эти баги связаны с неправильными настройками алгоритмов ИИ. Например, ваш помощник перестает помогать вам, враги не нападают на вашего персонажа и т. д.

2. Отсутствие движения персонажа, «застревания» во время движения. Нарушен pathfinding вследствие некорректной навигационной сетки или объектов, блокирующих передвижение персонажа по NavMesh. Персонаж с ИИ не может продолжить движение и застывает на месте или продолжает «идти» в невидимую стену.

На скриншотах ниже представлены примеры таких дефектов.

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

Один из неигровых персонажей циклично пугается главного героя даже тогда, когда последний не обращает на него никакого внимания. The Witcher 3: Wild Hunt © 2015, CD Projekt RED

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

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

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

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

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

4.2.8. Тестирование игровой физики

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

У игровой физики много задач, но самая главная – сделать игру интуитивно понятной и увлекательной. Когда объекты ведут себя непонятно, пользователь не понимает правила игры.

При этом мы, как тестировщики, должны понимать, что строгое соблюдение физических законов в игре очень часто не требуется, а иногда может убить все веселье. Только представь Need for Speed, в которой реализованы реальные законы физики. Любое столкновение на трассе каждый раз будет приводить к фатальному результату, и в игру невозможно будет играть. Если бы Марио подчинялся реальным физическим законам, то он никогда бы не прошел даже первый уровень, потому что в реальном мире (кроме индийского кино, конечно) не бывает «двойного» прыжка. А если бы в снайперском симуляторе игроку пришлось бы учитывать скорость и направление ветра, скорость движения цели, освещение, угол выстрела и другие факторы, то игра бы усложнилась многократно и нашла гораздо меньше поклонников.

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

1. Дефекты разрушений

2. Дефекты поведения объектов

В играх физика делится на две категории: физика твердого тела и мягкого тела. Физика мягкого тела описывает силы, которые воздействуют на объект и тем изменяют его форму (например, флаг, вода или одежда персонажа; по сути, к этой категории можно отнести все элементы, которые могут деформироваться при воздействии внешних сил).

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

В некоторых случаях, например в реализации «физики женской груди» (breast physics, jiggle physics), по факту являющейся мягким телом, могут использоваться технологии физики твердых тел.

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

Реализация физики груди с помощью дополнительных костей и суставов

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

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

Пружина, которая может двигаться в разных направлениях (влево-вправо, вверх-вниз), становится «основой» для анимации женской груди

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

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

И все же чаще всего под игровой физикой понимается физика твердого тела (Rigid Body Physics, RBP).

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

• силы тяжести (объект левитирует или взмывает вверх на значительную высоту);

• силы инерции (при резкой остановке быстро двигающийся тяжелый объект мгновенно останавливается);

• силы трения (тяжелый объект долго скользит по нескользкой поверхности);

• центробежной силы (автомобиль на огромной скорости входит в поворот по внешней полосе и без торможения проходит его) и др.,

или в том, что объекты обладают свойствами, невозможными в реальном мире, – например, огромной скоростью.

Левитация игрока в игре. NHL 16 © 2015, EA Vancouver

Летающие повозки – пример дефекта игровой физики. Red Dead Redemption © 2010, Rockstar

Отдельно нужно упомянуть дефекты, возникающие в тех случаях, когда скорость одного объекта настолько высока, что коллизия с другим объектом (особенно небольшим) не успевает регистрироваться системой. Речь идет о различных пулях, снарядах, стрелах и т. д. (Projectile). Таких проблем можно избежать, используя технологии излучения (Raycasting) и сканирования попадания (Hitscan), которые не требуют создания физической модели снаряда. Алгоритм реализации выстрела выглядит следующим образом.

1. Определяется направление, в котором указывает ствол оружия.

2. Из ствола оружия выпускается луч на заданное расстояние.

3. Используется raycasting для определения того, пересекся ли луч с каким-либо объектом.

Если игровой движок определил, что объект находится на линии огня, то он «сообщает» ему, что в него «попала» пуля. После этого объект может выполнить все действия для того, чтобы система зарегистрировала его повреждения.

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

Основное достоинство Raycasting в том, что он быстро вычисляется и не требует дополнительной памяти или процессорного времени на создание нового физического объекта (пули).

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

Попадание пули во врага происходит одновременно с дульной вспышкой (Muzzle Flash). Halo: Combat Evolved © 2001, Bungie

Второй недостаток Hitscan – использование прямых лучей. То есть невозможно учесть погодные условия и нельзя использовать стрельбу «навесом» (например, из лука, пушки или миномета).

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

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

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

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

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

2. Можно использовать гранаты и снаряды с отложенным эффектом попадания/взрыва.

3. Использование дополнительной визуализации полета пули – Bullet time.

Полет пули в режиме bullet time в slow mo выглядит эффектно. Hunting Simulator © 2013, Neopica

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

Большинство существующих игровых движков способно обрабатывать оба типа симуляций пуль – Hitscan и Projectile ballistic. Это позволяет предоставлять игрокам огромный выбор оружия. Например, в том же Halo с Assault Rifle используется Hitscan, а с Needler – баллистика снарядов.

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

Если разбирать выстрел с точки зрения физики Projectile ballistic во время тестирования, то нужно учитывать следующее.

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

2. Скорость перемещения снаряда должна быть достаточно высокой (за исключением ручных гранат).

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

4. При попадании в объект-цель снаряд обычно уничтожается, а на объекте должны появиться следы от попадания и другие последствия (об этом я говорил выше, см. «Расчлененка» и «Дефекты VFX»).

5. При попадании в определенные поверхности снаряд может изменить траекторию движения, имитируя рикошет (например, при выстреле из пистолета в гранитную плиту, стоящую под наклоном).

6. Снаряд, как любой физический объект, может быть уничтожен другим снарядом (например, попадание одной ракеты или ее осколков в другую).

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

8. Снаряды могут состоять из различных материалов, в том числе жидкостей, поэтому на них по-разному влияют фундаментальные силы (например, GES Bio Rifle в Unreal Tournament).

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

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

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

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

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

До этого мы говорили о подходах и проверках, чтобы ответить на вопрос «Что умеет делать наш продукт?», но на этом тестирование игры не заканчивается. Хотелось бы понять, насколько удобным, безопасным и надежным получился игровой продукт. Чтобы выяснить, как он выполняет свои задачи, нужно провести нефункциональное тестирование. Оно включает в себя тестирование качественных характеристик игры или одной из ее подсистем, которые могут быть измерены различными величинами, не относящимися к конкретной функции или действию пользователя. Этот вид тестирования проводится для того, чтобы определить работоспособность игры в разных условиях и обстоятельствах.

Если говорить проще, то это тестирование того, «как» работает игровой продукт. Нефункциональное тестирование так же важно, как и функциональное, поскольку очень влияет на удовлетворенность пользователей.

4.3.1. Тестирование пользовательского интерфейса

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

• Интерфейс пользователя (GUI)

Окно выбора оружия и одежды персонажа GUI. Assassin’s Creed: Odyssey © 2018, Ubisoft

• Head-Up Display (HUD, проекционный дисплей), который может включать следующее.

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

· Мини-карта для лучшей ориентации игрока на уровне.

· Текстурные наложения: указатель прицела, пиктограммы оружия, радар и т. д.

· Компас или направление к цели.

HUD обеспечивает быстрый доступ игрока к нужной информации и важным функциям. World of Warcraft © 2004, Blizzard Entertainment

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

• Индикатор урона (Damage indicator), который показывает направление и силу получения урона персонажем.

Damage Indicator показывает направление получения урона и пораженную область. World of Tanks © 2009, Wargaming.net

• Агония (Pain Effect) – это дополнение к индикатору здоровья. Проявляется покраснением экрана, дрожанием экрана и другими эффектами, в том числе звуковыми для индикации того, что персонаж находится в критическом состоянии и ему срочно требуется пополнить здоровье.

Здоровье персонажа находится на критической отметке. Diablo III: Reaper of Souls © 2010, Blizzard Entertainment

• Подсказка (Hint) – это элемент графического интерфейса. Используется как дополнительное средство для предоставления информации пользователю во время обучения. Могут быть двух видов.

· Внутриигровые (появляются при наведении курсора на интересующий пользователя объект или для обучения пользователя).

· Загрузочные (появляются во время загрузки, чтобы пользователь мог лучше ознакомиться с особенностями игры).

Подсказка в режиме обучения игрока. Genshin Impact © 2020, miHoYo Limited

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

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

• GUI правильно масштабируется при разном разрешении экрана.

• Текст не содержит ошибок и отформатирован.

• Текст читаем на фоне.

• Дизайн унифицирован (цвет, шрифт, размер элементов).

• В интерфейсе отсутствуют пустые участки.

• Элементы интерфейса не накладываются друг на друга.

• При выделении и/или наведении курсора на элементы (кнопки, надписи, поля и т. д.) они меняют внешний вид.

• Элементы анимированы, и анимация не «притормаживает».

• Нередактируемые поля выглядят одинаково и отличаются от редактируемых.

• Дублированные формы имеют одинаковые названия.

• Если элемент недоступен или отключен (disabled), есть пояснение, почему.

• Возможно перемещать и выделять элементы с помощью клавиатуры.

• При наведении на некоторые элементы могут появляться всплывающие подсказки.

• Работают все «горячие» клавиши и ярлыки.

• При ожидании действия появляется элемент загрузки.

Когда я говорю о GUI-элементах, то подразумеваются описанные ниже. Для каждого из них есть свои проверки и ожидаемое поведение.

• Текстовое поле (Text field)

· Внутри элемента может находиться поясняющий текст, который пропадает при вводе данных пользователем.

· Работает выделение текста с помощью Ctrl+A / Shift+стрелка.

· Невозможно использовать больше символов, чем указано.

· Невозможно использовать пустое поле или меньше символов, чем указано.

· Отсекаются пробелы в начале, конце (а иногда и в середине).

· Невозможно использовать символы, отличные от указанных, специальные символы или код.

· При ошибке валидации поле выделяется и выводится текст, поясняющий ошибку.

· При вводе пароля в соответствующее поле вводимые символы меняются на звездочки (*).

• Радиокнопка/Переключатель (Radio button)

· Расположен рядом с соответствующим текстом.

· Одновременно может быть выбран только один элемент.

• Флажок (Check box)

· Расположен рядом с соответствующим текстом.

· Одновременно может быть выбрано несколько элементов.

· При большом количестве элементов может быть специальный элемент для отметки/снятия выделения всех.

• Кнопка (Button)

· Имеет состояния: наведение курсора, нажатие, недоступна.

· При нажатии клавиши мыши на кнопке, если последующее отпускание клавиши мыши было в другой области, элемент не активируется (кнопка не нажимается).

• Выпадающий список (Drop-down list)

· Текстовые значения в списке располагаются в алфавитном порядке, числовые – по возрастанию.

· Самые популярные значения списка должны находиться сверху, последующие значения следуют по алфавиту.

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

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

· При наборе букв на клавиатуре подбираются подходящие значения.

• Подсказка (Tooltip)

· Не должна выходить за рамки экрана.

· Не нуждается в прокрутке.

· Может быть пропущена или обязательна к просмотру.

• Прокрутка (Scroll)

· Не появляется, если содержимое не выходит за рамки экрана.

· Работает при перетаскивании ползунка мышью, прокручиванием колеса мыши, клавишами стрелок «Вверх» и «Вниз» или отклонением стика на геймпаде.

· Крайнее верхнее и крайнее нижнее положения должны быть достижимы.

Отсутствует текст на элементах интерфейса пользователя. WWZ © 2019, Saber Interactive

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

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

4.3.2. Тестирование совместимости

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

Тестирование совместимости – это запуск базовых функций игрового приложения или функций проверяемого компонента на игровых платформах разной конфигурации и фиксирование результата их работы. В целевой игровой платформе есть два компонента: аппаратная часть и операционная система (OС), которые игровым приложением рассматриваются как единое целое. Тем не менее тестирование совместимости может проводиться по трем направлениям.

1. Тестирование совместимости с аппаратной частью (hardware)

2. Тестирование совместимости с OС и сторонним ПО

3. Тестирование совместимости с программно-аппаратным комплексом

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

1. Тестирование приложения на разных разрешениях экрана

2. Тестирование приложения с различными подключаемыми устройствами (наушники, карта памяти, контроллеры и т. д.)

3. Тестирование взаимодействия приложения с датчиками (гироскоп, геопозиция и т. д.)

4. Тестирование приложения на разных конфигурациях (оперативная память + процессор)

5. Тестирование управления приложением посредством свойств экрана (тач, свайп, мультитач)

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

Для игровых консолей проверка совместимости проводится с различными видами контроллеров. Кроме того, могут проводиться проверки совместимости игр с приставками предыдущих и последующих поколений, а также разными версиями устройств внутри одного поколения (например, PlayStation 4 и PlayStation Pro).

Другое направление тестирования – тестирование совместимости с OС и другим ПО. Среди такого ПО можно назвать:

• антивирусы;

• мессенджеры;

• программы для снятия скриншотов;

• программы для удаленного управления компьютером и прочее.

Иногда при появлении уведомлений из некоторых популярных мессенджеров игровое приложение сворачивается в трей[33] или «зависает». Другими примерами дефектов могут быть:

• возникновение отказов (см. ниже) при использовании некоторых видеокарт (например, относящимся к минимальным требованиям или, наоборот, только появившимся на рынке);

• несовместимость контроллеров некоторых производителей;

• несовместимость игры с конкретной OС;

• нарушенный режим воспроизведения звуков в разных устройствах;

• нарушенный режим воспроизведения графического контента из-за несовместимости с драйверами устройств.

Тестирование совместимости важно еще и потому, что во время его проведения могут быть выявлены общие функциональные и контентные проблемы игрового продукта. На определенных системах баги могут проявляться со 100 %-ной вероятностью, а на других – практически с нулевой.

4.3.3. Тестирование производительности

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

Зависание, фриз (Freeze)

Фризом, как правило, называется «замирание» картинки на экране на определенное время или насовсем. Опционально при этом также останавливается звук.

Заедание, статтер (Stutter)

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

Чтобы лучше понять проблему «заедания» в играх, нужно немного углубиться в историю развития геймдева. Раньше разработчики создавали игры, учитывая частоту кадров, с которой работал дисплей. Скорость передвижения объектов измерялась не в пикселях в секунду, а в пикселях «в кадр»: например, скорость персонажа в Sonic The Hedgehog для Sega была 16 пикселей на один кадр.

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

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

Если разработчик не знает (а он не знает), с какой частотой кадров работает игровая платформа, ему потребуется измерить текущую частоту кадров и адаптировать скорость анимации под нее, чтобы на экране игровой объект передвигался плавно с одной видимой скоростью. Например, если один кадр занимает 1/60 секунды (при 60 FPS), или 16,67 миллисекунды, а скорость объекта на экране 10 метров в секунду, то в каждом кадре расстояние, на которое он перемещается, будет равно 1/6 метра. Но если FPS «упадет» в два раза (до 30 кадров в секунду), то объект должен будет перемещаться уже на 1/3 метра в каждом кадре, то есть в два раза быстрее, чтобы пользователь наблюдал одну и ту же скорость объекта.

Скорость рендеринга кадров совпадает с частотой монитора, поэтому объект двигается плавно и с постоянной скоростью

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

Как ты понимаешь, при таких обстоятельствах синхронная работа центрального процессора (ЦП) и процессора графического адаптера (ГП) становится все более сложной. Часто происходят ситуации, когда ЦП отдает команду ГП произвести рендеринг сцены, а последний сохраняет ее в буфере. ЦП сообщает ГП о конце кадра, и эта команда не считается приоритетной, поскольку все еще происходит рендеринг сцены. То есть новый кадр ГП покажет только тогда, когда закончит выполнять предыдущие задачи. Поэтому способ вычисления временной разницы между началами соседних кадров уже не работает так хорошо, как раньше.

Время начала кадра, измеряемое игрой, начинает колебаться. Игра считает, что FPS «упал», и показывает предыдущий кадр, чтобы дать время ГП сгенерировать следующий, хотя в игре поддерживается стабильно высокий показатель FPS. Это и есть «запинание»: анимация, сгенерированная для нестабильного FPS, но отображаемая с фиксированным FPS.

Рендеринг кадра 3 у ГП занимает слишком много времени, поэтому кадр 2 повторяется в третий раз

Частота кадров, фреймрейт (Frame Rate)

Как я уже говорил, FPS – это количество кадров, сменяющих друг друга за одну секунду игрового процесса. От него зависит плавность картинки, эстетичность спецэффектов и в целом реалистичность происходящего на экране. В игры этот параметр пришел из кинематографа, где показатель количества кадров в секунду одинаков на протяжении всего фильма – 24.

На показатель частоты кадров непосредственное влияние оказывают:

• быстродействие оперативной памяти;

• монитор с высоким коэффициентом обновления кадров;

• графический адаптер (видеокарта), мощность которого обеспечивает скорость вычислительных процессов при рендере сцен;

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

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

Для этого и производится замер FPS прямо во время игры. Делается это с помощью специального ПО, о котором я расскажу в отдельной главе.

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

• видимая для пользователя подгрузка высокополигональных моделей или каких-либо других объектов на сцену;

• отсутствие текстур на поверхностях объектов на сцене;

• разрывы экрана;

• невозможность загрузить уровень или его очень долгая загрузка;

• очень долгая установка игры;

• невозможность запустить игру на платформе с минимальными требованиями.

4.3.4. Тестирование стабильности

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

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

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

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

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

Длительная работа приложения

Пользователь может проводить в игре долгое время, а работа игровых серверов вообще подразумевает функционирование в режиме 24/7. Значит, игровое приложение должно правильно и быстро функционировать все это время.

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

Пример. Ежеминутно в оперативную память записывается блок размером 4 Мб. Чтобы заполнить, например, объем 4 Гб, понадобится чуть больше 1000 минут. Нельзя забывать, что ОС и другие фоновые приложения также потребляют память. И давай представим, что этот объем будет равен 1,5 Гб. Игровое приложение тоже потребляет память: те же 1,5 Гб. Получается, что свободным остается 1 Гб, который будет заполнен за 256 минут, то есть чуть больше 4 часов. А это уже реальное время, которое может быть потрачено пользователем на игру.

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

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

Еще одна ситуация, приводящая к утечкам памяти и отказу системы, называется «состояние гонки» (Race Condition), или «конкуренция». Игровые платформы используют многоядерные ЦП, в которых происходят многопоточные вычисления. Последовательность вычислений, происходящих на одном ядре, называется потоком. Разные вычисления занимают разное время. Происходящее в разных потоках обычно неизвестно другим потокам, и для корректной работы приложения существуют функции, которые синхронизируют полученные в разных потоках результаты и тем самым обеспечивают целостность данных.

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

Результаты вычисления потока записываются в память. Любой записанный в памяти блок информации имеет «адрес» – условное обозначение того, где именно записана информация. Из-за неконтролируемого доступа к общей памяти состояние гонки может приводить к различным ошибкам. Ошибка происходит из-за того, что запись потока по адресу, где уже есть записанные данные, происходит быстрее, чем предыдущие данные могут быть прочитаны. Это и есть состояние гонки. При этом попытка повторения ошибки в схожих условиях работы в целях отладки и исправления может оказаться безуспешной. Тем не менее есть шанс появления такой ситуации, как и «снежного кома». Метод тестирования – длительная работа приложения под контролем внешних программ-мониторов, которые отслеживают состояние тестируемого приложения.

Пиковые нагрузки

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

Причины для возникновения пиковых нагрузок могут быть разными: до начала игры клиенту нужно загрузить значительный объем ресурсов с сервера, или вход на игровой сервер значительного количества игроков, связанный с временем суток (вечернее время), праздников (Новый год, Хэллоуин) или событий (каникулы).

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

Поскольку мы ждем от игрового продукта стабильной и производительной работы независимо от нагрузок, один из способов «борьбы» с пиковыми нагрузками – контроль очереди запросов и недопущения значительного перегруза системы. Но как быть, если ожидание недопустимо или должно быть минимальным? Тут остается только улучшать обработку запросов и работу функций на уровне программного кода, а результаты этих оптимизаций получать с помощью тестирования.

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

Отказ, падение, краш (Crash)

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

• Попытки чтения или записи памяти, которая не предназначена для чтения или записи этим приложением.

• Попытка выполнить привилегированные или недействительные команды.

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

• Попытка получить доступ к другим системным ресурсам, к которым у приложения нет разрешения.

Отказ в игре. Snowrunner © 2020, Saber Interactive

Реакция на отказ (краш)

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

Чтобы ответить на эти вопросы, мы должны искусственно вызвать зависание или отказ приложения. Мы не будем использовать многочасовой сценарий, при котором приложение будет работать с перегрузкой. Это состояние системы мы будем форсировать, намеренно увеличивая величину пиковой нагрузки или продолжительность такого пика. Например, если в нормальных условиях приложение должно пережить пик в 200 % от расчетной нагрузки длительностью 1 минуту, то здесь пик будет 800 % и 15 минут.

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

После отказа системы проверяются целостность данных (падение не должно повредить ресурсы), возможность приложения запуститься снова и др.

4.3.5. Нагрузочное тестирование

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

Нагрузочное тестирование может проводиться по-разному:

1. с применением автоматизированного тестирования и дополнительного программного обеспечения;

2. в рамках плейтестов большой группой тестировщиков;

3. в рамках бета-тестирования большой группой пользователей.

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

Ключевыми метриками в игровом тестировании называют:

• время отклика (например, на пользователя, время на загрузку ресурсов);

• потребление ресурсов (например, загрузка процессора, памяти, пропускная способность сети, сетевая задержка, доступное место на диске, интенсивность подсистемы ввода-вывода);

• время обработки пакетных операций (например, время ожидания, время обработки, время полного выполнения операций, время ответа базы данных);

• время на выполнения операций (например, для вставки, чтения, обновления и удаления данных).

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

Методы, используемые при анализе, могут включать:

• сравнение результатов с заявленными требованиями;

• определение тенденций в результатах;

• выявление ошибок;

• сравнение ожидаемого и полученного результатов;

• сравнение результатов с результатами предыдущих испытаний.

Понимание связи между метриками помогает понять, в какой момент производительность системы начинает снижаться. Например, какое количество запросов в секунду было обработано, когда загрузка процессора достигла 90 % и работа системы замедлилась?

Анализ может помочь определить причины снижения производительности или отказа, а проведение повторного тестирования – устранило ли эту причину внесение исправлений.

4.3.6. Тестирование локализации

Локализация – это процесс адаптации продукта (в нашем случае игры) к конкретному региону, имеющему свои культурные и религиозные особенности, а также определенные законы. Локализация требуется для распространения игры на разных региональных рынках, чтобы охватить большую аудиторию.

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

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

1. Перевод текстов: игровые диалоги, субтитры, всплывающие подсказки, описания и сообщения, имена персонажей, название предметов, заставок, пунктов меню.

2. Перерисовка графических файлов: изображения, символика, текстуры.

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

4. Поддержка технических требований.

5. Поддержка правовых требований региона.

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

В Steam указывается, какие локализации поддерживает игра

Тестирование локализации – это очень большая тема, достойная отдельной книги. Я постараюсь осветить лишь основные моменты; ты найдешь больше информации по ссылкам и литературе в конце книги.

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

Перевод текстов

В тестирование локализации входит проверка правильности переведенного контента, различных элементов интерфейса, ошибок и системных сообщений, проверка раздела FAQ/Help и вспомогательной документации.

Цель проводимого тестирования перевода – проверка контента игры (включая интерфейса игры, субтитров, реплик персонажей и т. д.) на наличие ошибок перевода.

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

• Ошибки формата чисел, денежных единиц, календаря, дат

• Ошибки, связанные с адресами, телефонами

• Некорректное использование и конвертация единиц измерения или валют

Другими словами, сообщение в игре «Вы движетесь со скоростью 62 мили в час» может вызвать непонимание у игрока из России, а сообщение «Вы движетесь со скоростью 100 километров в час» приведет в ступор игрока из США. В таких случаях необходимо изменять не только цифру, но и формулу расчета в зависимости от локализации.

• Отображение числовой информации

• Ошибки перевода имен собственных

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

То же касается:

• названий исторических событий;

• праздников;

• реалий;

• пословиц и поговорок;

• топонимов (географических названий);

• просторечной и ненормативной лексики;

• аббревиатур.

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

• торговая марка;

• логотип;

• сокращение;

• наименование товара (например, продукты питания – сэндвич, гамбургер, автомобили – джип, кроссовер, одежда – блейзер, макинтош, техника – смартфон. Иными словами, англицизмы, вошедшие в другие языки).

• Искажение или игнорирование особых символов (например, неправильное отображение диакритических знаков во французском, иврите, арабском)

• Несоответствие перевода ситуации

Ситуация, когда перевод выглядит смешно или чужеродно, обычно возникает из-за того, что переводчикам приходится работать, не понимая контекста, в котором произносится та или иная фраза. Отсюда и возникают легендарное «Потрачено!»[35] как перевод «Wasted» и масса других, которые неизбежно становятся мемами.

• Использование фраз или слов, которые могут восприниматься как оскорбление

Иногда даже не сами слова, а их употребление в неуместном контексте может спровоцировать большой скандал. В файтинге Kakuto Chojin разработчики назвали одного из героев Асад. Он проводит бои на ринге, оформленном в арабском стиле, а в музыкальный трек вставлено пение муллы, в котором явно слышна фраза «Allah Akbar». При попытке выйти на ближневосточный рынок локализаторы решили, что эта фраза привлечет игроков. Эффект оказался прямо противоположным: исламское общество посчитало оскорблением использование священной фразы в такой ситуации. Во всех исламских странах игра была запрещена.

А игра Devotion была запрещена в Китае после того, как проверяющие увидели в ней оскорбительные послания в адрес Председателя Компартии КНР. На одной из карт были размещены иероглифы с именем Си Цзиньпина и с Винни-Пухом, с которым его ассоциируют.

Перерисовка графических файлов: изображения, символика, текстуры

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

Разработчики решили, что проще сделать все дорожные знаки в игре изображениями, локализаторы решили оставить все как есть. Test Drive Unlimited © 2006, Eden Games

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

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

• Неестественно звучащая речь

Проблема возникает, когда реплики персонажей игры озвучивались в разное время, а затем соединялись в диалоге на стадии производства. В итоге полученные реплики звучат неестественно, с разными интонацией и тембром. Проблема усугубляется, когда актеры не знают контекст реплики или произносят фразы с излишней театральностью. Похожая ситуация наблюдалась с русской локализацией The Elder Scrolls V: Skyrim.

• Неподходящие голоса актеров озвучки

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

• Национальные и индивидуальные особенности речи персонажей

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

Поддержка технических требований локализации

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

• Искаженные символы (Mojibake, Garbage characters)

Речь идет о появлении искаженного текста в результате выбора неправильной кодировки символов. Он выглядит как набор символов из другой системы письма, как правило, совершенно нечитаемые. Например, фраза «База захвачена!» с исходной кодировкой Windows-1251 при декодировании в ISO 8859-1 будет выглядеть как «Áàçà çàõâà÷åíà!»

Не поддерживается шрифт или кодировка. Minecraft © 2011, Mojang Studios

• Локализованный текст не помещается в отведенные границы (обрезается, появляется скроллинг)

Нередко перевод слова с английского языка требует большее количество символов из-за того, что слова в английском существенно короче, чем во многих других языках. Например, английское «Reload now» содержит в себе 10 символов, а на русском соответствующий этому «Перезагрузите сейчас» – 20 символов, в два раза больше. И если на кнопке нет достаточно места для 20 символов, то строка не может уместиться целиком.

В строке не хватает места для большого количества символов на другом языке. WWZ © 2017, Saber Interactive

• Смещение/искажение текста и элементов интерфейса

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

• Перекрытие/наложение

Два или несколько элементов после локализации интерфейса перекрывают друг друга.

• Неверный шрифт/размер

В разных регионах используются разные шрифты и размеры по умолчанию. Например, в азиатских странах обычно используют шрифт размера 9 по умолчанию, а в США – шрифт размера 8.

Эта проблема обычно не влияет на функционал, но сильно влияет на опыт пользователя, затрудняя восприятие текста.

• Неправильное направление текста

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

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

Пример перекрытия. Mudrunner © 2017, Saber Interactive

• Неправильные «горячие» клавиши

Проблемы с «горячими» клавишами могут быть следующими:

· потерянная «горячая» клавиша (при локализации забыли назначить «горячую» клавишу, и в локализованной игре отсутствует возможность использовать этот функционал);

· дубликат «горячей» клавиши (используются две «горячих» клавиши для выполнения одного и того же действия);

· «горячая» клавиша не работает.

• Переменные в тексте и их особенности

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

Одна из наиболее распространенных ошибок разработчиков – делить на части предложения, содержащие переменные. Например, используется переменная для генерации боевых сообщений вида «You take X hit points». Если поместить части предложения («You take» и «X hit points») в разных местах кода, не предупредив об их взаимосвязанности, после перевода можно легко получить следующий текст: «Вы берете 2 единицы урона» вместо «Вы получаете 2 единицы урона».

Существует понятие «грамматический строй целевого языка», и это едва ли не главный краеугольный камень локализации. Зачастую при добавлении переменных разработчики не учитывают, что в ряде языков их значение может менять построение фразы. Речь идет не только об окончаниях в русском языке (1 единица, 3 единицы, 10 единиц), но и, скажем, об артиклях в немецком.

Когда переменных несколько, иногда нельзя поменять их местами (хотя обычно это признак не очень хорошо написанного продукта). Но переводчикам эта возможность нужна, поскольку в разных языках различные правила построения предложений: если в оригинале сначала стоит переменная X, а потом Y, то в иностранном порядок может быть иной – Y и затем X. Рассмотрим пример с теми же боевыми сообщениями: «You take 10 hit points, 3 points blocked». Красивый перевод будет иметь вид «Вы заблокировали 3 единицы урона, получив 10 единиц». Но если возможности менять переменные местами нет, то смысл фразы меняется в корне.

• Рассинхронизация звукового ряда оригинала и перевода

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

Обратный случай: в русской локализации The Witcher 3: The Wild Hunt длина фраз в диалогах зачастую сильно отличается от оригинала. Компенсируется такая разница технически: реплики персонажей ускоряются или замедляются.

• Несовпадение звучащей речи и субтитров

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

• Отсутствие/порча файлов перевода в папках назначения

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

Поддержка требований производителей аппаратной части

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

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

Поддержка правовых требований региона

Во время тестирования локализации необходимо учитывать правовые требования, касающиеся возраста игроков, различных стран и регионов. Например, в России совершеннолетие наступает в 18 лет, в США в зависимости от штата этот возраст варьируется от 18 до 21 года, а в Японии молодые люди считаются совершеннолетними с 20 лет. И это важно учитывать.

Таблица возрастных ограничений в зависимости от контента игры

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

1. ACB (Австралия): M

2. РСВР (Россия): 18+

3. PEGI: 12+

4. ESRB: T – для подростков

5. USK (Германия): 6+

В России игре присвоен самый суровый рейтинг. По всей видимости, причина столь жесткого суждения в том, что цензоры увидели в ней нарушение следующего пункта закона о защите детей: «К информации, запрещенной для распространения среди детей, относится информация, отрицающая семейные ценности, пропагандирующая нетрадиционные сексуальные отношения и формирующая неуважение к родителям и/или другим членам семьи»[36].

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

• Изображение крови (неважно какого цвета)

• Трупы убитых должны исчезать мгновенно

• Изображение женоподобных мужчин

• Порнографические сцены

• Название игры совпадает с названием ранее изданной игры

• Изображения вульгарных сцен и элементов, а также того, что существенно расходится с понятиями базовых социалистических ценностей (что бы это ни значило)

• Азартные игры

• Предрассудки и предсказания будущего

• Ограничения на ежедневное использование «коробок добычи» (loot-box, лутбоксы) и др.

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

К другим ограничениям законодательного порядка можно отнести следующие.

• Изображение нацистской символики и пропаганду нацизма

• Изображение символики различных международных организаций (например, Красный Крест)

• Расовая дискриминация

• Неуважение к религии

• Пропаганда наркотиков

• Реклама запрещенных напитков и продуктов (например, энергетиков)

• Порнография

• Информация об изготовлении оружия, взрывчатых веществ

• Информация о различных способах суицида

• Информация, содержащую описание или изображение сексуального насилия

• Лимит времени для нахождения в игре несовершеннолетних

• Лимит суммы денег на покупку внутриигрового контента

• Наличие системы родительского контроля и т. д.

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

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

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

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

Например, красный цвет для жителей Китая – символ выносливости и веры, в Индии он символизирует чистоту. Европа же, наоборот, видит в этом цвете грех и жертвенность. Для жителей Южно-Африканской Республики это цвет скорби. В США и Японии красный цвет символизирует опасность и террористическую угрозу, а у египтян ассоциируется с трауром. Поэтому при тестировании игрового проекта необходимо обращать внимание на цветовые решения: они могут быть важны.

Известно настороженное отношение некоторых народов к цифре 13 как символу неудачи. А в Китае и Южной Корее такая участь постигла цифру 4, произношение которой созвучно со словом «смерть». В Японии люди стараются избегать цифры 9, которая произносится так же как «страдание». Для христиан число 666 традиционно ассоциируется с Антихристом и злом в целом. Одним словом, иррациональный страх перед некоторыми цифрами есть у многих народов, и это необходимо учитывать при локализации игры для конкретного рынка и ее последующего тестирования.

Все народы относятся с уважением к собственной истории. Часто некоторые исторические события, особенно военные конфликты, могут интерпретироваться разными народами по-разному. Известна история с неудачной попыткой Age of Empires выйти на южнокорейский рынок с эпизодом, когда японское вторжение в Корею закончилось захватом страны практически без сопротивления. Несмотря на достоверность этих событий, корейцы считают этот исторический эпизод постыдным, и игра была допущена на рынок только после того, как разработчики переделали эту часть, добавив героическое сопротивление корейцев. В России вызовут возмущение игры, основанные на событиях Второй мировой войны, где Берлин захватывают американцы, которые также «героически» приписывают себе и освобождение концлагеря Освенцим.

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

1. Юмор

2. Религия, включая оккультизм

3. Отношение к инвалидам, сексуальным меньшинствам, животным, детям и т. д.

4. Сексуальные отношения

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

6. Терроризм

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

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

4.4. Прочие виды функционального/нефункционального тестирования

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

• Ошибка подключения

• Обрыв соединения или изменение его скорости

• Рассинхронизация состояния игроков

• Невозможность принять приглашение

• Невидимые игроки

• Ошибка в результатах игры

Ошибка подключения (Failed Connection)

Ниже приведены частые приведены частые причины для ошибки такого типа.

• Нестабильное интернет-подключение у пользователя

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

Пример ошибки загрузки контента при нестабильном интернет-соединении. Часть машины так и не подгрузилась. Dakar © 2022, Bigmoon Entertainment

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

Индикатор разрыва соединения с сетью. Valorant © 2020, Riot Games

• Блокировка игрока на игровом сервере

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

• Запуску мешают другие приложения (например, файрвол или антивирус)

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

• Игра не может корректно определить местоположение игрока (например, из-за использования VPN)

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

• Лаунчер игры был запущен некорректно (например, в режиме совместимости с более ранними версиями OС)

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

Предупреждение о необходимости отключить режим совместимости

• Для игры не установлены нужные обновления

Это довольная понятная ситуация, в которой у игрока попросту устарел клиент игры и требуется просто обновить его.

• Игровой сервер, к которому происходит попытка подключиться, в данный момент перегружен

В очень популярные игры могут одновременно играть миллионы игроков. Это очень большая нагрузка на игровые сервера, и их мощностей может не хватать. Иногда ошибки доступа к игровому серверу связаны с тем, что серверная часть игры не оптимизирована под большое количество одновременных соединений. Существует понятие PCCU (Peak Concurrent Users) – максимальное количество пользователей, одновременно находящихся в приложении. Когда оно достигнуто, игрок может получить ошибку подключения.

• Обрыв соединения (Dropped Connection) или изменение его скорости

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

Окно ошибки загрузки системных ресурсов. Genshin Impact © 2019, miHoYo Limited

• Рассинхронизация состояния игроков (Desync)

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

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

Вся игровая логика реализуется на сервере, а клиент только демонстрирует текущее состояние и отправляет сигналы серверу в виде нажатия клавиш и движения мышью. Казалось бы, все идеально, но представь, что игрок находится за тысячи километров от сервера. Сигнал от клиента к серверу не доставляется со скоростью света. Давай представим, что сигналу требуется 50 мс на преодоление этого пути и еще столько же, чтобы вернуться. Итого – 100 мс, или 0,1 сек. Со стороны клиента это выглядит так: игрок нажал стрелку движения вперед и после 0,1 секунды продвинулся вперед. Этот временной промежуток называется лаг. Напомню, что сейчас мы разбирали идеальную ситуацию. А если у нас нестабильное интернет-соединение или низкая скорость Интернета? Что, если связь то и дело прерывается? Лаг становится все больше и делает игру абсолютно неиграбельной.

Дефекты рассинхронизации, как и многие другие дефекты клиент-серверного взаимодействия, обычно возникают из-за следующего:

· нестабильное интернет-соединение, приводящее к потере пакетов;

· плохо реализованный сетевой код;

· значительная удаленность клиента от сервера;

· перегруженность сервера.

• Ошибка подсчета очков (Scoring Error)

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

• Ошибки безопасности и читерство

В некоторых играх недобросовестные игроки используют различные команды (читы) для того, чтобы получить незаслуженное преимущество перед другими игроками. Такие дефекты должны исправляться разработчиками незамедлительно. Сама по себе команда не является багом, ведь она была преднамеренно заложена разработчиками. Но вот возможность применять такие средства рядовыми игроками – несомненно, дефект безопасности.

4.5. Тестирование документов и требований

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

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

Требования к продукту разрабатываются на трех уровнях.

1. Бизнес-требования

2. Пользовательские требования

3. Продуктовые требования

На глобальном уровне создаются требования, относящиеся к группе так называемого видения проекта (Project Vision). Они описывают цели и задачи, ради достижения которых разрабатывается продукт. В этой же документации описываются ограничения, связанные с продуктом, для конкретизации ожиданий пользователей от его использования.

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

• внутренняя документация компании;

• документация по предметной области (профильные литература и статьи, исследования);

• нормативная документация (законы и иные правовые акты, государственные стандарты);

• продукты конкурентов.

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

• Инициаторы проекта

• Продюсерская группа (менеджеры проекта)

• Бизнес-аналитики

В общем случае тестировщики, как и разработчики, обычно не участвуют в сборе и анализе бизнес-требований. Но поскольку пользовательские и продуктовые требования – результат декомпозиции бизнес-требований, тестировщикам всегда полезно понимать, какие цели преследует проект. Мы исследуем предметную область заказчика, при этом существенно сокращая время на коммуникацию с ним: многие вопросы отпадают при изучении бизнес-требований.

Ко второй группе относятся требования, выраженные в формате пользовательских историй (User Stories). Они описывают то, как система реагирует на действия пользователя, обладающего различными правами, и формируются по принципу «Я, как кто, делаю что, зачем?» Пользовательские требования могут быть получены из:

• анализа и декомпозиций бизнес-требований;

• описания бизнес-процессов;

• изучения стандартов и регламентов;

• анализа собственных реализованных проектов, проектов конкурентов.

Данные об этих требованиях могут быть получены от:

• бизнес-аналитиков;

• конечных пользователей;

• косвенных пользователей;

• менеджеров проекта;

• руководителей структурных подразделений заказчика.

Сбор и анализ этих требований входит в круг обязанностей тестировщика, в задачи которого также входит следующее.

• Определение соответствия требований критериям качества

• Анализ требований в целях проектирования тест-кейсов

Продуктовые требования бывают функциональными и нефункциональными. Функциональные требования описывают, ЧТО система должна делать, нефункциональные – КАК должна делать. Например, «Персонаж обладает возможностью прыгать (функциональное требование) не выше 2 метров и не дальше 6 метров (нефункциональные требования)».

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

1. Краткий ГДД (англ. Game Design Overview) – это документ, в котором кратко описаны основные цели игры и ее функционал. Он не перегружен деталями и всегда полезен, поскольку помогает всем заинтересованным лицам лучше представить полную картину.

2. Детальный ГДД (англ. Detailed Design Document) – этот документ во всех деталях описывает все игровые механики и интерфейс. На его основе создаются технические задания для разработчиков.

3. Техническое задание (англ. Terms of Reference) – это документ, описывающий структуру продукта с технической точки зрения и исключающий двусмысленное толкование исполнителями.

4. Сценарий (англ. Script). В этом документе, который может быть и частью ГДД, прописываются в том числе диалоги неигровых персонажей (от англ. non-player character, NPC). Важно проверять диалоги: есть вероятность того, что некоторые реплики могут противоречить правилам игры и требованиям локализации.

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

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

1. Интервью. В нем, как правило, участвуют два человека: представитель заказчика и представитель исполнителя.

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

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

2. Собрание (митинг). В нем участвуют несколько человек, которые могут задавать вопросы и участвовать в дискуссии.

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

Минусы: заинтересованные лица не всегда могут собраться все вместе, и встречи могут часто переноситься.

3. Анкетирование. Проводится письменно.

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

Минусы: если вопросы плохо сформулированы или выбрана неправильная целевая аудитория, то можно получить неправильную информацию.

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

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

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

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

Плюсы: прототип более информативен, чем любое описание.

Минусы: метод отнимает довольно много времени. Кроме того, при прототипировании можно избрать неправильный путь.

6. Моделирование. Похож на предыдущий, но гораздо более «продвинут», чем прототип.

Плюсы: в процессе моделирования можно выявить какие-то особенности объекта, которые нельзя выявить иначе.

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

7. Фокус-группы. Очное взаимодействие с потенциальными пользователями.

Плюсы: информация получается от реальных пользователей.

Минусы: требуется организация специально подобранной группы людей, в том числе юридическая (подписание NDA[37]).

8. Анализ документации. Самый распространенный метод получения информации; фактически это осмысленное чтение.

Плюсы: не требует специальных инструментов и навыков.

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

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

Плюсы: позволяет использовать время для обдумывания и осмысления полученных данных.

Минусы: частая ошибка – «домысливание» и добавление собственной информации к ранее полученной, из-за чего полученные данные могут быть искажены.

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

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

В требованиях не должно быть:

• непонятности;

• частой изменяемости;

• изменений, которые вносятся в последний момент;

• неверных или спорных трактовок.

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

1. Понятность (требования должны быть понятными для всех заинтересованных лиц).

2. Корректность и согласованность (требование должно четко указывать на то, что должно выполнять приложение).

3. Завершенность (требование должно содержать всю информацию, которая нужна разработчикам).

4. Проверяемость (должны быть указаны способы однозначной проверки выполняемости требований).

5. Осуществимость (определяется балансом между ценностью и требуемыми ресурсами).

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

7. Упорядоченность по важности и срочности.

Основные принципы тестирования требований

• Тестирование требований должно проводиться до начала разработки продукта.

• Проводить тестирование требований могут как аналитики, так и тестировщики.

• Дефекты документации ничем не отличаются от любых других дефектов.

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

Критерии, по которым проводится тестирование документации

1. Четкость и полнота

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

В требованиях написано: «В поле ˮUsernameˮ могут использоваться буквы, цифры и некоторые специальные знаки». Разработчик вынужден был уточнять, о каких буквах (латинские, кириллические), каких цифрах (римские, арабские, целые) и каких символах (@#$%) шла речь в техническом задании. После реализации функционала очередь уточнять пришла для тестировщика, потому что он не мог понять, какими критериями руководствоваться при проверке.

Далее проводится углубленное исследование требований.

2. Логика и отсутствие противоречий

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

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

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

3. Актуальность

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

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

4. Возможные сценарии

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

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

5. Пересечения с уже существующими функциональностями

В документации необходимо подробно описать, как существующие механики пересекаются друг с другом. Это важно, потому что при реализации нового функционала в будущем можно легко упустить из виду и «потерять» возможность использовать одну из функционирующих механик.

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

6. Интеграция

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

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

7. Отсутствие ошибок написания и опечаток

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

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

Все сказанное выше относится к любому виду документации: от гейм-дизайнерской документации до технических заданий.

Ниже приведены основные (но не все) подходы к тестированию требований.

1. Рецензирование / партнерская проверка / парное рецензирование (Peer review)

Оно может быть представлено тремя независимыми подходами.

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

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

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

2. Задавание вопросов (Asking questions)

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

3. Использование чек-листов (Check-lists)

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

4. Визуализация (Visualization)

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

5. Моделирование и прототипирование (Modeling and Prototyping)

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

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

1. Участие правильных заинтересованных сторон

2. Разделение идентификации и исправления ошибок

3. Проверка с разных точек зрения

4. Повторная проверка

4.6. Автоматизация тестирования игр

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

Они приводят следующие аргументы.

Затраты на автоматизацию

Затраты на оплату труда разработчиков для создания дополнительного кода в игре, необходимого для поддержки автоматизации (а также написания скриптов и других тестовых инструментов, интерфейсов и прочего), могут в разы превысить расходы на оплату мануального тестирования. Кроме того, код, написанный для автоматизации тестирования, может содержать собственные ошибки и недоработки. Автоматизация тестирования может значительно увеличить как бюджет, так и время разработки игры. Угроза увеличения расходов и дополнительных задержек без гарантированных преимуществ делает задачу одобрения внедрения автоматизированного тестирования трудной для многих руководителей.

Виктор Гляненко, QA-директор Saber Interactive

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

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

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

Повторное использование

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

Ошибка ожиданий

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

Масштаб автоматизации

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

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

Человеческий фактор

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

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

Глава 05. Общее у них только одно – все они разные

Мы плаваем в разных морях, но выходим на тот же берег.

BioShock Infinite

• В чем заключаются особенности тестирования игр на разных платформах?

• Мобильные устройства, игровые консоли. PC, облачные платформы, VR и AR. Зачем тестировщику нужны инструменты?

• Какие инструменты используются при тестировании?

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

Классические игровые консоли

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

Игровая консоль PlayStation 5

Портативные консоли

Процветание мобильных устройств привело к увеличению популярности портативных игровых консолей (таких как Nintendo Switch, Steam Deck и др.) с их способностью переключаться между стационарным и портативным режимами, а также переписало правила мобильного и домашнего гейминга. Платформы прошлого, такие как PlayStation Vita и Nintendo DS, также внесли свой вклад в развитие портативного гейминга.

Портативная консоль Steam Deck

PC-гейминг

Компьютеры остаются подлинными ветеранами игрового мира, предоставляя игрокам не только мощности для запуска самых сложных игр, но и доступ к широкому ассортименту ПО для редактирования, моддинга и создания контента. PC-гейминг расцветает благодаря таким платформам распространения, как Steam, Epic Games Store и GOG, которые предлагают уникальные распродажи, эксклюзивные релизы и огромное сообщество игроков.

Мобильные устройства

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

Облачные игровые платформы

Облачные сервисы проложили путь для стриминга видеоигр, позволяя игрокам наслаждаться высококачественным геймингом без необходимости владения мощным игровым оборудованием. Эти платформы потребовали от игровой индустрии переосмыслить традиционный подход к распределению и владению играми. На момент написания этой книги одной из самых популярных облачных игровых платформ в России является VK Play Cloud.

Виртуальная реальность (ВР, VR)

Технологии виртуальной реальности стали одним из самых захватывающих и инновационных направлений в игровой индустрии. VR-шлемы, такие как Oculus Rift, HTC Vive и PlayStation VR, переносят пользователей в полностью погружаемые 3D-миры и создают иллюзию реального присутствия в виртуальном пространстве. Игры для виртуальной реальности постоянно развиваются, начиная от простых аркад и заканчивая полноценными приключенческими и ролевыми играми. VR-технология также находит применение в сфере образования и профессионального тренинга, что говорит о ее потенциале выйти за рамки чисто развлекательного контента.

5.1. Мобильные устройства

К мобильным устройствам, как правило, относят следующие.

1. Смартфоны

2. Планшеты

3. Умные часы и браслеты

4. Умные очки и VR-шлемы

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

1. Диагональ и разрешение экрана

При огромном разнообразии смартфонов и планшетов разных производителей тестировщику приходится иметь дело с очень большим количеством разрешений экрана и его диагоналями для проверки корректности отображения как самой игры, так и пользовательского интерфейса (UI). При этом нужно помнить еще и про особенности различных аппаратов. Например, в Apple в какой-то момент решили, что очень стильно будет выглядеть «челка» на экране смартфона. И пока производители игр не стали думать, что с этим делать, она перекрывала важные элементы UI или объекты на экране в ряде игр, создавая трудности игрокам.

«Челка» на экране iPhone могла скрыть происходящее на экране

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

1. игра масштабирует все элементы UI и самой игры в соответствии с диагональю и разрешением экрана;

2. все объекты находятся в границах экрана;

3. элементы UI не перекрывают друг друга;

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

2. Устройства ввода и способ взаимодействия с игрой

Чтобы играть в игру на консоли (приставке) или РC, игрок использует специальные устройства ввода: джойстики, геймпады, клавиатуры, мыши и др.

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

3. Поддержка прерываний

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

4. Интернет-соединение и его скорость

Мобильность подразумевает то, что игрок может не всегда находиться онлайн. Он может быть дома, в лесу, в самолете и в открытом море. При этом способ и скорость соединения с Интернетом может постоянно меняться. И игры должны корректно вести себя при переключении между основными состояниями связи: E, 3G, LTE, Wi-Fi, отключение связи (режим полета, потеря сигнала). Нестабильное соединение или низкая скорость подключения может стать причиной неприятных дефектов производительности, например «лаги» на стороне игрока, поскольку при низкой скорости соединения его устройство реже отдает пакеты данных и на игровом сервере отображаются только промежуточные данные о его перемещениях.

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

1. Автономный, то есть не требующий подключения к Интернету. К таким играм можно отнести очень простые игры типа платформеров или «Сапер».

2. Постоянное подключение. К ним можно отнести все многопользовательские игры, в которых соперники соревнуются на одной карте (например, PUBG или Hearthstone). Данные в этом случае с игрового клиента передаются на сервер в непрерывном режиме.

3. Временное подключение. Это игры, требующие подключения к сети для скачивания дополнительного игрового контента или передачи данных с клиента. То есть данные передаются с сервера клиенту или, наоборот, тогда, когда происходит подключение к сети.

Соответственно, проверки поведения игры при подключении к сети должны включать в себя:

1. тесты для разной скорости подключения;

2. тесты при нестабильном соединении (задержки передачи пакетов, потери пакетов, дублирование пакетов, объединение пакетов);

3. тесты при обрывах соединения для разных моментов геймплея.

5. Требования магазинов приложений

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

6. Лимиты на размер игры

Поскольку для большинства пользователей основной источник игрового контента – крупнейшие официальные магазины типа AppStore, Google Play или Huawei AppGallery, то необходимо учитывать и соблюдать их требования по максимальному размеру размещенных в них приложений. Разрешенный размер может меняться, но само требование остается неизменным.

7. Использование GPS, акселерометра (G-сенсор) и гироскопа

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

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

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

Акселерометр (G-сенсор) – это компонент, измеряющий ускорение в трех осях пространства. Он довольно часто используется в играх, например в гоночных симуляторах: для управления автомобилем, его ускорения и замедления.

В играх на основе GPS пользователи взаимодействуют с игрой, находясь в реальной среде. Игроки используют GPS и другие технологии для поиска предметов и наград в физическом мире.

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

8. Внутриигровая реклама

Сейчас большинство мобильных игр условно-бесплатные, чтобы расширить базу потенциальных игроков. Такие игры используют два основных вида монетизации, каждая из которых требует отдельных проверок: внутриигровая реклама (In-App Ads, IAA) и внутриигровые покупки (In-App Purchases, IAP). В первом случае игрок должен просмотреть некий рекламный контент для получения игровых бонусов или дальнейшего прогресса, во втором игрокам, не желающим тратить время на долгое достижение результатов, предлагают оплатить покупку игровых предметов или дальнейшего прогресса. Часто эти два метода сочетаются между собой.

In-App Ads в играх можно классифицировать следующим образом.

Rewarded Video Ads. Чтобы получить игровой бонус, игрок должен посмотреть 5–30-секундный видеоролик другого сервиса или игры.

Пример Rewarded Video Ad

Interstitial Ads. Это вид рекламных видеороликов, которые появляются в случайных местах игры и не дают игроку каких-либо бонусов. Их можно пропустить после первых 3–5 секунд.

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

Пример Offerwall

Playable Ads. Это интерактивная реклама с элементами геймплея, чтобы дать пользователю представление о том, что его ждет.

Пример Playable Ad. © 2016, Playrix

Поскольку в первых трех случаях мы говорим о видеороликах, то задачи тестировщика при осуществлении проверок таковы:

• проверка корректности запуска ролика и его воспроизведения;

• проверка длительности видео;

• проверка возможности пропустить просмотр;

• проверка работоспособности ссылок и анимации в случае использования графических ссылок;

• проверка корректности звукового сопровождения и его синхронизации с видеорядом;

• проверка корректности масштабируемости изображения по диагонали и в зависимости от разрешения экрана и т. д.

В других случаях (например, с Offerwall) при проверке следуют алгоритму тестирования, схожему с тестированием пользовательского интерфейса, из-за наличия интерактивных объектов, ссылок, верстки и похожего функционала. А Playable Ad – это небольшая часть игры («мини-игра в игре»), и методология тестирования этого вида рекламы, по сути, не отличается от тестирования полноценного игрового продукта.

9. Инструментарий тестирования

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

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

Ниже приведены основные проблемы использования эмуляторов и симуляторов в тестировании игр.

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

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

3. Несмотря на имеющийся в эмуляторах функционал, нельзя полноценно имитировать проблемы с аккумулятором устройства. Также нельзя предусмотреть и проверить взаимодействие тестируемой игры с другими популярными приложениями, с которыми игровое ПО взаимодействует постоянно.

Поэтому необходимость проведения тестов хотя бы на нескольких реальных устройствах – неотъемлемый элемент процесса тестирования.

Кроме эмуляторов и симуляторов мобильных устройств в работе тестировщика не обойтись без ПО, которое позволяет:

• делать скриншоты и записывать видео;

• имитировать различные проблемы с интернет-соединением;

• проверить, как игра воспринимается людьми, имеющими особенности органов чувств (например, для людей с цветовой слепотой и ее подвидами).

10. Возможности автоматизации тестирования

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

5.2. Игровые консоли

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

Первый и основной нюанс консольного тестирования – это аппаратное и программное обеспечение. В отличие от РС, где существуют тысячи различных конфигураций, консоли имеют унифицированное железо. Это дает разработчикам возможность точно знать, под какое оборудование они оптимизируют свои игры. Это, с одной стороны, облегчает процесс тестирования, так как отсекает проблемы совместимости, характерные для РС. Однако это добавляет сложности, связанные с оптимизацией и интеграцией с операционной системой игровой консоли. Консоли разных производителей (и разных моделей) имеют разный интерфейс, разные функции или реализацию аналогичных функций. Например, консоли Sony имеют функцию PlayGo, которая позволяет запустить игру, не дожидаясь ее полной загрузки. Разработчику нужно заранее позаботиться о том, чтобы необходимые для запуска игры файлы загружались первыми и могли работать до полной установки игры. Именно из-за отличий в аппаратном и программном обеспечении каждый фрагмент кода должен быть оптимизирован под спецификации и технические требования каждой консоли.

Пример игровых контроллеров для автосимуляторов

Еще одна особенность тестирования консольных игр – довольно специфические для консолей контроллеры, такие как геймпады (gamepad) и контроллеры движения (move motion controller), а также множество других игровых контроллеров, которые могут быть подключены к игровой приставке.

1. Рули, педали и рычаги переключения скоростей

2. Джойстики

3. Макеты оружия (пистолеты, автоматы)

4. Макеты музыкальных инструментов (гитары, ударные установки)

5. Танцевальная платформа (ритм-платформа)

6. Макеты рыболовной удочки и т. д.

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

В отличие от современных РС, у которых практически не осталось дополнительных оптических устройств для установки игр с внешних носителей (таких как DVD или Blu-ray-диски), игровые консоли используют возможности использования дисков или картриджей как одну из основных для установки продуктов (наряду со скачиванием игры из официального магазина игр). В связи с этим часто возникает необходимость дополнительных проверок установки и процесса игры с таких носителей.

На базовом уровне, кроме указанных выше, отличий тестирования консольных игр от тестирования игр для РС нет, но существует один вид тестирования, который радикально меняет подходы к проверкам. Этот вид называется сертификационным тестированием (Compliance testing). Производители игровых консолей (на текущий момент основные производители – Sony, Microsoft и Nintendo) разработали ряд требований[40], которые они предъявляют к играм и без соблюдения которых игра не будет опубликована в официальном магазине платформы. Эти требования изложены в специальных документах, которые получают аккредитованные компании-разработчики и тестировщики. Помимо функциональных и нефункциональных требований в документах изложены и требования юридического характера, связанные, например, с соблюдением прав и ограничений для несовершеннолетних пользователей, использования объектов интеллектуальной собственности и др.

Сертификация всех публикуемых в магазине платформы игр необходима прежде всего для:

• соблюдения законодательства стран, в которой распространяется игровой контент;

• интеграции с оболочкой системы консоли;

• поддержания репутации владельцев платформы;

• гарантии работоспособности игры для покупателей и соблюдения их прав;

• исключения попадания нежелательного и/или вредоносного программного обеспечения или контента на платформу.

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

Выпускаемых игр огромное количество, и владельцы платформы не могут предоставить список требований для каждой конкретной игры: он общий и универсальный. Одинаковые требования для разных игр могут тестироваться разным путем, но одинаковым принципом, и это создает трудности для понимания начинающим тестировщикам. К примеру, есть требование «иметь возможность приобрести творог в магазине» и мы тестируем разные магазины. Ты пойдешь в разные места, творог будет лежать в разных местах, ты будешь общаться с разными кассирами, потратишь разную сумму, но принцип проведения теста будет при этом один. Как раз это и требуется понимать при сертификационном тестировании.

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

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

5.3. Персональный компьютер (ПК, РС)

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

• Огромное количество конфигураций компьютерного «железа»

• Большое количество операционных систем и их версий

• Большое количество установленного на РС программного обеспечения (антивирусы, другие игры, драйверы устройств и т. д.) и присутствие или, наоборот, отсутствие обновлений для этих программ

• Многообразие используемых мониторов с разным разрешением, соотношением сторон и частотой обновления экрана

• Широкий спектр подключаемых игровых контроллеров

• Большое количество платформ распространения и хранения игрового контента

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

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

5.4. Virtual Reality (VR)

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

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

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

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

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

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

Проверка аппаратной части проводится для следующих типов устройств.

VR-шлемы (Headsets)

VR-шлемы – это головное устройство для виртуальной реальности. Они надеваются на голову пользователя и погружают его в виртуальное окружение, предоставляя изображение и иногда звук внутри шлема. Популярные VR-шлемы включают Oculus Rift, HTC Vive, PlayStation VR, Valve Index и т. д.

Контроллеры (Controllers)

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

Датчики движения (Motion Sensors)

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

Базовые станции (Base Stations)

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

Аудиоустройства (Audio Devices)

Звуковые наушники или встроенные акустические системы в VR-шлемах предоставляют звуковой компонент виртуального опыта. Хорошее звуковое оформление усиливает иммерсию и атмосферу в игре.

Специализированные аксессуары

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

При этом основными аспектами тестирования аппаратной части VR-игр остаются следующие.

• Совместимость устройств (проверка совместимости VR-устройств с разными компьютерами или консолями. Это включает в себя проверку того, что VR-шлемы и контроллеры подключаются корректно и определяются системой).

• Тестирование трекинга и датчиков (проверка того, что трекинг движений и позиционирования работает корректно и точно. Это важно для обеспечения плавных и реалистичных движений в виртуальной среде. Кроме того, нужно проверить, что датчики и базовые станции правильно обнаруживаются и устанавливаются на местности).

• Эргономика и комфорт (оценка комфорта ношения VR-шлема и контроллеров в течение продолжительного времени. Тестировщики могут выявить возможные дискомфортные моменты или проблемы с посадкой).

• Тестирование звука и акустики (тестирование звуковой подсистемы VR-устройств (наушники или динамики), а также синхронизации звукового сопровождения с графическими образами).

• Проверка сенсорного взаимодействия (тестирование сенсорного взаимодействия с контроллерами (например, сенсоры прикосновения, жесты и кнопки), а также проверка вибрации контроллеров для обратной связи с пользователем).

• Тестирование проводных и беспроводных соединений (тестирование стабильности беспроводных соединений между VR-устройствами и их связью с компьютером или консолью).

Тестирование аппаратной части VR-игр – важный этап в разработке и выпуске игровых продуктов для виртуальной реальности. Оно охватывает не только сами VR-устройства (шлемы, контроллеры, базовые станции и датчики), но и компьютерные или консольные системы, на которых эти устройства работают.

5.5. Облачные платформы

Облачная игровая платформа (Cloud Gaming Platform) – это сервис, который предоставляет игрокам возможность запускать и играть в видеоигры, хранящиеся и выполняемые на удаленных серверах в облаке (централизованных данных), а затем передавать видео- и аудиопоток на устройства игроков через Интернет. Это значит, что игры запускаются и обрабатываются на серверах, а пользователи видят их видеопоток и управляют игровым процессом на своих устройствах.

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

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

Тестирование сети и соединения

• Оценка стабильности и надежности интернет-соединения для игры

• Проверка задержек (лагов), потерь пакетов и пропускной способности

• Тестирование в условиях разных скоростей интернет-соединения (4G, 5G, бродбенд)

• Совместимость с разными интернет-провайдерами

Тестирование совместимости устройств

• Проверка того, что платформа совместима с разными устройствами: смартфонами, планшетами, смарт-телевизорами и РС

• Проверка того, что приложения и клиенты для разных платформ работают корректно

Тестирование производительности

• Оценка производительности серверов облачной платформы при максимальной нагрузке

• Тестирование на масштабируемость для обеспечения плавной игры во время пиковой активности

• Проверка уровня загрузки процессора, использования памяти и других ресурсов серверов

Тестирование безопасности

• Анализ уязвимостей в системе безопасности платформы

• Проверка на защиту от атак, включая DDoS-атаки и хакерские атаки

• Проверка правильности обработки пользовательских данных и их шифрования

• Тестирование аутентификации и авторизации

Тестирование качества видео и аудио

• Оценка качества видеопотока, включая разрешение, частоту кадров и сжатие

• Проверка качества аудио, включая четкость и глубину звука

• Тестирование на артефакты, задержки в видео и аудио

Тестирование интерфейса и управления

• Проверка удобства и интуитивности интерфейса для разных устройств и уровней опыта игроков

• Тестирование корректности и отзывчивости управления, включая контроллеры, сенсорные экраны и голосовые команды

Тестирование игровой механики

• Оценка баланса игровой механики и игрового процесса

• Проверка, что игровые функции и механики работают корректно и согласно дизайну игры

Тестирование совместимости с браузерами и операционными системами

• Проверка, что облачная платформа работает на разных браузерах (Chrome, Firefox, Safari и др.) и операционных системах (Windows, macOS, Linux)

Тестирование игрового контента

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

Тестирование обновлений и патчей

• Оценка процесса обновления и установки патчей на серверах облачной платформы

• Проверка, что обновления не приводят к сбоям и не нарушают работоспособность игр

Тестирование монетизации и платежных систем

• Проверка правильности работы систем монетизации, включая магазины внутри игры и платежные шлюзы

• Тестирование покупок и микротранзакций

Тестирование локализации и географической доступности

• Проверка, что платформа доступна и работает корректно в разных странах и регионах

• Проверка перевода и локализации игр на разные языки и культурные особенности

5.6. Инструменты тестирования

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

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

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

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

Ниже приведено то, что должен знать специалист по тестированию игрового ПО.

1. Инструменты управления тестированием (Test Management Tools). Они играют важную роль в процессе тестирования, предоставляют централизованный и структурированный подход к управлению всеми аспектами тестирования и помогают координировать усилия тестировщиков и разработчиков.

К основным функциям таких инструментов традиционно относят следующие.

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

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

• Запуск и мониторинг тестов. С помощью этих инструментов можно запускать тесты, отслеживать их выполнение и результаты. Тест-менеджеры могут мониторить прогресс тестирования в реальном времени и управлять ресурсами.

• Управление дефектами. Test Management Tools интегрированы с системами управления дефектами (bugtracking tools), что позволяет тестировщикам легко создавать отчеты о багах, связывать их с соответствующими тестами и отслеживать статус их решения.

• Отчетность и анализ. Эти инструменты предоставляют возможность создавать отчеты о текущем состоянии тестирования, качестве продукта и выполнении плана. Это помогает проектным менеджерам и руководству принимать информированные решения.

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

2. Баг-трекеры (Bugracking Tools) – инструменты для регистрации и отслеживания дефектов. Они необходимы для улучшения качества ПО, ускорения процесса обнаружения и устранения ошибок, а также для обеспечения более эффективной работы команды разработки.

Ниже приведены основные функции таких инструментов.

• Регистрация ошибок. Основная цель инструмента – регистрировать все обнаруженные ошибки и проблемы в одном месте. Это позволяет избежать потери информации о проблемах и делает их видимыми для всей команды разработки.

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

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

• Документация и описание ошибок. Инструменты предоставляют место для описания каждой ошибки, включая информацию о том, как ее воспроизвести, какие условия привели к ошибке, а также прикрепление скриншотов или видеозаписей. Это упрощает понимание проблемы.

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

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

3. Инструменты для автоматизации функционального тестирования. К ним можно отнести довольно обширный круг ПО. Они используются для автоматизации процесса тестирования на разных платформах и могут быть как отдельными приложениями (например, для тестирования мобильных приложений), так и интегрированными утилитами (например, инструментарий игровых движков).

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

• Текстовые и табличные редакторы. Нужны для написания различных документов, необходимых для проведения тестирования.

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

• Эмуляторы и симуляторы. Применяются для тестирования приложений в случае, когда недоступны реальные устройства.

5. Инструменты для проведения и поддержки нефункционального тестирования. К ним можно отнести следующие.

• Средства анализа производительности. Помогают анализировать производительность приложения, измерять загрузку ресурсов (CPU, память, дисковое пространство) и выявлять проблемы производительности.

• Инструменты для управления конфигурациями. Помогают устанавливать и настраивать тестовые окружения, что может сэкономить время при подготовке к выполнению тестов.

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

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

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

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

Глава 06. Целью всего является развитие

Природой в нас заложено стремиться к большему.

Deus Ex: Human Revolution

• Как начать карьеру в области тестирования?

• В какой компании лучше работать?

• Как определить, какие навыки нужны работодателю?

• Что делать, если нет опыта?

• Что написать в резюме?

• Как себя правильно оценить?

• Какие вопросы могут задать во время собеседования?

• Как проходить собеседование при приеме на работу?

• Что делать, если отказали в приеме?

• Как и куда развиваться в тестировании?

Предлагаю начать с обзора компаний, которые прямо сейчас ищут тестировщиков и готовы пригласить тебя на собеседование. Объявления, как правило, можно найти в следующих источниках.

1. HH.ru – пожалуй, основной на сегодняшний день ресурс о работе во всех сферах, включая геймдев. Здесь можно найти огромное количество вакансий, включая объявления о найме сотрудников с небольшим опытом или вовсе без опыта работы. Дополнительный список похожих ресурсов ты найдешь в конце этой книги.

2. VK – объявления о вакансиях в разных регионах появляются не только в специализированных группах, но и в виде таргетированной рекламы, которая сама тебя находит.

3. Разные игровые выставки, где выставляются огромные доски с объявлениями о вакансиях в сфере геймдева.

4. LinkedIn – профессиональная соцсеть, содержащая огромное количество профилей компаний и сотрудников в разных сферах.

5. Компании, предлагающие трудоустройство после прохождения обучения. Таких тоже немало. Однако прежде чем отдавать деньги за обучение, я рекомендую тебе внимательно прочитать отзывы реальных выпускников таких курсов и изучить список компаний-партнеров, которые предлагают последующее трудоустройство.

6. Профессиональные группы и каналы в Telegram, где собирается много людей для обмена опытом по конкретным профессиональным темам. Часто там же появляется информация о вакансиях в разных компаниях.

7. Другие источники. Это могут быть офлайн-мероприятия и мастер-классы, а также сайты крупных компаний, где публикуется информация об открытых вакансиях.

Все компании можно условно разделить на три группы.

1. Продуктовые – разрабатывают собственные игровые продукты и нанимают специалистов для реализации собственных идей.

2. Аутсорсинговые – предоставляют услуги, например, тестирования для разработчиков игр «под ключ».

3. Аутстаффинговые – предоставляют сотрудников разных специализаций и уровня профессионального развития компаниям-разработчикам для проведения конкретных видов тестирования.

Попробуем разобраться, в чем заключаются особенности работы в компаниях разных типов. Конечно, в разных компаниях все устроено по-разному, поэтому я говорю лишь о типичных составляющих работы.

В таблице выше речь не идет о плюсах и минусах работы. Это лишь особенности, которые в разных обстоятельствах у людей разного склада характера, темперамента и настроя могут рассматриваться одновременно как плюс или минус работы. Поэтому каждый сам выбирает, в какой компании лучше начинать свою карьеру. Чтобы определиться с выбором максимально точно, не стесняйся задавать вопросы на собеседовании. Вопросы могут быть следующие.

1. Какая методология разработки используется на проектах?

2. Как, кем и в каком виде создается документация по проекту?

3. Какие роли есть у сотрудников проекта?

4. Какие виды и типы тестирования применяются на проекте?

5. Какие инструменты используются для управления тестированием?

6. Какой используется баг-трекер?

7. Есть ли программы обучения и развития в компании?

8. Как можно перейти с одного проекта на другой?

9. Как получить повышение в компании?

Ты скажешь: «Это все очень хорошо, но что делать, если у меня нет никакого опыта в тестировании? Работодатели хотят нанимать опытных сотрудников». Уверяю тебя, хороший работодатель понимает, что вложение в собственных сотрудников – это гарантия конкурентоспособности компании в среднесрочной перспективе. Грамотный HR[41] всегда старается разглядеть потенциал в соискателе, даже если у него нет опыта работы. А некоторые (многие!) компании специально набирают новичков, чтобы подготовить из них тех специалистов, которые им нужны.

Ожидания IT-компаний от соискателя-новичка

Диаграмма выше показывает, что более существенно для работодателя при найме соискателя-новичка в профессии.

Обрати внимание на английский язык: знание его очень важно в сфере IT. Без английского ты, к сожалению, не сможешь не только читать профильную литературу, но и выполнять свои профессиональные обязанности. Например, документы, которые используются для проведения сертификационного тестирования (Compliance testing) игр для консолей, написаны только на английском языке.

Все курсы, профориентации, бесплатные обучающие программы работодателей требуются только для одного – найти недооцененный талант и отсеять остальных. Сформировавшегося специалиста сложно переобучить из-за внутреннего сопротивления, а новичку легко привить новые знания и навыки, если у него сильная мотивация к освоению этих знаний и навыков.

Виктор Гляненко, QA-директор Saber Interactive

Хочется рассказать, что мы в Saber Interactive считаем важным для человека без опыта работы, желающего стать QA-специалистом в геймдеве.

Для компании, в которой работает много команд из разных уголков мира, конечно же, очень важен английский язык хотя бы на уровне чтения и понимания технической документации (большая часть доступна только на английском языке) и возможности общаться с коллегами в рабочих чатах. У нас были случаи, когда проект не проходил сертификационную проверку от Microsoft или Sony из-за того, что неверно были поняты технические требования. Или когда из-за слабого английского языка у тестовой команды уходит много времени на оформление отчетов о найденных ошибках и их постоянно приходится проверять и исправлять неточности. Чем точнее оформлен найденный баг, тем быстрее его исправят.

Другое качество новичка, привлекательное для наших рекрутеров, – общая компьютерная грамотность. Новичку сложно или почти невозможно работать, если он не знает или не понимает, как работать с документами на своем компьютере. У человека в целом должно быть представление о том, что такое компьютер и игровая приставка.

Я бы обязательно выделил самое важное, на мой взгляд, требование, – любовь к играм и умение в них играть. Потому что при тестировании могут быть пропущены проблемы, которые заметит только человек с большим игровым опытом. В нашей практике были случаи, когда мы брали очень перспективного с точки зрения мотивации и сопутствующих навыков человека, но без игрового опыта. В итоге такой человек не мог выполнить простые проверки в игре, так как не умел играть и не мог пройти уровень, который нужно было проверить без использования отладочных «читов», дающих неуязвимость персонажу. Согласитесь, достаточно забавно услышать в ответ на вопрос, почему не выполнены рабочие задачи, жалобу на то, что игрового персонажа постоянно убивают.

Любовь к играм позволяет предлагать варианты улучшения игрового процесса или отстаивать свою точку зрения в спорной ситуации по работе игровой логики. Немного дополню про опыт работы в другой сфере. Нередко можно заметить, что кандидаты скрывают опыт работы, к примеру, официантом или на стройке, так как считают это неважным для резюме. Но опыт работы с людьми и общения с ними, решения конфликтных или сложных ситуаций может пригодиться и быть очень важен, так как при работе тестировщиком нужно много взаимодействовать с коллегами.

6.1. Начало карьеры

Есть своеобразная Уловка-22: бывший студент не может найти работу, потому что работодатель хочет сотрудника с опытом, а приобрести опыт без работы невозможно. Если ты не приложишь усилий для того, чтобы не попасть в эту ловушку, трудоустроиться будет очень сложно.

Но подумай: точно ли ты не можешь получить никакого опыта до того, как придешь на собеседование? Конечно можешь! Во-первых, многие компании предоставляют возможность пройти производственную практику. Во-вторых, ты можешь предложить свои услуги (бесплатные) по тестированию игрового проекта, например, инди-разработчикам[42] и таким образом сформировать портфолио для собеседования. Такие проекты представлены на любой игровой выставке или конференции по разработке игр.

Другой источник первоначального опыта – краудтестинговые платформы и биржи фрилансеров. Зарегистрировавшись там, ты можешь предлагать свои услуги по тестированию и продолжать формировать портфолио.

Наконец, еще один источник опыта – открытые и закрытые бета-тестирования игровых продуктов (ОБТ и ЗБТ). Будем откровенны: для 95 %, если не больше, игроков ОБТ – это просто способ познакомиться с игровым продуктом раньше других. Но ты должен войти в оставшиеся проценты, потому что тестировать продукт ты будешь по-настоящему, с оформлением баг-репортов и предоставлением обратной связи разработчикам. Потому что твоя задача – приобрести опыт и подтвердить это своими знаниями и навыками на собеседовании для получения работы своей мечты. Так что записывайся на ближайший бета-тест, и вперед на поиск багов!

При подготовке портфолио для собеседования нужно сделать так, чтобы твои навыки и знания были очевидны, как и области, в которых ты их применил. Нужно составить его так, чтобы читающий получил информацию в наиболее понятном и подробном виде. Обязательно нужно включить следующее.

• Информация о проектах, в которых ты принимал участие как тестировщик, с подробным описанием обязанностей на проекте (составление тест-плана, проектирование тест-кейсов, выполнение тестирования и т. д.)

• Время работы на проекте

• Информация о том, была ли это командная или индивидуальная работа

• Виды и типы тестирования, которые ты выполнял (функциональное, нефункциональное)

• Функционал, который тестировался

• Инструментарий, который ты использовал, включая инструменты управления тестированием и т. д.

• Модель, которая использовалась в разработке и тестировании игрового продукта

• Немного статистики: сколько тест-кейсов было спроектировано, сколько багов найдено, в каких областях продукта, сколько из них были высокой критичности

Естественно, ты не должен включать в портфолио информацию, если подписывал NDA или разработчик прямо не разрешил использовать информацию для портфолио. О том, можно ли будет использовать информацию с проекта в портфолио, разработчика нужно спросить заранее.

6.1.1. Как себя правильно оценить

Рано или поздно этот вопрос задают себе все соискатели. Стоимость любого производимого человеком товара состоит из себестоимости (всех затрат на производство, включая оплату труда сотрудника, который производит этот товар с помощью инструмента и материалов) и прибыли, которую получает компания и которая зависит от спроса на этот товар на рынке. Себестоимость интеллектуального труда посчитать очень непросто, а иногда и невозможно. Цена интеллектуального труда определяется исключительно рынком и тем, насколько человек, продающий свой интеллект, осведомлен о ситуации на рынке труда.

В каждом конкретном случае специалист либо соглашается на предложение работодателя, либо работодатель соглашается на ту цену, которую называет соискатель (особенно в случаях, когда спрос на услуги таких специалистов существенно превышает предложение). В случае с трудоустройством новичков без опыта работы ситуация, как правило, разворачивается по первому сценарию, поскольку предложение на рынке труда превышает спрос. Кроме того, работодатели соизмеряют собственные затраты на подготовку новичков с потенциальными доходами, которые они могут извлечь после того, как профессионал сформировался. При этом они учитывают многие факторы: текучку, тренды развития отрасли, тенденции, связанные со спросом на услуги компании, и т. д.

Посмотрим на условия, которые влияют на «стоимость» специалиста.

1. Уникальные навыки в профессиональной сфере

2. Экспертные знания в профессиональной и смежных отраслях

3. Отличное владение актуальными инструментами

4. Значительный опыт участия в успешных проектах

5. Развитые личные качества (софтскиллс – коммуникативные навыки, способность к обучению и адаптации, умение работать в команде и т. д.)

6. Незначительное количество специалистов этой профессии на рынке труда

7. Повышенный спрос на специалистов данной профессии

Совокупность этих условий гарантирует специалисту предложения высокой заработной платы практически в любом регионе. Как правило, начинающий специалист не может гарантировать наличия не то что совокупности, но и любого отдельно взятого условия.

Многие консультанты по поиску работы рекомендуют новичкам без опыта соглашаться почти на любое предложение работодателя, поскольку первая работа в желаемой сфере – шанс на дальнейшее развитие. Они во многом правы: оценить себя, свои навыки и профессиональный уровень можно только в сравнении, а оно может быть только в условиях настоящей работы.

С другой стороны, есть вполне рабочие инструменты и способы, которые помогут тебе довольно точно узнать свою стоимость на рынке труда.

Первый из них – «Сколькополучатель» от hh.ru. С его помощью ты сможешь узнать о действующих на рынке воронках дохода. Все, что нужно сделать, – выбрать регион, интересующую тебя профессиональную область, роль, стаж и должность и нажать кнопку «Узнать уровень дохода». Ты тут же получишь данные об уровне зарплат при наличии открытых вакансий на hh.ru.

Чтобы вычислить свою индивидуальную вилку дохода, можно провести собственное исследование отраслевого рынка. Для этого ты можешь придерживаться следующего алгоритма.

1. Нужно зайти на hh.ru, в верхнем левом углу выбрать вкладку «Соискатели» и нажать на значок фильтров в строке поиска.

2. В открывшемся окне установи нужные фильтры. Если нужно, используй язык поисковых запросов для конкретизации поиска. Например, заключив поисковый запрос в кавычки – «Тестировщик игр», – ты получишь результаты, включающие только это сочетание. Ты также можешь исключить из поиска ненужные слова, выбрать конкретный регион и просматривать только вакансии, где указано финансовое предложение работодателя.

После проведения анализа определи для себя три уровня дохода – минимальный, комфортный и желаемый, тем самым сформировав вилку зарплатных ожиданий. Так ты сможешь избежать категоричности в ответе на вопрос о финансовых ожиданиях и будешь чувствовать себя комфортно в разговоре о стоимости своего труда.

6.1.2. Что написать в резюме

Когда будешь составлять резюме, постарайся задуматься вот о чем. В компанию обращается довольно много соискателей, которых никто из сотрудников этой компании никогда не видел (за редким исключением). Поэтому решение о приглашении на собеседование они будут принимать исходя из того, насколько твое резюме отвечает требованиям вакансии. Вот несколько советов, которые помогут тебе составить хорошее резюме, исходя из личного опыта найма сотрудников автором этой книги.

1. Резюме не должно содержать грамматических, пунктуационных и других ошибок. Резюме – это характеристика человека. Сразу заявляя о собственной безграмотности, не стоит рассчитывать на то, что к тебе проявят интерес люди, работа и профессия которых – обнаружение ошибок.

2. Пиши проще, старайся избегать длинных предложений с деепричастными оборотами и большим количеством специальных терминов. Поверь, если рекрутеру захочется восхититься изящным слогом, он откроет томик стихов Пастернака или Бродского.

3. Используй больше конкретики, особенно когда это касается твоего профессионального опыта. Фраза «занимался тестированием игр» гораздо хуже, чем «участвовал в тестировании производительности и совместимости игр для ПК».

4. Самое важное напиши в самом начале. Рекрутер должен вдумчиво прочитать много резюме в день. И часто, не найдя нужной информации на первой странице, он теряет внимательность и интерес к соискателю. Поэтому о своих самых значительных достижениях, навыках и знаниях стоит написать в самом начале.

5. Специалист по найму персонала будет тебе очень признателен, если ты структурируешь свое резюме. Читать сплошной текст и выискивать в нем ответы на вопросы – то еще занятие! Попробуй использовать стандартную структуру.

• Шапка: здесь нужно разместить свою фамилию и имя, способ связи, возраст и город проживания.

• Технические навыки: напиши об инструментарии тестирования, которым ты владеешь на хорошем уровне.

• Опыт работы: предоставь информацию о проектах, в которых ты принимал участие, достижения в них на предыдущих местах работы (если они были). Если твой опыт работы не связан с тестированием, попробуй использовать его в свою пользу. Например, если ты работал в образовании, то укажи, что можешь отлично ладить с людьми и обладаешь развитыми коммуникативными навыками.

• Образование: Перечисли оконченные и неоконченные учебные заведения (особенно профильные), курсы по тестированию и в смежных областях, которые ты проходил. Но не нужно писать о средних баллах и цвете диплома, работодателя это вряд ли заинтересует.

• Дополнительная информация: перечисли другие свои навыки, которые могут быть полезны работодателю. Вряд ли работодатель придет в восторг от того, что у тебя есть права категории А и B. Но вот владение английским языком на уровне «Upper-Intermediate» и сертификат ISTQB® GaMe Testing точно выделит тебя из массы других соискателей.

6. Не стоит преувеличивать собственные достоинства и писать о навыках, которыми ты не владеешь. Рекрутер – это специалист, которого обучали видеть фальшь и ложь. Настойчивая неправда в резюме и на собеседовании станет основанием для «черной метки», которую тебе выпишет специалист по найму.

7. Расшифровывай аббревиатуры. Это прежде всего касается названий учебных заведений. Если МГУ, МФТИ, ISTQB рекрутеры способны расшифровать сами, то менее известные комбинации букв точно поставят их в тупик.

8. Напиши о своих любимых играх. Для игрового тестировщика одно из ценных качеств – игровой опыт: именно он будет твоим надежным помощником для определения, как должен функционировать игровой продукт, если у тебя не будет в руках документации по нему.

9. В идеале можно написать сопроводительное письмо к своему CV, в котором подробно изложить, почему ты направляешь резюме именно в эту компанию. Это точно поможет лучше продемонстрировать твою заинтересованность в вакансии.

Пример резюме ты найдешь в конце этой книги. Можешь использовать его как образец для написания своего.

Подготовленное портфолио вместе с резюме можно направлять в компании, которые тебя заинтересовали. Обязательно заведи табличку, в которой отмечай, когда и куда ты направил свои запросы. И вот несколько советов относительно того, что делать точно НЕ нужно.

1. Не нужно звонить на следующий день после того, как отправил документы с вопросом, почему тебе до сих пор не перезвонили. Компании получают десятки, если не сотни предложений от соискателей, и чтобы их обработать, нужно время.

2. Не нужно говорить позвонившему тебе рекрутеру, что ты никак не можешь встретиться с ним в назначенное время, потому что будешь проходить собеседование в другом месте; когда освободишься, то будешь готов немедленно встретиться. Поверь: больше ты этого человека не услышишь.

3. Не нужно возмущаться и писать негативные отзывы о компании, получив отказ из-за того, что ты невнимательно читал текст вакансии. Например, работа предлагается в офисе с переездом в другой город, а ты не готов к этому и хотел бы работать удаленно.

Помни, что прием соискателя на работу – право, а не обязанность работодателя. Тебя могут не принять по следующим причинам.

1. Найден более подходящий кандидат на должность.

2. Не было представлено резюме соискателя, позволяющее оценить его профессиональные качества.

3. Вакансия закрылась.

4. Должность была предложена сотруднику компании.

Если произошло именно так, не отчаивайся. Наступит день, когда раздастся звонок и тебя пригласят на собеседование.

6.1.3. Алгоритм поиска первой работы

Его можно изобразить в виде схемы.

Примерный процесс приобретения первой работы

Важно определиться, какой тип компании ты хочешь выбрать для карьерного старта. Для этого нужно потратить время на анализ рынка и составить список потенциальных работодателей. При этом, как ты понимаешь, может встать вопрос о том, готов ли ты отправиться в другой регион, потому что в твоем городе компаний, занимающихся игровым тестированием, нет. Впрочем, сейчас многие компании готовы предложить удаленное сотрудничество, но это касается скорее опытных тестировщиков.

Особое внимание стоит обратить на то, какие навыки требуются в выбранных компаниях. Крупные компании достаточно подробно описывают круг обязанностей нанимаемых сотрудников, и ты сможешь определить, чему уделить больше внимания. Однако используй логику и здравый смысл при оценке объявлений. Сейчас, например, очень модно говорить об автоматизированном тестировании, в сети огромное количество курсов по изучению автоматизации, создатели которых обещают по окончании обучения высокие зарплаты даже новичкам. На деле все может оказаться не так радужно. Во-первых, без основ тестирования, к которым относится и мануальное тестирование, автоматизация бесполезна. Во-вторых, после подсчета затрат на обеспечение того, чтобы игра могла быть протестирована с помощью автоматизированных тестов, и на разработку самих тестов, обычно принимается решение использовать мануальное тестирование. Ну и, в-третьих, значение и надежность применения автотестов в игровой индустрии частенько преувеличивают.

За время работы в сфере тестирования автор этой книги неоднократно принимал участие в плейтестах, целью которых, кроме всего прочего, было проверить, как серверная часть справляется с нагрузкой при большом количестве пользователей. Разработчики игр из одной небезызвестной компании утверждали, что провели автоматизированное нагрузочное тестирование с десятком тысяч ботов с отличными результатами. Команда была разбита на пятерки, которые должны были последовательно подключаться к игре и совершать любые действия (это же плейтест ☺). Так вот сервер «упал» в тот момент, когда в игру зашло… 79 человек.

Следующий этап – ревизия собственных навыков и их непредвзятый анализ. Ты должен сопоставить свои знания и навыки с тем, что требуют компании от своих сотрудников. Здесь тебе понадобится самокритичность и честность. Часто от начинающих специалистов можно услышать заверения в том, что они обладают достаточным уровнем предметных знаний. Но на деле оказывается, что многие не вполне владеют даже терминологией, а многие процессы и подходы представляют себе совсем иначе, чем нужно.

Проведя такую ревизию и анализ, нужно получить недостающие знания и углубить уже имеющиеся. В сети множество неплохих курсов и материалов по тестированию, которые я мог бы рекомендовать тебе в качестве дополнительных. Их список ты найдешь в конце этой книги. Кроме того, разные компании предлагают внутренние курсы для своих сотрудников. Кроме расширения профессионального кругозора, они позволяют еще лучше адаптироваться к рабочему процессу.

Ниже приведен список базовых навыков и знаний, обязательных для любого начинающего тестировщика в области игрового тестирования.

пайплайн[43]

Как во всех предыдущих случаях, я предлагаю подробно рассмотреть процесс рекрутинга и то, чем занимаются HR, чтобы лучше подготовиться к каждому этапу трудоустройства.

Конечно, в разных компаниях процесс приема новых сотрудников может выглядеть по-разному, но все же есть общие действия и стадии процесса.

Часто можно встретить утверждение, что отбор кандидатов начинается с первичного собеседования (так называемого скриннингового интервью), но это совершенно не соответствует действительности. До того как специалист по подбору кадров пригласит тебя на первое интервью, он проделывает огромный объем работы по отсеиванию тех соискателей, которые не подходят для трудоустройства по формальным критериям на основании присланных ими резюме. Это и есть первый этап: на нем отсеивают часть обратившихся. Формальные критерии изложены в требованиях к открытой вакансии. Они могут быть следующими.

1. Образование

2. Опыт работы

3. Определенный уровень профессиональных знаний и навыков

4. Дополнительные знания, требующиеся для выполнения конкретной работы (например, знание английского языка для тестировщика, занимающегося сертификационным тестированием приложений для игровых консолей)

По законодательству многих стран, в том числе России, запрещено указывать и основывать свой выбор соискателя на требованиях дискриминационного характера, таких как:

• пол (если только по закону нельзя принимать женщин или если это не обязательный параметр – например, у моделей);

• раса (если это не обязательный параметр – например, у моделей);

• физических параметров (если это не обязательный параметр – например, у моделей);

• регистрация и прописка;

• национальность;

• происхождение;

• имущественное, семейное, социальное и должностное положение (кроме запретов занимать определенные должности с непосредственным подчинением близким родственникам при трудоустройстве на государственную гражданскую службу);

• возраст (если только по закону нельзя принимать несовершеннолетних);

• отношение к религии;

• убеждения;

• судимость (кроме случаев, когда соискатель имеет судимость за определенные преступления при трудоустройстве в сфере образования и воспитания);

• принадлежность к общественным объединениям и социальным группам;

• другие обстоятельства, которые не связаны с деловыми качествами работников. Например, соискатель обратился повторно. Отказ ему на основании того, что такой отказ был дан соискателю ранее, неправомерен, поскольку он мог пройти обучение и улучшить свои профессиональные качества.

Представитель работодателя вряд ли догадывается о твоих достоинствах, как и о твоем существовании вообще. Поэтому наша с тобой первая задача – подготовить хорошее резюме и портфолио, чтобы предоставить информацию о себе и пройти первый этап отбора.

Хорошим оно считается тогда, когда говорит нанимателю, чем ты можешь быть полезен и почему нужно нанять именно тебя. С точки зрения оформления это должны быть привлекающие внимание смысловые блоки с выжимкой информации о тебе как о специалисте – лаконично, по делу, без вранья.

6.1.4. Как пройти собеседование

Это будет твоя первая встреча с представителем компании. Ее цели следующие.

1. Понять, насколько твой опыт, знания и навыки подходят к требованиям вакансии. Рекрутер будет задавать тебе разные вопросы. Цель некоторых тебе может быть непонятной, потому что люди, составляя резюме, в попытках сделать его максимально привлекательным частенько приукрашивают действительность. Задача HR-специалиста на этом этапе – понять, насколько ты «приукрасил действительность» или, наоборот, упустил важные детали, которые резко повышают твою профессиональную ценность.

2. Оценить твои личностные качества и навыки коммуникации (софтскиллс). Говорят, что язык – это отражение сознания человека. Если соискатель постоянно путается, спешит, недоговаривает или, наоборот, говорит много и не по делу, рекрутер может сделать неутешительные выводы о неразвитых коммуникативных навыках. А это может очень негативно повлиять на работу в проектной команде.

3. Узнать, насколько ты действительно открыт для предложения компании и насколько мотивирован работать в игровой индустрии.

4. Понять твои ожидания от работы в компании, в том числе связанные с условиями труда и зарплатой.

Ниже приведен список вопросов, которые ты можешь услышать на предварительном собеседовании.

Общие

1. Расскажите немного о себе. Почему решили сменить сферу деятельности (если это не первая работа)?

2. Какое у вас образование?

3. Проходили ли вы какое-то обучение, связанное с тестированием?

4. Почему выбрали именно нашу компанию?

5. Чем для вас интересна профессия тестировщика?

6. Что для вас приоритетно в работе? Зарплата? Коллектив? Уютный офис? Удобное расположение? Другое?

7. Какие, по вашему мнению, есть возможности профессионального роста для тестировщика?

8. Есть ли у вас опыт работы, связанный с игровой индустрией?

9. Какие у вас зарплатные ожидания?

Все эти вопросы необходимы для того, чтобы выяснить, насколько ты ориентируешься в базовых профессиональных процессах, владеешь профессиональной терминологией и способен к анализу и логическому мышлению. Собеседуя тебя на должность стажера или младшего тестировщика (QA Junior), никто из участвующих в этом сотрудников не ожидает, что ты продемонстрируешь глубокие профессиональные знания процесса тестирования и высокий уровень владения инструментами. Все они хотят убедиться только в одном: твоя мотивация и интерес в получении работы и развитии в профессии так высоки, что ты готов потратить немало времени и приложить серьезные усилия для освоения новых профессиональных навыков.

Как уже было сказано выше, одна из главных задач рекрутера – определение приоритетов сотрудника в работе, то есть того, что для него важно. Другими словами, определение мотивации сотрудника.

Ниже представлена схема, которая иллюстрирует базовые приоритеты соискателей. Будем честны, в основе мотивации сотрудников всегда лежит материальная компенсация труда. Автор этой книги не считает денежную мотивацию чем-то позорным. Любой человек хочет, чтобы его труд был достойно оплачен. Однако среди работодателей есть и те, кто считают честный разговор о денежных мотивах сотрудника чем-то неприемлемым. Они искренне полагают, что участие в тестировании известного игрового тайтла само по себе должно приносить глубокое удовлетворение. Хотя их самих вряд ли вдохновит работа над суперизвестным проектом в офисе, где постоянно забивается туалет, а принципы продвижения по карьерной лестнице непрозрачны и непонятны большинству сотрудников.

В подобной ситуации стоит честно сказать, что карьерный рост и активная работа над интересными проектами – сильные мотиваторы, однако базовые потребности человека должны быть закрыты.

Пирамида мотивации сотрудников

Если все прошло хорошо, специалист по набору персонала пригласит тебя на вторую часть беседы, которая пройдет уже в присутствии представителей отдела тестирования. Она иногда называется техническим интервью. Во время него тебе зададут много специфических вопросов.

По игровому тестированию

1. Зачем нужны тестировщики при разработке игр? Какие у них обязанности?

2. Как выглядит процесс тестирования? Из каких этапов он может состоять?

3. Гарантирует ли тестирование профессиональной командой отсутствие дефектов в игре?

4. Какие жанры игр вы знаете? Какие из них ваши любимые и почему?

5. На что влияет жанр игры в процессе тестирования?

6. Если бы вам пришлось тестировать игру вашего любимого жанра, что бы вы стали проверять в первую очередь? Почему?

7. Если нет письменных требований, откуда можно получить информацию о том, как должен функционировать игровой продукт?

8. Какие критерии (критерии входа) должны быть выполнены до начала тестирования?

9. Чем игра отличается от прикладного ПО?

10. Что такое ошибка в игре?

11. Приведите пример бага, который вы встречали во время игры. Что, по-вашему, привело к возникновению этого дефекта?

12. Какие еще бывают баги? Какие из тех, что вы назвали, вы бы определили как самые критичные для игры? Почему?

13. Какие виды тестовой документации вы знаете?

14. Что такое тест-план? Для чего он нужен?

15. Что такое чек-лист? Для чего он нужен?

16. Что такое тест-кейс? Для чего он нужен?

17. Что такое отчет о дефектах (баг-репорт)? Для чего он нужен?

18. Как вы себе представляете жизненный цикл дефекта с момента его документирования?

19. Почему считается, что тестирование нужно начинать как можно раньше?

20. Можете ли вы привести примеры звуковых дефектов в игре? Дефектов уровня? Дефектов локализации?

По игровой разработке

21. Какие виды игровой документации вы знаете? Для чего она разрабатывается?

22. Знаете ли вы основные этапы разработки игры?

23. Что такое игровой движок? Какие движки вы знаете?

24. Знаете ли вы какие-либо модели разработки ПО? В чем между ними разница?

25. Можете ли кратко рассказать об основных этапах создания 3D-модели персонажа для игры?

26. Можете ли вы привести примеры основных игровых механик?

По игровому «железу»

27. На какой игровой платформе вы обычно играете? Какие платформы вы знаете? В чем между ними различия?

28. От каких компонентов PC больше всего зависит производительность в игре?

29. Какие виды игровых контроллеров вы знаете?

30. Вы обнаружили дефект и отправили его разработчику для устранения. Он утверждает, что четко выполнил все шаги, описанные вами, но дефекта не обнаружил. Почему такое может произойти?

Кроме этих вопросов очень часто компании предлагают пройти ряд психологических тестов, решить несколько логических задач или выполнить тестовое задание (или просто протестировать какой-либо предмет типа ручки). Часто решений у задач, которые дают на собеседовании тестировщику-стажеру, нет. Собеседующие наблюдают за рассуждениями и реакцией соискателя, а также за его поведением в ситуации, когда необходимо быстро решать возникшую задачу.

Вот примеры некоторых таких задач.

1. Перед вами два мотка веревки. Если взять их концы и поджечь, то каждый моток сгорает за один час. Вопрос: как правильно отмерить 45 минут, применяя два таких мотка веревки, при условии, что веревку нельзя делить?

Ответ на задачу. Одновременно поджечь один моток с двух концов, а второй – с одной стороны. Ровно через 30 минут первый моток полностью выгорит, а второму останется гореть 30 минут. Чтобы получить желаемые 15 минут, его придется снова поджечь с обеих сторон.

2. Есть три стакана: с черникой, земляникой и смесью ягод. Каждый стакан помечен неверно. Вы можете достать одну ягоду из одного стакана, при этом заглядывать внутрь нельзя. Как узнать содержимое всех стаканов и правильно расставить метки?

Ответ на задачу. Так как стаканы подписаны неверно, ни в одном из них не лежит то, что указано на пометках. Стоит начать с надписи смесь (С). Достанем ягоду. Черника? Значит, этот стакан с черникой. Остаются два стакана с пометкой черника (Ч) и земляника (З). В стакане (З) может быть черника или смесь. Но так как чернику мы уже нашли, то в стакане с пометкой (З) может быть только смесь. В последнем стакане с пометкой (Ч) останется земляника.

3. У вас в запасе бесконечный источник воды, а также два сосуда – на 5 литров и 3 литра. Как отмерить 4 литра, используя только этот инвентарь?

Ответ на задачу. Для начала необходимо наполнить емкость в 5 литров и вылить часть воды в трехлитровый сосуд. Сейчас в меньшем сосуде находится 3 литра, в большом – 2. Затем нужно опустошить маленькую емкость и перелить в него оставшуюся воду из большого. После этого заново наполнить пятилитровый сосуд и перелить из него воду в трехлитровую емкость. За счет уже имеющихся 2 литров доливать придется всего литр, а в большей емкости останется 4 литра.

Таких задач множество. Ты можешь потренироваться в их решении, чтобы быть готовым к решению подобной на собеседовании.

Не стоит удивляться такому суровому отбору. Компании в сфере IT заинтересованы в долгосрочном сотрудничестве и прилагают массу усилий, чтобы не только новый сотрудник чувствовал себя хорошо на новом месте работы, но и те сотрудники, которые уже работают в компании, не испытывали дискомфорта от его присутствия. Поэтому для стажера, впервые трудоустраивающегося в компанию, зачастую его мотивация и софтскиллс гораздо важнее, чем профессиональные навыки и знания.

По окончании собеседования тебе останется лишь ждать решения компании. Если оно положительное, я поздравляю тебя! Ты принят на свою первую работу и начал карьеру в игровой индустрии и тестировании.

Наталья Шевякова, HR и психолог Bytex

Хочу дать несколько советов, которые помогут успешно пройти собеседование при трудоустройстве на должность тестировщика.

1. Ознакомьтесь с игровой индустрией. Понимание текущих тенденций, популярных жанров и ключевых компаний в индустрии покажет вашу заинтересованность и знание сферы.

2. Разберитесь в основах тестирования. Необходимо понимать, что такое тест-кейсы, как оформлять баг-репорты, и основы методологий тестирования (например, ручное и автоматизированное тестирование).

3. Играйте в игры с аналитическим подходом. Практикуйтесь в тестировании, играя в различные игры. Обращайте внимание на баги, недочеты в геймплее и предлагайте возможные улучшения.

4. Развивайте технические навыки. Опыт работы с различными операционными системами, базовые знания программирования и понимание жизненного цикла разработки ПО будут большим плюсом.

5. Улучшайте свои коммуникативные навыки. Тестировщику важно уметь четко и ясно описывать обнаруженные проблемы, а также эффективно работать в команде.

6. Подготовьте примеры своей работы. Если у вас есть опыт тестирования (даже если это личные проекты), подготовьте примеры баг-репортов или описаний тест-кейсов.

7. Изучите компанию и продукт. Перед собеседованием узнайте как можно больше о компании и тестируемой игре. Это покажет вашу заинтересованность и готовность к работе именно с их продуктом.

8. Будьте готовы к практическим заданиям. На собеседовании могут предложить выполнить тестовое задание – например, найти баги в игре или написать тест-кейс.

9. Проявите энтузиазм и готовность к обучению. Показывайте, что вы готовы учиться и развиваться в данной области.

10. Подготовьте вопросы к интервьюеру. Это покажет вашу заинтересованность в должности и компании, а также поможет лучше понять требования и условия работы.

Успех на собеседовании зависит от вашего умения общаться и вести диалог, слушать собеседника, отвечать на вопросы интервьюера, а также от способности демонстрировать свои профессиональные навыки и знания.

6.1.5. Как пережить отказ при трудоустройстве

Но что делать, если пришел отказ?

Во-первых, ты должен понять, что жизнь на этом не заканчивается и услышать отказ в самом начале карьеры – это обычное явление, тем более что конкуренция в отрасли довольно высокая. По своему опыту могу сказать: на должность стажера-тестировщика в компанию, занимающуюся игровым тестированием, принимается один человек из 8–9 обратившихся. И это только по результатам очного собеседования: отсев на этапе анализа резюме еще больше.

Во-вторых, попробуй получить фидбек рекрутера. Если основанием для отказа были недостаточные опыт и навыки, это просто исправить. Причины, которые не касаются формальных требований, выяснить будет сложнее.

В-третьих, тебе нужно успокоиться (я понимаю, что ты расстроен) и провести работу над ошибками. Постарайся ответить на следующие вопросы.

• Адекватно ли ты оценил себя на конкретном рынке труда?

Обрати внимание на разницу в зарплатах. В столичных городах уровень зарплаты для одной и той же должности всегда будет выше, чем в регионах.

• Структурированы ли твои навыки и достижения в резюме?

Проверь еще раз, отвечают ли указанные тобой навыки и знания требованиям конкретной вакансии.

• Хорошо ли ты презентуешь себя на встрече?

Конечно, уверенность в себе – это огромный плюс, но вот разыгрывать из себя альфа-самца, стремясь произвести впечатление на девушку из отдела HR, – не лучшая идея. Не лучший вариант и обратная ситуация – начать разговор с того, что ты прошел уже три собеседования, и никто не хочет тебя брать на работу. Просто будь собой!

• Умеешь ли ты отвечать на популярные вопросы нанимателя?

Нужно еще раз освежить свои знания, чтобы успешно отвечать на вопросы собеседующих. Знания со временем имеют свойство устаревать.

• Не мешают ли соцсети или активность в Интернете вашей карьере?

Автору известны случаи, когда после получения резюме соискателя работодатель поручал службе безопасности провести проверку, в том числе и аккаунтов в социальных сетях.

• Подходящее ли фото ты выбрал для резюме?

Если ты решил ошарашить потенциального работодателя своим фото с новогоднего корпоратива, это весьма спорное решение. Конечно, HR запомнит резюме с фото лучше, чем без него, но ты же не хочешь нанести психологическую травму нанимателю, который тебе пока ничего плохого не сделал? ☺

• Соблюдаешь ли ты правила прохождения интервью: не опаздываешь ли, уместен ли твой внешний вид?

Пунктуальность (тайм-менеджмент) очень важна в тестировании. Многие люди очень критично относятся к тем, кто не считает предосудительным немного опоздать на встречу. Тебе также не прибавит очков вызывающая или слишком открытая одежда. Помни, что собеседование – это деловая встреча.

Поиск работы, особенно первой, – это, конечно, серьезный стресс. Но не стоит накручивать себя дополнительно. Рекрутеры всегда ведут базы хороших кандидатов, а значит, даже если ты получил отказ сейчас, в будущем тебе могут предложить другую позицию в той же компании.

6.2. Куда расти в тестировании

В самом начале этой книги я упоминал о том, что для тестировщика, по сути, открыты все дороги для развития в игровой индустрии, как и для любого другого специалиста. Но здесь я хотел бы рассмотреть вопросы развития именно в области тестирования. Примерная эволюционная цепочка тестировщика нашла свое отражение в схеме сертификации тестировщиков ISTQB. Она вполне отражает рост и роли тестировщика практически в любой компании. По сути, специалист в области тестирования может развиваться, выбирая узконаправленные области: тестирование мобильных приложений, производительности, безопасности, искусственного интеллекта, автоматизация тестирования и т. д. Причем одновременно с этим можно выбрать направления тестирования с опорой на используемые модели разработки – последовательные или гибкие.

Вертикальный рост сотрудника в компании обусловлен приобретенным им опытом и уникальными навыками. Традиционная траектория развития включает в себя переход на уровень тест-аналитика, тест-менеджера, то есть руководителя (лида) группы тестирования. Предлагаем рассмотреть каждое из этих направлений подробнее.

Схема сертификации тестировщиков International Software Testing Qualification Board

6.2.1. Кто такие тест-аналитик и тест-дизайнер

До сих пор нет единого мнения, стоит ли разделять тест-анализ и тест-дизайн. Однако между ними есть разница.

Цель тест-аналитика – организовать процесс максимально эффективного тестирования с учетом существующих проектных ограничений (как правило, речь идет о недостатке ресурсов, в том числе временных). Для этого специалист должен:

• проанализировать пользовательские истории и продуктовые требования;

• описать в удобном виде и проанализировать объект тестирования (то есть игровой продукт);

• выбрать методы тестирования в конкретной тестовой среде;

• проанализировать тестовое покрытие;

• приоритизировать задачи тестирования.

На основе целей и задач такого специалиста я могу описать эту специализацию примерно так следующим образом.

Тест-аналитик – специалист, который определяет оптимальный набор тестов и их приоритеты для того, чтобы вся важная функциональность разрабатываемого продукта была протестирована в текущих ограничениях (времени/бюджета). При отсутствии системного аналитика играет его роль и может подключаться к работе на этапе формирования бизнес-требований.

Тест-аналитик – это специалист, планирующий процесс тестирования на основе анализа продукта

Задача тест-дизайнера – оптимизировать процесс тестирования с точки зрения минимально необходимого для достижения целей набора тест-кейсов. То есть в идеале процесс должен выглядеть следующим образом.

1. Тест-аналитик анализирует продукт, декомпозирует его на составляющие компоненты для лучшего понимания области тестирования и расставляет приоритеты тестирования исходя из оценки ситуации.

2. Тест-дизайнер на основании информации, полученной от тест-аналитика, разрабатывает тест-кейсы, применяя соответствующие техники тест-дизайна для оптимизации ресурсов.

3. Тестировщик проводит тестирование по уже готовым тест-кейсам и составляет отчет о дефектах.

Однако в реальности такое разделение на специализации встречается довольно редко (только в очень крупных компаниях). Поэтому зачастую анализ и дизайн выполняет один специалист. Я буду здесь называть его тест-аналитиком.

Одна из задач тест-аналитика – определить методы проведения тестирования продукта. Для этого он использует разные инструменты, облегчающие восприятие и анализ объекта тестирования, – например, интеллект-карту (mind map). Ниже представлен пример интеллект-карты для описания одного из элементов игрового продукта.

Процесс построения интеллект-карты связан с декомпозицией продукта на мельчайшие части. При этом есть важное правило декомпозиции: все объекты одного уровня, являющиеся компонентами одной системы (то есть составляющими объекта верхнего уровня), объединяет один общий признак. Например, компонент «Метательное оружие» состоит из подкомпонентов «Лук» и «Копье», а компонент «Пистолеты» – из «Walther» и «Beretta». Декомпозиция нужна для более ясной визуализации продукта и для увеличения покрытия функционала игрового продукта тестами. Описывая процесс тестирования игровых механик, мы говорили о декомпозиции игрового продукта на пользовательские истории с учетом жанровой принадлежности. Глубокая компонентная декомпозиция игры позволяет ясно увидеть объем, который нужно покрыть проверками. Глубина декомпозиции должна быть такова, чтобы четко увидеть все функциональные и нефункциональные области, требующие тестирования.

Пример части интеллект-карты

Пример декомпозиции по объективному признаку

Глядя на декомпозированный проект, часто можно понять, что команде может не хватить времени для проведения тщательного тестирования. В такой ситуации, как правило, встает вопрос об увеличении проектных ресурсов (например, времени или команды тестирования). Это всегда приводит к увеличению бюджета проекта, что может быть нереально в конкретной ситуации. В этом случае задача тест-аналитика – определить наиболее приоритетные области проекта и виды тестирования для получения лучших результатов.

Приоритизация чаще всего основывается на следующих факторах.

1. Требования заказчика (владельца продукта).

2. Риски. Области продукта, отказ в которых принесет наибольший ущерб, необходимо тестировать в первую очередь и особенно тщательно. Вспомни базовые жанровые механики. Если в шутере игрок не может стрелять или передвигаться, игра перестает оправдывать свое жанровое название, и игроки не будут в нее играть.

3. Временные ограничения. Если идет предрелизное тестирование, тестировать нужно самый важный для этого релиза функционал.

Тест-аналитик может использовать следующие методы приоритизации.

1. Оптимизация тестов (в том числе их количества).

Частично этого можно добиться, проанализировав вышеуказанные факторы и выбрав наиболее приоритетные области для покрытия, определяя, какие тесты должны выполняться прежде всего. Другой способ оптимизации – применение техник тест-дизайна. В качестве примера можно привести применение техники попарного тестирования во время проверок производительности и совместимости (P&C), где этот подход оправдан и позволяет существенно сократить время тестирования и количество тестов при незначительном сокращении области покрытия.

2. Оптимизация рабочих процессов.

Одна из задач тест-аналитика – выявление неоптимальных временных трат сотрудников на разных этапах рабочего процесса. Этому помогает проведение ретроспектив, на которых команда обсуждает улучшения и оптимизацию рабочих процессов.

3. Применение инструментов.

Применение новых технологий и инструментария, которые способны ускорять процессы тестирования или выполнение проектных задач.

4. Выбор стратегии тестирования.

Правильный выбор стратегии тестирования определяет приоритетные области тестирования и оптимальный подход при проведении тестирования. Например, стратегия автоматизации регрессионного тестирования при правильной реализации позволяет существенно сократить время тестирования.

5. Применение автоматизированного тестирования.

В тестировании игр к автоматизации подходят довольно осторожно, потому что часто написание автотеста сопоставимо с временем и стоимостью разработки. То есть экономическая целесообразность автоматизации тестирования может оказаться очень и очень низкой. Иногда, впрочем, применение автоматизированных тестов может сократить общее время тестирования продукта. К ним можно отнести, например, симуляцию боя произвольно выбранных колод в коллекционной карточной игре для проверки баланса.

После анализа несколько десятков вакансий «Тест-аналитик» у меня получился следующий список ожиданий работодателя от такого специалиста.

• Общее понимание жизненного цикла разработки ПО, особенностей разработки игр и места контроля качества в нем

• Анализ требований, технической документации и тестового покрытия

• Организация сбора и автоматизации игровых данных

• Контроль полноты покрытия требований

• Декомпозиция требований

• Оценка покрытия функционала

• Приоритизация тест-кейсов

• Знание и умение использовать техники тест-дизайна

• Составление графика тестирования

• Выявление причин пропуска инцидентов в релизных сборках

• Понимание принципов командной разработки продукта, в частности игрового

• Передача результатов и составление рекомендаций для заинтересованных лиц

В компании с полным циклом разработки, где весь процесс разработки от идеи до передачи готового игрового продукта в релиз реализуется одной командой специалистов, тест-аналитик начинает работать существенно раньше, чем программисты. Его задача – выяснить цели тестирования, основываясь на разных факторах: игровая платформа, жанр игры, принадлежность к многопользовательскому типу, целевой аудитории и т. д. От его умений и способностей зависит ход и успех проекта тестирования. И это одно из направлений вертикального роста для тестировщика.

6.2.2. Кто такой SDET

Если ты решил развивать навыки программирования, но не хочешь уходить из тестирования, твой вариант карьерного роста – SDET (Software Development Engineer in Test).

Роль SDET заметно отличается от традиционной роли тестировщика. Тестировщики, как правило, фокусируются на ручном тестировании, поэтому наличие навыков программирования не является для них жизненно необходимым. Сильными сторонами тестировщика всегда были знание предметной области, интуиция, нестандартное мышление, навыки планирования тестирования и настройки системы тестирования и внимательность. И это все безусловно важные, незаменимые навыки. SDET занимаются тестированием ПО как разработчики и поставляют решения для автоматизации с нуля.

SDET – это разработчик, специализирующийся на тестировании

Часто такого специалиста путают с тестировщиком, занимающимся автоматизированным тестированием.

Для лучшего понимания разницы между мануальным тестировщиком, автотестером и SDET ты можешь изучить таблицу ниже.

Другими словами, от SDET в компании, которая занимается разработкой и тестированием игровых продуктов, будут ожидать:

• понимания сути процесса тестирования и пайплайнов проекта;

• способности осуществить проверку работоспособности автотестов;

• умения разрабатывать и поддерживать тест-кейсы для автотестов;

• планирования и реализации автотестов;

• способности разрабатывать фреймворки[44] автоматизации тестирования;

• автоматизации тест-кейсов с использованием фреймворков;

• разработки вспомогательных инструментов для ручного и исследовательского тестирования;

• хорошего владения Python;

• хорошего владения C#/C++;

• помощи в устранении дефектов;

• способности настраивать базы данных;

• взаимодействия со всеми заинтересованными лицами проекта.

Как ты заметил, SDET – это суперпрокачанный QA-инженер. Он играет важную роль в обеспечении высокого качества ПО, помогает сократить время на тестирование и улучшить процесс разработки.

Карьера тестировщика компьютерных игр может развиваться по-разному. Но для достижения успеха нужно не только обладать навыками тестирования, но и постоянно совершенствоваться и быть готовым к изучению новых технологий и методик.

6.2.3. Кто такой тест-менеджер

Тест-менеджер – это специалист по управлению процессом тестирования ПО. Такой специалист работает вместе с командой разработчиков и тестировщиков, чтобы обеспечить эффективное тестирование программного продукта и достижение качества.

Тест-менеджер обязательно должен иметь хорошие навыки управления проектами, понимание методологий тестирования, опыт работы с инструментами для автоматизации тестирования и знание процессов разработки программного обеспечения. Кроме того, тест-менеджер должен быть хорошим коммуникатором и иметь способность работать в команде, чтобы обеспечить эффективное тестирование и достижение качества.

Тест-менеджер (QA-менеджер) – управленец высшего звена в тестировании

Задачи тест-менеджера варьируются в разных компаниях, но обычно включают в себя следующие.

1. Планирование и организацию тестирования, включая определение приоритетов, составление тестовых планов, оценку рисков и разработку стратегии тестирования.

Определение приоритетов тестирования – это процесс определения того, какие функции или части приложения должны быть протестированы в первую очередь.

Этот процесс включает в себя несколько шагов.

• Оценка рисков

• Анализ функциональности

• Планирование времени и других ресурсов

• Обработку обратной связи от клиентов

• Определение зависимостей между функциями приложения для понимания того, что тестируется в первую очередь

Эти шаги используются для разработки плана тестирования, который позволит максимально эффективно использовать ресурсы.

2. Управление процессом тестирования, включая назначение задач тестировщикам, контроль за выполнением тестов, мониторинг результатов тестирования и своевременное информирование о проблемах.

Управление процессом тестирования – планирование, контроль и координация всех этапов процесса тестирования ПО. Он включает в себя определение стратегии тестирования, создание тест-планов и тест-кейсов, управление ресурсами для тестирования, контроль качества процесса тестирования и отчетность о его результатах.

Можно кратко выделить важнейшие этапы управления процессом тестирования.

• Определение целей и стратегии тестирования. Важно четко определить, чего нужно достичь в результате тестирования, а также какие методы и инструменты использовать.

• Создание тест-планов и тест-кейсов. На этом этапе необходимо определить, какие тесты нужно провести, какие данные использовать и какие ожидаемые результаты. Тест-план должен быть основным документом, описывающим все процессы тестирования.

• Выбор и управление ресурсами. Необходимо определить, какие ресурсы понадобятся для тестирования, включая оборудование, программное обеспечение и персонал. Кроме того, необходимо контролировать расходы на тестирование и управлять временем.

• Контроль качества процесса тестирования. На этом этапе необходимо проводить контроль за процессом тестирования, включая отслеживание прогресса тестирования, оценку результатов тестирования и выявление проблем.

• Отчетность о результатах тестирования. Необходимо подготовить отчет о результатах тестирования, включая информацию о найденных ошибках, оценку качества программного обеспечения и рекомендации по улучшению процесса тестирования.

• Управление процессом тестирования. Требует внимания к множеству деталей и умения координировать различные аспекты всего процесса тестирования.

3. Координация работы между командой тестировщиков и другими участниками проекта, включая разработчиков, менеджеров проекта и заказчиков.

Для обеспечения эффективной координации тестировщиков и разработчиков на проекте используются следующие подходы.

• Раннее вовлечение тестировщиков в проект. Тестировщики могут принимать участие во всех этапах проекта, начиная с планирования, анализа требований, проектирования и т. д. Это поможет им понять цели проекта, а также обеспечить более раннее выявление и устранение дефектов.

• Установление четких коммуникационных каналов. Разработчики и тестировщики должны иметь возможность общаться между собой и обмениваться информацией о проекте. Для этого можно использовать разные средства коммуникации: электронную почту, мессенджеры, системы управления проектами и т. д.

• Организация регулярных совещаний. Разработчики и тестировщики должны регулярно встречаться для обсуждения прогресса проекта, обмена информацией и урегулирования возможных конфликтов. В зависимости от проекта это может быть ежедневное совещание или более редкие встречи.

• Установление единой системы работы с багами. Разработчики и тестировщики должны иметь доступ к общей системе управления багами, в которой они могут фиксировать, отслеживать и устранять дефекты. Это поможет избежать дублирования работы и снизить время на устранение ошибок.

• Разработка тест-кейсов. Тестировщики должны иметь доступ к требованиям проекта, чтобы разработать тест-кейсы, которые помогут выявить дефекты в соответствии с этими требованиями. Разработчики должны иметь доступ к результатам тестирования, чтобы убедиться в соответствии своего кода требованиям.

• Установление общих целей и приоритетов. Разработчики и тестировщики должны иметь общее понимание целей проекта и приоритетов задач. Это поможет им более эффективно сотрудничать, сосредотачиваясь на наиболее важных для проекта задачах.

4. Оценка качества программного продукта и разработка мероприятий по улучшению его качества, включая проведение анализа дефектов и определение причин ошибок.

Первопричина – это корень проблемы, которая приводит к дефекту. Я уже говорил о том, что определение первопричин дефектов в игровых продуктах – важная задача для тестировщиков и навык, который приходит с опытом.

5. Оценка и выбор инструментов тестирования и управления тестированием.

При оценке инструментов необходимо учитывать следующие факторы.

• Тип игры: в зависимости от него могут потребоваться разные инструменты тестирования. Например, инструменты тестирования для шутера от первого лица могут отличаться от инструментов для игры-головоломки.

• Платформа: выбранные инструменты тестирования должны быть совместимы с платформами, на которых разрабатывается игра, такими как РС, консоли, мобильные устройства и т. д.

• Бюджет также будет играть решающую роль в выборе инструментов тестирования, которые вы можете себе позволить. Некоторые инструменты тестирования могут быть довольно дорогими, в то время как другие бесплатны или имеют открытый исходный код.

• Цели тестирования. Необходимо определить, что конкретно должно быть протестировано в игре: графика, звук, пользовательский интерфейс, игровой процесс или производительность. Затем нужно выбрать инструменты, предназначенные для этих областей.

• Удобство для пользователя: нужно определить, насколько просты в использовании инструменты и требуют ли они специальных навыков или опыта работы для того, чтобы ваша команда не тратила много времени на освоение этого инструмента. Также нужно обратить внимание на уровень технической поддержки, предоставляемой поставщиком инструмента.

• Совместимость. Выбранные инструменты должны быть совместимы с другими используемыми инструментами, такими как ПО для отслеживания ошибок, инструменты управления проектами и инструменты автоматизации.

6. Разработка отчетов о тестировании и документации, включая описание тест-кейсов, результаты тестирования и оценку качества.

Написание отчета о проведении тестирования компьютерной игры требует следования определенным правилам.

• Структура: отчет должен содержать введение, методику тестирования, результаты тестирования и заключение. Каждый раздел должен быть четко обозначен и иметь свой заголовок.

• Язык: отчет должен быть написан на языке, понятном для целевой аудитории. Необходимо использовать профессиональный язык, избегать жаргонных выражений и не использовать слишком сложных терминов (и, если это необходимо, нужно добавить их объяснение).

• Четкость и краткость. Краткие предложения и параграфы облегчают чтение и понимание информации.

• Объективность: отчет не должен содержать личных мнений или предубеждений. Описываются только факты и результаты тестирования.

• Детали тестирования: в отчете следует указать детали тестирования, включая инструменты и методы, использованные для проведения тестирования, количество участников тестирования, его продолжительность и т. д.

• Рекомендации: в отчете следует дать рекомендации по улучшению игры на основе результатов тестирования.

• Проверка на ошибки: перед отправкой отчета на проверку отчет необходимо обязательно проверить на наличие грамматических и пунктуационных ошибок, а также на логические ошибки.

Ожидания работодателей к тест-менеджеру обычно включают в себя следующие.

• Опыт в области тестирования, чтобы понимать процесс тестирования и управлять им.

• Знание методологий и инструментов тестирования, чтобы выбирать наиболее подходящие для конкретного проекта.

• Навыки управления проектами, чтобы планировать, координировать и контролировать процесс тестирования.

• Коммуникативные навыки для взаимодействия с различными участниками проекта, такими как разработчики, бизнес-аналитики, менеджеры и клиенты.

• Аналитические способности для анализа данных тестирования и принятия решений на основе этих данных.

• Опыт работы с автоматизацией тестирования может значительно повысить эффективность и качество тестирования.

• Сертификация в области тестирования типа ISTQB, чтобы продемонстрировать свои знания и навыки в этой области.

Тест-менеджер (руководитель тестирования, QA manager) – это фактически высшая ступень в иерархии тестировщиков.

Можно было бы продолжить список и упомянуть, например, возможность развиваться до уровня проектного менеджера и продюсера или перехода в область поддержки пользователей. Приобретая опыт, специалист в области тестирования как никто другой понимает, как НЕ нужно делать, чтобы избежать проблем и ошибок на разных этапах разработки. Этот опыт и знания вместе с дополнительными навыками позволяют успешно управлять проектом или улучшать опыт взаимодействия с игровым продуктом со стороны пользователей.

Попав в индустрию и имея желание развиваться в ней, а также имея необходимые базовые навыки, ты можешь развиваться абсолютно в любом направлении и стать кем угодно. Важно только быть честным с собой и быть готовым к большой работе. Конечно, если у тебя нет слуха, ты вряд ли сможешь стать композитором, но все остальные направления для тебя открыты.

Заключение

Ты почти закончил читать эту книгу. Каждая ее строчка была написана для того, чтобы ты понимал: тестирование – это процесс, который требует высокой квалификации, терпения, усидчивости и любви к играм. Без сомнения, тестирование игр – это одна из самых увлекательных и захватывающих профессий в индустрии геймдева.

Ты одним из первых увидишь грядущие хиты, на твоих глазах появятся новые гейм-дизайнеры с мировыми именами. Но и ты сам должен будешь соответствовать этому высокому уровню. Твоя будущая работа потребует постоянного развития и изучения новых технологий и методов тестирования.

Ты будешь находить ошибки и проблемы, которые никто не заметил, чтобы игроки могли наслаждаться игрой без проблем и перерывов. Твоя будущая работа – это повышение качества и эффективности игр, и ты станешь важным звеном, ценным членом команды в процессе их создания.

Я очень надеюсь, что эта книга поможет тебе освоить основы этой профессии, научит справляться с трудностями и проблемами в тестировании игр, а также покажет, как продвинуться по карьерной лестнице в индустрии геймдева.

Никогда не останавливайся, стремись к большему и лучшему. И помни, что твоя работа в игровой индустрии важна и ценна для многих игроков по всему миру, которые благодаря твоей работе смогут наслаждаться увлекательным миром игр.

P. S. Если ты захочешь связаться со мной для уточнения каких-либо вопросов, изложенных в этой книге, то можешь использовать мои контакты.

e-mail: atorgovkin@btx.games

VK: @atorgovkin

Приложение 1. Список полезной литературы

1. Axelrod, A. “Complete Guide to Test Automation”.

2. Copeland, L. “A Practitioner's Guide to Software Test Design”.

3. Fullerton, T. “Game Design Workshop: A Playcentric Approach to Creating Innovative Games”.

4. Grispin, L., Gregory, J. “Agile Testing”.

5. Grispin, L., Gregory, J. “More Agile Testing”.

6. Jackvony, K. “The Complete Software Tester: Concepts, Skills, and Strategies for High-Quality Testing”.

7. Levy, L., Navak, J. “Game QA & Testing”.

8. Myers, G. “The Art of Software Testing”.

9. Whittaker, J. “Exploratory software testing”.

10. Вигерс, К. «Разработка требований к программному обеспечению».

11. Ильяхов, М., Сарычева, Л. «Пиши, сокращай. Как создавать сильный текст».

12. Канер, С., Фолк, Дж., Нгуен, Е. «Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений».

13. Коберн, А. «Быстрая разработка программного обеспечения».

14. Куликов, С. «Тестирование программного обеспечения. Базовый курс».

15. Майерс, Г., Баджетт, Т., Сандлер, К. «Искусство тестирования программ».

16. Назина, О. «Что такое тестирование. Курс молодого бойца».

17. Программа подготовки ISTQB® CT-GaMe.

18. Раскин, Дж. «Интерфейс. Новые направления в проектировании компьютерных систем».

19. Савин, Р. «Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах».

20. Шелл, Дж. «Геймдизайн. Как создать игру, в которую будут играть все».

Приложение 2. Ответы на вопросы теста и заданий

Ответ на задание Матрица трассируемости

Ответ на вопросы теста Оценка проекта на вехах

1. Указанные активности выполняются в следующем порядке:

• Определение целей тестирования – этап «Планирование тестирования».

• Анализ базиса тестирования – этап «Анализ тестирования».

• Определение необходимых тестовых данных для поддержки тестовых условий – этап «Проектирование тестов».

• Сравнение фактических и ожидаемых результатов – этап «Выполнение тестов».

• Создание сводного отчета по тестированию – этап «Завершение тестирования».

2. Нижняя граница равна 10, верхняя – 50. Значит, для нижней границы проверяются значения 9, 10 и 11, а для верхней – 49, 50 и 51.

3. Главная задача на этапе завершения тестирования – написание итогового отчета.

4. Основной ошибкой стало то, что отчет составлялся без учета целевой аудитории, для которой он предназначался. Его данные были бы более полезны для технических специалистов, которые непосредственно исправляют дефекты.

Отчет для менеджмента должен содержать информацию, которая позволит быстро оценить ход проведения работ и их результат. Информация должна быть более высокоуровневой и отражать текущую ситуацию по количеству дефектов различных приоритетов, количеству пройденных и непройденных требований и т. д.

5.

a. Неверно. Дата может присутствовать в отчете, но она не так важна для исправления дефекта.

b. Верно. Подробное описание помогает разработчику понять, как проявляется дефект и как его воспроизвести.

c. Верно. Сравнения ожидаемого и фактического результата объясняет суть дефекта.

d. Верно. Приоритет дефекта показывает степень важности дефекта и то, как скоро его нужно исправить.

e. Неверно. Имя тестировщика включают в отчет о дефекте, но оно не так важно для исправления дефекта.

f. Неверно. Рекомендации по исправлению не включаются в отчет о дефекте.

Ответ на задание Тестирование ключевого функционала

1. Тестирование боевых характеристик:

a. Проверить правильность расчета урона при атаке персонажа.

b. Проверить влияние характеристик (силы, ловкости, интеллекта) на урон и шанс попадания.

c. Проверить работу различных видов оружия и брони персонажа.

2. Тестирование управления и взаимодействия:

a. Проверить корректность управления персонажем с помощью клавиатуры или контроллера.

b. Проверить взаимодействие персонажа с окружающим миром: открытие дверей, сбор предметов, взаимодействие с NPC.

3. Тестирование системы прокачки и опыта:

a. Проверить правильность начисления опыта за выполнение различных заданий или убийство монстров.

b. Проверить корректность увеличения уровня персонажа и распределение очков характеристик при повышении уровня.

4. Тестирование анимации и звуков:

Проверить корректность и плавность анимаций действий персонажа (атака, бег, прыжок и т. д.).

5. Проверка звуков:

a. Проверить наличие звуков для действий персонажа.

b. Проверить корректность звуковых эффектов действиям персонажа.

c. Проверить синхронизацию звуков с действиями персонажа.

6. Тестирование сохранения и загрузки игры:

a. Проверить корректность сохранения игрового прогресса и состояния персонажа.

b. Проверить корректность загрузки сохраненной игры и восстановление состояния персонажа.

Приложение 3. Список интернет-ресурсов для поиска работы

Порталы для поиска работы

1. HeadHunter (hh.ru) – крупнейший российский сайт для поиска работы

2. Superjob.ru (superjob.ru) – портал для поиска работы

3. Rabota.ru (rabota.ru) – сервис для поиска работы

4. Зарплата.ру (zarplata.ru) – сервис для поиска работы

5. Хабр Карьера (career.habr.com) – сервис для поиска работы от портала Habr

6. Tproger (tproger.ru/jobs/) – вакансии в IT

7. GeekJob (geekjob.ru) – каналы с вакансиями для IT-специалистов

Биржи для фрилансеров

8. Freelance (freelance.ru) – биржа для фрилансеров, где можно получить первоначальные заказы для портфолио

9. FreelanceJob (freelancejob.ru) – одна из старейших бирж для фрилансеров в России

10. FL (fl.ru) – еще одна биржа фрилансеров

11. UpWork (upwork.com) – биржа для фрилансеров, где ты можешь сотрудничать с иностранными заказчиками

12. FIVERR (fiverr.com) – еще биржа для фрилансеров, где ты можешь сотрудничать с иностранными заказчиками

Приложение 4. Образец резюме тестировщика (пример)

Приложение 5. Краткий словарь тестировщика

Апгрейд (от англ. upgrade) – обновление аппаратного обеспечения

Апдейт (от англ. update) – обновление программного обеспечения

Апишка (от англ. API) – интерфейс программирования приложений, который используется для взаимодействия между различными приложениями или сервисами

Апрув (от англ. approve) – одобрение чего-либо

Аттач (от англ. attachment) – прикрепленный к чему-либо файл (например, в баг-репорте)

Аджайл (от англ. agile software development) – семейство гибких методологий разработки, которые используются для разработки

Асайн (от англ. assign) – назначение кого-то на задачу или проект или передача бага специалисту для исправления в системе баг-трекинга

Аутсорсинг (от англ. outsourcing) – полная или частичная передача задач для выполнения посторонним лицам

Баг (от англ. bug) – недостаток компонента или системы, который может привести к отказу определенной функциональности

Билд (от англ. build) – сборка проекта из исходного кода

Брейншторм (от англ. brainstorm) – способ генерации новых идей или решения существующих проблем путем обмена идеями в группе людей

Бэкап (от англ. backup) – создание резервной копии данных, чтобы в случае сбоя можно было вернуть всю программу в прежнее состояние

Вайпнуть (от англ. wipe) – удалить все данные или настройки из программы или устройства

Вертикальный срез (от англ. vertical slice) – прототип приложения / демонстрация того, что удалось сделать за определенный период времени

Воркфлоу (от англ. workflow) – принцип организации рабочих процессов, отображающий различные сущности процесса, их переходы в различные состояния и условия для таких переходов

Ворнинг (от англ. warning) – сообщение об ошибке или предупреждение о возможной проблеме в приложении

Гайдлайн (от англ. guideline) – руководство или инструкция, которая описывает, как выполнять определенную задачу или проект

Генерить (от англ. generate) – создавать

Дебажить (от англ. debug) – отладка кода, поиск и исправление ошибок в коде

Девопс (от англ. devops) – методология, объединяющая разработку (dev) и операции (ops) для улучшения совместной работы команды и оптимизации процессов разработки и эксплуатации ПО

Дедлайн (от англ. deadline) – крайний срок выполнения проекта

Дейлик (от англ. daily meeting) – ежедневное совещание команды, на котором обсуждаются проделанная работа, планы на день и задачи

Деплой (или «задеплоить», от англ. deploy) – перенос исполняемого кода на сервер или устройство, где оно должно функционировать

Диздок (от англ. design document) – документ, описывающий приложение или отдельную фичу

Дистрибутив (от англ. distribute) – программный пакет, содержащий программный код и другие составляющие программы, созданный для выполнения деплоя программы

Дропнуть (от англ. drop) – удалить или отменить что-либо

Заовнить (от англ. own) – забрать запрос на самостоятельное решение

Инпут-лаг (от англ. input lag) – замедленная реакция игры на действия пользователя

Инсталлировать (от англ. install) – устанавливать программное обеспечение

Кейс (от англ. case) – сценарий использования

Колл (от англ. call) – созвон для обсуждения проблемы

Коммитить (или «закоммитить», от англ. commit) – зафиксировать изменения кода в хранилище кода

Конфа, конфлюенс (от англ. confluence) – сервис, содержащий полезную информацию

Конфиг (от англ. configuration) – конфигурационный файл программы

Костыль – исправление серьезных ошибок без должного исправления системы в целом, то есть решение проблемы в кратчайшие сроки в ущерб эффективности

Креды (от англ. credentials) – учетная запись пользователя, логин и пароль

Курить маны (от англ. manual) – читать документацию

Легаси-код (от англ. legacy code) – устаревший код

Лочить (от англ. lock) – блокировать доступ к ресурсам или функциям

Лог (от англ. log) – запись программного журнала

Майлстоун, МС (от англ. milestone) – контрольная точка в процессе разработки, тестирования продукта

Мержить (от англ. merge) – объединять изменения из разных веток разработки в одну основную ветку при использовании бранчинга

Мит (от англ. meeting) – собрание, совещание

Неписи (от англ. NPC) – второстепенные компьютерные персонажи

Овертаймить (от англ. overtime) – работать сверхурочно

Онбординг (от англ. onboarding) – процесс введения новых сотрудников в компанию

Опенсорс (от англ. open source software) – программное обеспечение с открытым исходным кодом, которое может использовать и изменять любой желающий

Откат – возвращение к исходному состоянию

Отрепортить (от англ. report) – отправить отчет

Пайплайн (от англ. pipeline) – общепринятые всеми участниками проекта нормы, правила и инструменты, которые используются на проекте

Парсить (от англ. parse) – собирать определенные данные из какого-либо источника путем поиска и извлечения данных из программного кода

Патч (от англ. patch) – дополнение или обновление программы, которое исправляет ошибки

Пинг (от англ. ping) – измерение времени, за которое данные отправляются и возвращаются от сервера в сети

Прод (от англ. production) – рабочая версия продукта, которую используют конечные пользователи

Пушить (от англ. push) – продвигать какую-либо идею, формировать рассмотрение вопроса

Резолвить (от англ. resolve) – решать проблему или исправлять баг

Релиз (от англ. release) – выпуск готовой версии продукта (например, игры)

Репорт (от англ. report) – документ, который содержит информацию о результате исследования

Ретро (от англ. retrospective) – совместное обсуждение прошлых достижений и неудач в проекте для извлечения уроков и оптимизации процессов

Рефакторинг кода (от англ. refactoring) – изменение исходного кода программы для облегчения его понимания и дальнейшей поддержки

Саппорт (от англ. support) – обеспечение технической поддержки продукта

Синкануться, засинкать (от англ. synchronize) – обменяться информацией в целях поддержания знаний о проекте в актуальном состоянии

Скоуп (от англ. scope) – объем работ, который нужно выполнить

Спека (от англ. specification) – детальное описание того, как должно работать ПО

Таска (от англ. task) – задание

Тегнуть (от англ. tag) – присвоить метку объекту для более удобного поиска

Тикет (от англ. ticket) – задача (обычно в системе управления или баг-трекинговой системе)

Тулза (от англ. tool) – вспомогательный программный инструмент для выполнения основной задачи

Фидбек (от англ. feedback) – обратная связь, отзыв

Фиксить (от англ. fix) – исправлять баг, решать проблему

Фича (от англ. feature) – уникальная особенность игры

Форсить (от англ. force) – делать что-то ускоренно или принудительно

Фриз (от англ. freeze) – замирание кадра / задержка в процессе геймплея

Чекать (или «прочекать», от англ. check) – проверять

Черри-пикинг (от англ. cherry picking) – действие в среде управления версиями Git, которое позволяет точечно выбрать необходимые изменения в других ветках и добавить в свою

Хотфикс (от англ. hotfix) – небольшое изменение в программном коде, которое вносится для решения конкретной проблемы без перекомпиляции всего приложения

Хурма – баг непонятного происхождения

Шарить (или «расшарить», от англ. share) – делиться информацией, открыть доступ к файлу

Юзать (от англ. use) – пользоваться

Приложение 6. Источники изображений

Все изображения в книге были использованы с информационной целью и для раскрытия творческого замысла автора. Ниже приводится список заимствованных для указанных целей изображений и их источников.

Примечания

1

Saber Interactive – международная компания по разработке и изданию компьютерных игр. Офисы разработки находятся в России, Армении, Испании, Беларуси, Швеции и Португалии. – Здесь и далее прим. авт.

2

Bytex – российская компания, специализирующаяся на тестировании компьютерных игр любого жанра на любых платформах.

3

RSTQB (Russian Software Testing Qualifications Board) – российское представительство открытой международной организации ISTQB, занимающейся развитием тестирования программного обеспечения через обучение и сертификацию.

4

Шутан (от «шутер», англ. shooter) – жанр игры от первого или третьего лица, в котором игровой процесс основан на использовании в сражениях огнестрельного оружия.

5

Баг – жаргонное название дефекта. В индустрии ходит такая легенда о появлении этого термина. В 1945 году при испытании компьютера Mark II случился сбой в работе, вызванный мотыльком, закоротившим собой контакты реле. В журнале была сделана соответствующая запись о первом подтвержденном случае обнаружении бага (жука). Так с тех пор называют любой дефект программного или аппаратного обеспечения.

6

Плейтест (англ. playtest) – метод тестирования игры путем предоставления ее группе представителей целевой аудитории для обнаружения потенциальных дефектов и сбора отзывов.

7

Продукт развивается, и требования могут быстро устаревать. Если требования не актуализируются, то, как правило, использовать их в работе нет никакого смысла. Поэтому одна из важных задач в проекте – поддерживать требования к продукту в актуальном состоянии.

8

ГДД (гейм-дизайн-документ) – детальное описание разрабатываемой компьютерной игры.

9

QA (Quality Assurance) – это любой систематический процесс определения соответствия продукта или услуги определенным требованиям.

10

Краш – полная поломка, аварийный сбой.

11

Тест-кейс – это детально описанный сценарий или инструкция, которая позволяет тестировщикам выполнить определенные шаги для проверки определенной функциональности или поведения программного продукта. Это основной инструмент в процессе тестирования программного обеспечения, включая компьютерные игры.

12

Иногда также называется Repro Frequency.

13

Баг-трекер (англ. bug tracking system, bug-tracker – «система отслеживания ошибок») – прикладная программа, разработанная с целью помочь разработчикам программного обеспечения (программистам, тестировщикам и др.) учитывать и контролировать ошибки и неполадки, найденные в программах, пожелания пользователей, а также следить за процессом устранения этих ошибок и выполнения или невыполнения пожеланий.

14

В некоторых компаниях для определения этого фактора может быть использовано отдельное поле. Оно может так и называться – влияние на пользователя (User effect), в английском варианте еще употребляется User impact, Probability. То есть то, насколько вероятно, что пользователь встретит этот дефект. Сам посуди, если баг возникает при прохождении основного сюжетного квеста в игре, то вероятность его встретить 100 %, а если эта проблема где-то на краю локации в подземельях и туда еще надо добежать, то понятное дело, что не каждый игрок найдет это место, а значит и баг.

15

Рендеринг – термин в компьютерной графике, обозначающий процесс получения изображения по модели с помощью компьютерной программы.

16

Summary реальных баг-репортов.

17

Конечно, для этого тебе потребуется приобрести довольно большой опыт работы на разных проектах.

18

Таким тестированием, как правило, занимаются сами художники или тестировщики, имеющие специализацию в этом направлении.

19

Гибкие модели разработки (Agile) – методологии, основывающиеся на цикличном методе (итерационном подходе). В нем решения разрабатываются на основе анализа требований в результате работы самоорганизующихся кросс-функциональных групп (которые делают однородную творческую работу) при управлении ими комбинированным (либеральным и демократическим) методом.

20

Себестоимость проекта – стоимостная оценка всех затрат на реализацию проекта.

21

Аттачи (от англ. attachments) – дополнительные материалы.

22

Потому что у них, как правило, нет особого выбора или возможности внедрять что-то в группе разработки.

23

В управлении проектами – контрольная точка, значимый, ключевой момент. Как правило, с этим моментом связано завершение какого-либо ключевого мероприятия, подписание важных документов или любые другие значительные действия, предусмотренные планом проекта.

24

Решение о продолжении проекта.

25

Smoke-тест (дымовое тестирование) – проведение минимального набора тестов для выявления явных ошибок.

26

Стрейф (от англ. strafe) – в играх жанра FPS движение персонажа вперед-вбок, то есть диагонально. Такое движение позволяет уклоняться от огня противника и передвигаться чуть быстрее.

27

Спавн (от англ. respawn) – появление NPC, монстра, персонажа или предмета в игровом мире, как правило, после убийства или его подбора.

28

Навигационная сетка – это абстрактная структура данных, используемая в приложениях ИИ для помощи агентам (неигровым персонажам в случае с играми) в поиске пути в сложных пространствах.

29

Самые используемые 3D-редакторы – Maya, 3D Max и Blender.

30

Тексель – минимальная единица текстуры трехмерного объекта, пиксель текстуры.

31

Звуковая зона – это область на игровой карте, при попадании в которую активизируется дополнительная озвучка этого места. Например, при выделении какого-то здания на карте в стратегической игре игрок слышит звуки событий, происходящих конкретно в этом здании (голоса людей, шум оборудования и т. д.).

32

Утечка памяти (от англ. memory leak) – ситуация, когда программа неправильно использует оперативную память компьютера, постепенно расходуя ее ресурсы без возможности их освободить. В результате доступная память постепенно уменьшается, что может привести к ухудшению производительности системы или даже ее сбою.

33

Трей (англ. Tray) – раздел интерфейса пользователя, где показаны иконки системных функций и приложений, не размещенные на главном экране.

34

Нагрузочное тестирование исследует способность системы обрабатывать растущие объемы ожидаемой реалистичной нагрузки (ISTQB CTFL-PT).

35

Реплика, использованная в одном из переводов Grand Theft Auto: San Andreas в ситуации, когда персонаж погибал, и которая могла звучать как «Урыли!» или «Уделали!».

36

Федеральный закон от 29.12.2010 № 436-ФЗ (ред. от 29.12.2022) «О защите детей от информации, причиняющей вред их здоровью и развитию».

37

NDA (Non-disclosure agreement) – соглашение о неразглашении; форма договора, предотвращающего утечку конфиденциальной информации.

38

Нотация – процесс (Basic Flowchart в Visio). Данная нотация используется для представления алгоритма выполнения процесса (нотация класса workflow).

39

Унифицированный язык моделирования (UML) был разработан для проектирования и внедрения программных систем со сложной структурой и комплексным поведением. Применяется также для описания различных процессов.

40

У Sony этот документ называется Technical Requirements Checklist (TRC) для PlayStation, у Nintendo – Nintendo Switch Guidelines, у Microsoft – Xbox Requirements (XR) for Xbox Console Games для Xbox.

41

Human Resources (HR) – специалист, который занимается подбором и наймом персонала и много чем еще.

42

Инди-разработчики – это небольшая группа специалистов, разрабатывающих игру без финансовой поддержки со стороны инвесторов и издателей.

43

Визуализация проекта разработки (тестирования) продукта.

44

Фреймворк – готовая модель для быстрой разработки. Это основа, на базе которой можно дописать собственный код. Она задает структуру, определяет правила и предоставляет необходимый набор инструментов для создания проекта.

Content

Александр Торговкин
Тестирование видеоигр, или Легкий способ попасть в геймдев

Благодарности

От автора

Глава 01. Путь в тысячу ли начинается с первого шага

1.1. Как устроена профессия?

1.2. 7 принципов и 5 мифов тестирования

Глава 02. Самая большая ошибка – не исправлять ошибки

2.1. Отчет о дефекте (баг-репорт)

2.1.1. Атрибуты отчета о дефекте

2.1.2. Критичность дефекта (Severity)

2.1.3. Приоритет дефекта (Priority)

2.1.4. Признаки плохого баг-репорта

2.2. Жизненный цикл дефекта (Defect Life Cycle)

2.3. Первопричины дефектов

2.4. Как снизить риски возникновения дефектов

2.4.1. Использование моделей и методологий разработки

2.4.2. Использование ветвления (Branching)

2.4.3. Взаимодействие тестировщика с заинтересованными лицами

Глава 03. Чтобы все хорошо сделать, нужно все хорошо организовать

3.1. Планирование тестирования

3.1.1. План тестирования

3.1.2. Планирование ресурсов

3.1.3. Планирование рисков

3.2. Проектирование тест-кейсов

3.2.1. Чек-листы

3.2.2. Тест-кейс

3.2.3. Тест-дизайн

3.2.4. Наборы тест-кейсов (тест-суиты)

3.2.5. Как проектировать эффективные проверки

3.3. Выполнение тестирования

3.4. Завершение тестирования

3.4.1. Отчетные документы

3.5. Мониторинг и контроль тестирования

3.5.1. Метрики тестирования

3.5.2. Оценка проекта на вехах (контрольных точках)

Глава 04. Когда не знаешь, с чего начать, начинай с сути

4.1. Какие бывают игры?

4.2. Функциональное тестирование

4.2.1. Тестирование игровых механик

4.2.2. Тестирование уровней (игровых карт)

4.2.3. Тестирование моделей и анимации

4.2.4. Тестирование визуальных эффектов (VFX)

4.2.5. Тестирование освещения, отражений и теней

4.2.6. Тестирование звука

4.2.7. Тестирование искусственного интеллекта (ИИ) персонажей

4.2.8. Тестирование игровой физики

4.3. Нефункциональное тестирование

4.3.1. Тестирование пользовательского интерфейса

4.3.2. Тестирование совместимости

4.3.3. Тестирование производительности

4.3.4. Тестирование стабильности

4.3.5. Нагрузочное тестирование

4.3.6. Тестирование локализации

4.4. Прочие виды функционального/нефункционального тестирования

4.5. Тестирование документов и требований

4.6. Автоматизация тестирования игр

Глава 05. Общее у них только одно – все они разные

5.1. Мобильные устройства

5.2. Игровые консоли

5.3. Персональный компьютер (ПК, РС)

5.4. Virtual Reality (VR)

5.5. Облачные платформы

5.6. Инструменты тестирования

Глава 06. Целью всего является развитие

6.1. Начало карьеры

6.1.1. Как себя правильно оценить

6.1.2. Что написать в резюме

6.1.3. Алгоритм поиска первой работы

6.1.4. Как пройти собеседование

6.1.5. Как пережить отказ при трудоустройстве

6.2. Куда расти в тестировании

6.2.1. Кто такие тест-аналитик и тест-дизайнер

6.2.2. Кто такой SDET

6.2.3. Кто такой тест-менеджер

Заключение

Приложение 1. Список полезной литературы

Приложение 2. Ответы на вопросы теста и заданий

Приложение 3. Список интернет-ресурсов для поиска работы

Приложение 4. Образец резюме тестировщика (пример)

Приложение 5. Краткий словарь тестировщика

Приложение 6. Источники изображений

Примечания