Перевод книги «Game QA & Testing». Часть 6

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

Предыдущая часть здесь:

Задолго до того как «прогремел гром» и появилось тестирование — были приняты некоторые очень важные решения. Давайте поближе посмотрим кто обычно принимает эти решения. Лягушонок Кермит как-то сказал знаменитое «Не так и просто быть зеленым». Также непросто быть боссом. В этом разделе мы попытаемся описать роли продюсера, QA менеджера, лида тестировщиков и неформального лида. Так как игровая индустрия стремительно развивается, временами сложно отследить кто именно что делает.

Продюсер месяцами (возможно и годами) выполняет надзорную роль за игрой во время разработки. «Главный по срокам” и “Мастер бюджета» — продюсер — будет первым защитником студии от жадного издателя или первым, кто уволит ту же студию, если они завалят сдачу проекта. Когда игра наконец готова к тестированию, продюсер протягивает руку QA менеджеру и запускает процесс.

Когда игра готова к тестированию, продюсер передает ее QA менеджеру — тому, кого возможно недавно наняли или перебросили с другого проекта. QA менеджер оценивает ситуацию и рассматривает несколько вопросов:

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

Лид тестировщиков (lead tester, ведущий тестировщик) может помочь собрать команду из тестировщиков, обычно это один из самых талантливых и наиболее опытных сотрудников. Лиды тестировщиков делают основную работу, необходимую при начале процесса тестирования, а также отвечают за все билды, записанные и в работе — которых может быть довольно много, в зависимости от размера команды. Хотя для современных игр есть возможность записать их на жесткий диск, иногда приходится все же использовать диски. В этот момент испытываются ваши навыки, как лидера. Как вы будете разбираться со всеми этими копиями, одновременно контролируя тестировщиков? Лиды тестировщиков — обычно опытные тестировщики из других подразделений. Как только команда собрана, лид тестировщиков может решить назначить неформального лида, чтобы распределить рабочую нагрузку — так как большие команды автоматически требуют большего надзора.

Неформальный лид (floor lead) — это «неофициальный» лид тестировщиков. Возможная замена, если дела идут плохо, или ассистент, если все идет хорошо. На некоторых проектах может быть несколько неформальных лидов — например, при мультиплатформенной игре, когда версии для Xbox, PlayStation и Wii тестируются одновременно. Неформальные лиды не имеют реальной власти и могут быть временными работниками (в командах временных тестировщиков). Чем они действительно должны обладать — это опытом и более глубоким пониманием процесса разработки. Поскольку неформальные лиды должны помогать с оценкой каждого тестировщика — хорошие отношения с ними помогут сохранить вам работу. Еще одна вещь, которую необходимо помнить — поначалу работа может показаться очень легкой, но на самом деле это далеко от правды. Чтобы быть эффективным неофициальным лидом, вам необходимо развивать не только технические, но и социальные навыки. Вы будете первой линией обороны при конфликтах во взаимоотношениях и персональных проблемах внутри команды. Так что сначала убедитесь, что вы с этим справитесь.

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

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

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

Clipping — это когда одни полигоны прорезают другие. Классический пример — это солдат, стоящий за закрытой дверью с оружием, которое торчит через дверь. Это часто встречалось в GoldenEye 007 (N64). Clipping также встречается в транспорте. К примеру, ноги персонажа не должны торчать сквозь джип.

В программировании координата Z отвечает за глубину. Когда встречается эта проблема — текстуры различной глубины могут перекрывать и «сражаться» (отсюда и название). Во время QA тестирования Quake 4 в лифтах командного центра часто встречался Z-fighting. Нередко дверь лифта или его стены перекрывают оригинальные текстуры окружения.

Классический визуальный баг разрыв экрана (screen tearing) — возникает, когда видеокарта не может создать кадр достаточно быстро — в результате возникает отвлекающий эффект тиринга. Обычно, происхождение этого бага — производительность, возможно из-за нехватки времени на обработку или от того, что это слишком сложно для платформы. Если разрывы экрана становятся слишком заметными, разработчики вынуждены снижать фреймрейт до уровня 30 кадров в секунду, вместо 60 — это решение «на скорую руку».

Когда вы столкнетесь с пропавшими текстурами (missing textures), вы увидите белую поверхность или заглушку (картинку, которая вставляется, если игровой движок видит отсутствие текстуры). Проблема в том, что про пропавшие текстуры забывают даже когда золотой статус уже близко — и часто в игре все равно остается несколько таких. Хотя пропавшие текстуры — обычно низкоприоритетный баг, он может быть приоритезирован как «средний», если вы сталкиваетесь с ним в особо заметном месте. Если же вы столкнетесь с временной текстурой при поздней бете — внесите это как высокоприоритетный баг. Это уже серьезно.

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

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

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

Разрывы звучания (audio drop) напоминают то, что вы слышите во время разговора по телефону при плохом соединении. Это как украсть слово «люблю”, из фразы “Я люблю тебя”. Вы слышите только “Я ... тебя”, что может значить “Я НЕНАВИЖУ тебя!». Но оставим разрушенные отношения. Разрывы звучания легко слышимы и очень раздражают. Вы можете пропустить важный диалог, многозначительный звук выстрела или любимый момент из песни. Однако, временами разрывы встречаются во время какофонии звуков, так что их становится сложно идентифицировать. Эти баги — самые непростые.

Звучащие словно на поцарапанном CD, пропуски (skipping) легко идентифицировать. В играх пропуски обычно следуют за провалами частоты кадров. Это хороший признак проблем с производительностью, а не с ассетами. Если это только проблема с производительностью, единственное ваше решение — записать их как «производительность» (читайте описание проблем производительности ниже в этой главе). Однако же всегда есть шанс, что звуковой эффект или музыка и правда повреждены.

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

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

Уровень звука (volume level). Если в игре имеется звуковой слайдер для каждого элемента — таких как «двигатель”, “шум дороги”, “оппоненты” и “фоновая музыка» — это не баг. Однако, если игра объединяет звуки в определенном виде — и вы не можете это изменить на экране опций — слишком тихий звуковой эффект или слишком громкая музыка — могут быть классифицированы как баги уровня звука.

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

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

Застревание (stuck spot) — классическое имя для классического бага. Вы можете припомнить самые первые 3D платформеры, такие как Super Mario 64 или Banjo-Kazooie. Было весело прыгать везде, исключая те ситуации, когда вы попадали между тремя деревьями и застревали. В большинстве случаев — виновник левелдизайнер. Плохая геометрия делает невозможным движение персонажа. Однако, застревания также часто встречаются в шутерах от первого лица. Вы можете найти их около углов и между коробками. Если вы наткнулись на такое, лучше загрузить предыдущее сохранение. Хуже, когда необходимо перезапускать игру или перезагружать уровень. Баги застревания — высокоприоритетные, потому что могут остановить геймплей.

Залипание (sticky spot) — «недоразвитый родственник» застревания. Эти баги среднего приоритета, да — вы можете выбраться, просто это занимает время. Залипание может перерасти в застревание, если левелдизайнер примет неверные решения после вашего отчета. С другой стороны, баг застревания может быть понижен до залипания опытным разработчиком.

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

Дыра в карте (map hole) — это звучит весело, но на самом деле очень серьезно. Если игрок провалится через нее, иллюзия присутствия моментально разрушится. Еще хуже, когда дыры в карте неглубокие и позволяют игрокам по-читерски стрелять в других из-под карты. (Это случалось в некоторых загружаемых картах Call of Duty 3. Было огромная дыра в карте на уровне, так что многие тестировщики спрыгивали туда специально, чтобы сделать прицельный хэдшот.) Единственный способ найти все дыры в карте — пройти по каждому ее квадрату. Нет другого пути. Вот почему временами игровое тестирование больше про дисциплину и репетативные действия, а не про навыки.

Пропавшая геометрия (missing geometry) — противоположность невидимой стены. Когда внешне стена или барьер для передвижения отображаются, но на самом деле их нет — потеряна часть геометрии. Самая распространенная вариация этого бага — «секретный проход» точно между стенами замка. (Такой был найден Луисом в Call of Duty 3, на карте Merville. Что забавно, эта пропавшая геометрия была прямо рядом с одним из флагов, так что захватить его становилось намного проще.)

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

Название бага «искусственный интеллект» (ИИ) — может заставить вас подумать, что речь о том, что игровые персонажи ведут себя по-умному. На самом деле нет. Когда персонажи делают что-либо абсолютно нелогичное — например, упираются в стену в течение 5 минут — можете быть уверены, что это проблема с кодом ИИ (AI, artificial intelligence). Примеры багов ИИ включают в себя поиск пути и поведение неигровых персонажей. Давайте поближе взглянем на оба типа этих багов.

Если у вас проблема поиска пути (pathfinding) и управляемый компьютером персонаж не может найти путь по карте, у вас есть три возможные объяснения:

1). Невидимая стена преграждает ему путь.

2). Дыра в карте обрывает скрипт.

3). Ошибка ИИ.

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

Когда ИИ работает, поведение неигрового персонажа (non-player character (NPC) behavior) должно заставлять вас поверить, что это реальный человек играет с вами в игру. Когда есть проблема с ИИ — вы точно понимаете, что персонаж управляется компьютером. Недостаточно просто пожаловаться на этот баг. Вам необходимо объяснить разработчикам, почему определенное поведение (например, утыкание в неправильную дверь лифта) выбивается из игры. Если вы создадите точное описание, разработчики оценят ваш баг с полной серьезностью и попытаются его устранить. Поведение NPC также может иметь эффект на баланс. Если вы полагаетесь на свою команду NPC в убийстве толп и толп врагов — плохая их эффективность может сделать игру слишком сложной. С другой стороны, чрезмерные усердия (или слишком высокая квалификация) помощников NPC могут сделать игру слишком простой.

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

Поиск физических багов является частью ежедневной работы тестировщика с тех пор, как физический API (application programming interfaces) был недавно добавлен в игровые движки и инструменты. Физика в игре — это целая подсистема, одна из мощнейших. И геймплей, и анимация напрямую влияют на физический код, так как они принимают участие в физической подсистеме движка. Знание о том, как выявлять физический баги — очень желательный навык. Примеры физических багов — это разрушаемость и динамическое поведение. Давайте поближе рассмотрим оба вида багов.

Часто встречающаяся особенность современных игр — это разрушаемое (breakable) окружение. В Gears of War это называется «разрушаемое укрытие” и и позволяет игрокам до определенной степени защищаться от вражеского огня. Когда же урон слишком мощный, укрытие разлетается на кусочки (так называемые “разрушаемые объекты»). Теперь представьте, что объекты совершенно не разрушаются, или делают это, но осколки зависают где-то в воздухе. Это два вида багов, которые могут возникнуть при разрушении.

Объекты не обязательно должны быть разрушаемыми, чтобы вести себя «странно» с точки зрения физики. В Quake 4 поддельная физика использовалась для того, чтобы двигать металлические или деревянные ящики. Они постоянно находились под напряжением, результатом которого стало неправильное динамическое поведение. Например, заставьте своего персонажа врезаться в металлический ящик на большой скорости. Ящик должен двигаться определенное количество времени, а затем остановиться. Но в Quake 4 ящик может временами продолжить двигаться. Это хороший признак того, что кое-что в физическом коде неправильно — настоящая это физика или поддельная.

Физические баги будут играть гораздо большую роль в ближайшем будущем. Новейшие игры, такие как Fracture от Lucas Arts, используют физику на полную. Франшиза Half-Life практически полагается на нее. Хорошее понимание физики старшей школьной программы и немного внимания к деталям необходимы, чтобы замечать физические баги — и направлять разработчиков в правильном направлении.

Стабильность (Stability) отсылает нас к предсказуемости кода — соответствует ли он намерениям команды разработчиков. Примеры багов стабильности включают в себя зависания, падения и баги загрузки. Давайте взглянем поближе на эти 3 примера.

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

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

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

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

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

Когда игру делают, разработчики ставят себе цель на количество кадров в секунду (фреймрейт, framerate) — какой он должен быть в игре. В первые дни существования PlayStation 3, разработчики нацеливались на 30 кадров в секунду (FPS), в то время, как игры на Xbox360 запускались на 60 кадрах. Низкий фреймрейт — это тот, что находится на значении ниже того, на которое нацелились. Так что если вы нацелились на 30 кадров в секунду, а FPS падает ниже 20 — это низкоприоритетный баг фреймрейта. Основную часть времени разработчики не беспокоятся о производительности, пока не наступит время перед бетой. Причина в том, что необходимо создать игру, а уже затем проверять производительность. Проблема такого подхода в том, что серьезные проблемы с производительностью могут быть слишком сложными, чтобы починить их в последние 2 месяца производственного процесса. Вот почему некоторые студии придерживаются прицельного фреймрейта во время производства — чтобы быть уверенными, что проблемы с производительностью будут замечены как можно раньше.

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

Требования игр на ПК включают минимальные системные требования (minimum requirements machine, min spec) — наименьшие характеристики компьютера, на котором игра будет работать. Баг минимальных системных требований создается, когда игра не работает корректно на таком компьютере. Это прописано в договорных обязательствах. Когда разработчик поставляет игру издателю — он должен быть уверен, что игра идет на минимальной системной конфигурации. Это единственный способ добраться до миллионов потенциальных покупателей, которые не обладают мощной игровой системой. Чаще всего, компьютеры минимальной конфигурации обладают GPU и CPU нижнего уровня, малым количеством памяти. Самым неудачливым тестировщикам приходится играть на компьютерах с минимальной конфигурацией — с фреймрейтом в 12 кадров в Quake!

Баг времени установки (Installation Time) — это тип бага производительности потому, что это скорее всего связан с проблемой в самом установщике. Размеры игр растут, разработчики продвинулись от дискет на 1,44Мб до blu-ray дисков на 50Гб. Играм всегда необходимо время на установку, обычно около 20 минут. Однако, если игра устанавливается дольше этого времени — что-то случилось. Это не нормальный опыт — долгое время установки.

Баги производительности легче всего заметить, но сложнее всего устранить. Вы не можете не отчитаться, если игра идет на 15 кадрах в секунду. Решение этих проблем — совсем другая история. Это трудное время для разработчиков — когда они пытаются понять, как их устранить. Если проблема достаточно серьезная, ее могут вообще никогда не устранить.

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

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

Баги совместимости с видеокартой (Video Card) были очень частыми во время тестирования Quake 4. Драйвера ATI постоянно заставляли игру падать на рабочий стол. В команде тестирования различные тестировщики имели компьютеры с видеокартами Nvidia и ATI, чтобы поймать баги на них. Держите в голове, что только поддерживаемое железо тестируется. Как правило, встроенные видеокарты, как Intel GMA3100, не поддерживаются — так что не ожидайте их увидеть в лаборатории тестирования.

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

Ошибка операционной системы (Operating System) довольно частое явление. Всегда будьте уверены, что пишите о проблемах с поддерживаемой операционной системой. Часто можно увидеть, как бетатестеры жалуются на проблемы с совместимостью с Vista 64, тогда как она просто не поддерживается. Хотя временами операционная система поддерживается, но игра все же не запускается — это совершенно точно баг.

Всегда убеждайся в том, что стандарты, такие как USB и bluetooth поддерживаются. Если вы слышите моно вместо стерео, когда используете беспроводную гарнитуру — проблема может быть механической (с динамиком) или с проблемой совместимости Bluetooth. Перед тем как написать про этот баг — проверьте это устройство на другом компьютере или консоли.

Проблемы совместимости чаще всего ассоциируются с видеокартами, контроллерами, операционной системой или стандартами. Теперь двинемся к «крутым парням» — сетевым багам.

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

Ошибка соединения (Failed Connection) — это классический баг Xbox Live. Сообщение на экране может быть разным (например «connection failed,” “failed to connect,” “no connection,” “dropped connection”), но смысл всегда один и тот же: ваша консоль “не видит” или “не слышит” другие консоли. Частота появления этого бага может варьироваться от “всегда повторяется” до “временами возникает» — это важная информация, так что запишите ее обязательно.

Скажем, консоль смогла присоединиться, но у вас все равно обрывается соединение (Dropped Connection ). В этом и есть разница с предыдущим багом. Конечно же, если вы сыграли несколько сессий без проблем с соединением, и оно неожиданно оборвалось — вы без проблем идентифицируете этот баг. Не так очевидно идентифицировать, когда вы встречаетесь с тем, что соединение обрывается сразу же после подключения. Кто-то может это описать как «не подсоединяется», но вы теперь знаете как это описать правильнее.

Баг непринятого приглашения (Unaccepted Invitation) случается только в играх, где есть приглашения в игру. Скажем, вы попросили другого тестировщика пригласить вас в игру. Вы видите приглашение и нажимаете «Принять». Однако в итоге вы остаетесь на главном экране, а не присоединились к игре своего коллеги. Эти ошибки могут стать очень каверзными по мере того, как производство приближается к бета-версии — поскольку большинство руководителей тестирования не обращают на них внимания, так как они не являются частью самой игры. Всегда помни про эти неработающие приглашения в игру.

Все знакомы с лагами (задержками, lags). Это раздражающее ощущение, когда вы стреляете из своего оружия, а попадание засчитывается только через полсекунды. Лаг — это симптом более серьезных сетевых проблем, таких как потеря пакетов или чрезмерное использование полосы пропускания. Важно очень подробно написать отчет, когда вы столкнетесь с лагом:

Всегда такая задержка?

Когда начинается?

Пропадает ли он при начале новой игры?

Используете ли вы фаервол?

Если вы не видите другого игрока или NPC, вы познакомились с багом «невидимый игрок» (invisible player) — признаком серьезных сетевых проблем. Баг невидимого игрока может оказаться одним из самых больших ваших испытаний, потому что его часто сложно повторить или отследить. Представьте себе необходимость проверки всех игроков в каждой сессии, чтобы убедиться, что все они видны! Как и лаг, баг невидимого игрока следует задокументировать подробно. Запишите все необычное и сравните свои заметки с коллегами. Не так уж редко можно встретить игру в продаже с такими типами багов — которые починят только патчем через пару месяцев после старта продаж.

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

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

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

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

Мы упоминали гейм дизайн документ (game design document (GDD)) в главе 3. Как тестировщик, вы вероятнее всего не увидите актуальный ГДД. Лиды тестировщиков возможно, чтобы они познакомились с игрой. ГДД описывает все креативные аспекты игры и работает на все команды проекта (включая дизайн, арт, технические и звуковые отделы). Типичный ГДД содержит историю/персонажа, геймплей, интерфейс и описание уровней.

Там, где ГДД описывает словами то, чего должна достигнуть игра, руководство по стилю (art style guide) (временами называемое «библией арта” («art bible»), которую необходимо четко отделять от “игровой библии», описанной в следующем разделе) иллюстрирует ее изображениями и референсами. Если ГДД упоминает церковь в маленьком французском городке, руководство по стилю содержит несколько картинок привлекательных европейских церквей. В гоночных играх руководство по стилю включает описание всех машин, включенных в игру, с картинками и спецификациями. В FPS оно иллюстрирует каждый класс оружия, который может использоваться.

Библия игры (game bible) — это документ, составленный QA-менеджером или ведущим тестировщиком. Его цель — служить источником знаний для новых сотрудников. Она содержит названия карт, аббревиатуры, как уровень серьезности классифицируется на проекте и основные правила. В настоящее время, игровые библии часто загружаются на Wiki, где становятся «живой документацией».

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

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

Вскоре после начала работы над новым проектом, лид тестировщиков начинает создавать «главу всех чек-листов» — тест план (test plan). Этот документ содержит все чек-листы, содержащиеся в игре. Тест планы, используемые QA, обычно изначально предоставляются командой производственного тестирования, потому как производственная команда уже работает над игрой несколько месяцев, когда QA присоединяется к делу. Тест план должен содержать следующие разделы:

Когда создается игра, разработчикам необходимы инструменты для отслеживания задач, а также багов. Мы называем последние «баг трекеры» (bug trackers). Давайте взглянем поближе на три инструмента, которые стали стандартом индустрии: DevTrack, Bugzilla и TestTrack Pro.

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

Bugzilla — это основанная на вебе багтрекинговая система с открытым исходным кодом, разработанная Mozilla Foundation в 1998. Bugzilla в чем-то похожа на DevTrack, но там где DevTrack может быть немного дороговат (как проприетарное, платное программное обеспечение), Bugzilla остается абсолютно бесплатна в использовании. Это делает ее хорошей низкобюджетной заменой DevTrack — с тем преимуществом, что Bugzilla также довольно хорошо известна.

Разработанная Seapine Software, TestTrack Pro — это профессиональная багтрекинговая программа, широко используемая в игровой разработке. Также как и DevTrack, TestTrack Pro используется разработчиками и издателями, такими как 2K Games, Atari, Epic Games, and Sega. Некоторые находят эту программу исключительно удобной, поскольку она позволяет лидам и их помощникам получать широчайший набор отчетов.

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

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

Вот короткий список шагов для внесения бага в DevTrack:

1. Зайдите в свой аккаунт, введя логин и пароль.

2. Выберите подходящий проект.

3. Поищите похожие баги. Этот шаг необходим. Надо быть уверенным, что вносите что-то новое.

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

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

6. Убедитесь, что ваш баг сохранился в системе.

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

«Открытый» (Open) баг — это тот, который был недавно внесен тестировщиком. Он остается открытым, пока не будет назначен на лида.

«Назначенный» (Assigned) баг — за который отвечает разработчик. Баг назначен на разработчика лидом определенной команды.

Когда ответственный разработчик починит баг, он меняет статус на «решено” (resolved) или “починен» (fixed).

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

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

Закрытый (closed) баг — тот, что был исправлен. Здесь его путь заканчивается.

Не будет починен (Will Not Fix (WNF)) означает, что ваш баг не настолько важен, чтобы его починить. Это обычно случай низкоприоритетных багов. Разработчики просто не имеют достаточно времени, чтобы починить все, что было отправлено — и фокусируются на багах среднего и высокого приоритета.

Описанный ранее в этой главе "Не баг"(Not a Bug (NAB)) — это незабываемый опыт. Если вы видите NAB в своем статусе — разработчики не считают, что вы нашли баг. Чтобы подлить масла в огонь, они обычно приписывают “так задумано" в разделе заметок. Слишком много NAB означают, что вы делаете свою работу не очень хорошо.

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

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

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