Жизненный цикл дефекта – это период существования бага с момента, когда он был найден и описан тестировщиком, до момента, когда дефект был исправлен одним из игровых разработчиков. Схема ЖЦД важна для понимания того, что может произойти на этом пути. Часто эту схему называют модным словом 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. Это еще более продвинутая альфа-версия игры, но на этом этапе разработчики часто сосредотачиваются на оптимизации продукта, а не на добавлении новых функций. Они стараются устранить максимальное количество известных багов, часто вовлекая в ее тестирование большое количество людей, перед выпуском игры. Часто к бета-тестированию в качестве тестировщиков привлекают обычных игроков. Этот этап может быть сдан с дефектами, которые могут считаться значительными.