Loe raamatut: «Тестирование видеоигр, или Легкий способ попасть в геймдев», lehekülg 3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. Транспортное средство отказывается ехать¹⁶

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

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. Первопричины дефектов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 – проект, в котором ошибки допущены только при непосредственной разработке. Говорит о том, что команда программистов была очень слабой. Впрочем, такая ситуация тоже практически невозможна.