Как найти дыры в играх

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

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

Что такое баги в игре и как они классифицируются

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

Как классифицируют игровые баги:

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

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

3. Баг локализованной игры. В основном это не переведенный на нужный язык текст или орфографические и/или синтаксические ошибки при переводе слов и т. д.; в общем, проблемы с переводом.

4. Баг производительности. Игровые проблемы с FPS, не связанные с пользователем, — игра работает медленно и лагает на производительных устройствах.

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

6. Технический баг. Нестабильный интернет, отчего игра плохо работает. Или, например, не хочет запускаться в 3G—сети.

7. Баг совместимости. К примеру, игра не запускается на совместимых устройствах.

Но это еще не все. Это была классификация по происхождению бага. Еще они классифицируются по приоритетности и скорости их устранения. В этом случае выделяют три категории:

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

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

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

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

1. Баги, мешающие пользователям игры. В целом влияют на количество игроков, на различные рейтинги и т. д.

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

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

Что такое баги в игре — разобрались, и как их классифицируют — тоже. Остается вопрос: а как вообще появляются эти «недостатки» и от чего зависит их количество в проектах?

От чего зависит количество багов в играх

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

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

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

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

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

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

5. Раннее тестирование. Один баг часто порождает целую цепочку багов, поэтому необходимо качественное тестирование на ранних этапах разработки.

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

1. Сетевой режим RPG-игр. Огромный игровой мир с просто невероятным количеством возможных сценариев при взаимодействии игроков между собой.

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

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

Как искать и находить баги в играх

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

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

Как искать и находить баги в играх, советы:

1. Фокусировка. Важно фокусироваться именно на процессе поиска, а не на процессе игры. Можно даже держать постоянно в голове мысль: «Здесь должен быть баг!»

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

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

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

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

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

7. Думайте. Как ни странно, но мысли по типу: «Почему игры пишутся с багами?», «Почему баги в играх — это то, что считается нормой?», «Что вообще такое баги в играх?» и т. д. помогают развивать собственную философию в этом вопросе. А со временем вы сами будете находить подтверждение своим мыслям и догадкам. И у вас появятся собственный алгоритм и методики поиска.

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

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

Заключение

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

Хотите действительно полезный блог про Denuvo? А пожалуйста.

Ребят, лайфхак по всей котовасии с этой DRM: кидаете на Steam-кошелёк пару косых и покупаете Just Cause 3 (или любую другую игру), качаете по закону через него же, активируете, запускаете, можно и с DLC, правда пока сюжетных не вышло. Выходите из игры, переходите в автономный режим Стима и играетесь сколько влезет, в оффлайне конечно. Потом идёте на сайт Гейбушки, и делаете возврат всего, что купили, а сами в оффлайне продолжаете играться, но главное не забудьте потом, как игру пройдёте в оффлайне же и удалить и Steam, и игру, желательно с концами да трэйными записями. И вуаля — правда я сам только сегодня это мучу, пришли ответы по возврату средств двух из четырёх DLC, но ничего не предвещает беды и по возврату игры.

Х3, сколько эта дыра может длиться. Теоретически, можно играть вообще во всё угодно в день выхода без ожидания кряков, правда нужно быть поаккуратнее. С Origin я мало знаком, поэтому судить пока не берусь, но если и там можно делать возврат средств на сайте, а не через их клиент — та же инструкция. Я не знаю, как работает данная тема с Uplay и проканает ли запуск FC:Primal в оффлайне, так что не торопился бы пока покупать его, до дня релиза. В общем ждём. А лучше конечно левый акк завести для таких вещей, плюс потом всё же можно перевести деньги с одного акка на другой покупкой игры гифтом или типа того, когда склепают кряк, ну или на крайняк даже если забанят, а вы успеете пройти хоть одну игру на халяву — будет не так обидно. Просто барыгам по 100р. за активацию по мне так не камильфо.

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

P.S. Да, это очередные танцы с бубном, но всё работает, как минимум в теории и отчасти уже на практике.

P.P.S. Надеюсь, что администрация будет очень радушна и одобрит существование данного блога, как анастезию в нынешние нелёгкие.

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

UPD-2: Последнее письмо о возвращении средств DLC пришло. Теперь жду ответа о самой игре.

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

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

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

Больше чем один способ найти черную дыру в No Man’s Sky

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

1) Завершить сюжетную линию Атласа

Сюжетная линия Атласа — одна из трех основных сюжетных миссий в No Man’s Sky. Игроки должны посетить интерфейсы Атласа и создать Семена Атласа. Цели даны в игре, и игроки могут следовать им, чтобы завершить квест.

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

2) Поговорите с Поло

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

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

3) Найдите ее случайным образом

Этот метод предпочитает использовать большинство игроков. Им нравится естественное исследование, которое можно провести в No Man’s Sky, и фактор неожиданности, когда вы натыкаетесь на что-то неожиданное в галактике.

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

Что делают черные дыры в No Man’s Sky?

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

Также читайте продолжение истории ниже. Как выполнить задание «Компас» в No Man’s Sky. Куда отправляется Блейдд после того, как линия квестов Ранни заканчивается в Elden Ring? Как найти водные сокровища в No Man’s Sky

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

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

Как найти баги в играх

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

Инструкция

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

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

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

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

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

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

Войти на сайт

или

Забыли пароль?
Еще не зарегистрированы?

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

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

Глава 4. Планируй свою стратегию. Категории багов, инструменты и документация.

Принимающие решения.

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

QA в процессе планирования.

Продюсер.

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

QA менеджер.

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

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

«Дешевая газировка никогда не повредит»: обязанности QA менеджера.

Лид тестировщиков.

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

Обязанности помощника QA лида.

Неформальный лид.

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

Категории багов.

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

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

Визуальные (visual).

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

Clipping.

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

Z-fighting.

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

Screen Tearing.

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

Missing textures.

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

Visible artifacts.

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

Тестирование внутри игрового мира.

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

Аудио.

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

Audio drop.

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

Skipping.

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

Distortion.

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

Звуковое тестирование в игровой музыке и саунд дизайне.

Missing Sound Effect.

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

Volume Level.

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

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

Левелдизайн.

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

Stuck Spot.

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

Sticky Spot.

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

Invisible Wall.

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

Map Hole.

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

Missing Geometry.

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

Тестировщики как «убер» игроки: работа с командой дизайна.

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

Искусственный интеллект.

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

Pathfinding.

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

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

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

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

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

Non-Player Character Behavior.

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

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

Физика.

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

Breakables.

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

Dynamic Behavior.

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

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

Стабильность.

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

Freeze.

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

Crash.

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

Loading.

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

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

Производительность.

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

Frame Rate.

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

Load Time.

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

Minimum Requirements Machine.

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

Installation Time.

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

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

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

Совместимость.

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

Video Card.

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

Controller.

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

Operating System.

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

Standards.

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

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

Сеть.

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

Failed Connection.

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

Dropped Connection.

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

Unaccepted Invitation.

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

Lag.

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

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

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

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

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

Invisible Player.

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

Scoring Error.

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

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

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

Документация.

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

Гейм дизайн документ (ГДД).

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

Важнейшая QA документация.

Руководство по стилю.

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

Библия игры.

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

Чек-листы.

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

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

Тест план.

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

Подходящие для работы инструменты.

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

DevTrack.

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

Bugzilla.

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

TestTrack.

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

Три функции идеальной программы для тестирования.

«Безболезненные» багтрекеры.

Как использовать багтрекеры.

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

До того, как внесете баг.

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

Когда вносите баг.

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

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

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

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

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

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

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

После внесения бага.

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

Open.

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

Assigned.

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

Resolved / Fixed.

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

Verified.

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

Конечные результаты.

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

Closed.

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

Will Not Fix (WNF).

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

Not a Bug (NAB).

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

Duplicate.

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

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

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