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

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

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

Как мы уже много раз упоминали: Тестирование видеоигр очень сильно отличается от простой игры в них. Если вы и правда хотите обнаружить баги, вам необходимо делать это со всем старанием. Просто играя в игру, вы со временем встретитесь с некоторыми “находками” спустя какое-то время — но вы просто наткнетесь на них. Чистая случайность (а не техника) будет определять вашу производительность. Если вы игровой тестировщик — вам хотелось бы находить баги по собственной воле. Для этого вам необходимо вооружиться всеми навыками тестирования.

Как уже обсуждалось в Главе 4, баги — это изъяны программного обеспечения, которые могут быть заметны игрокам. Если баг существует, но его невозможно найти — это абсолютно то же самое, что его нет. Следовательно, вы способны только найти баги, которые проявляют себя визуально, звуком или в геймплее.

Если вы взглянете на различные игровые жанры, станет понятнее, что баги специфичны для каждого из них. Более того, техники, которые могут использоваться для поиска багов в FPS, могут иметь огромное различие с техниками, используемыми в симуляторах. Хотя вам необходимо проверять абсолютно всё, чтобы выполнить хорошо работу тестировщика, некоторые жанры имеют “слабые места”, которые всегда должны получать здоровую дозу внимания.

Один из старейших игровых жанров, 2D платформеры, начали свое существование на игровых автоматах в поздних 1970-х и невероятно продвинулись с Super Mario Bros. Когда вы тестируете платформеры, вы должны сфокусироваться на геймплее. Поскольку эти игры довольно просты (даже если их механика состоит в перемотке времени, как в Braid, они все равно относятся к платформерам), визуальные и звуковые ошибки будут устранены изначально — в то время как недостаточно точное управление персонажем сложнее заметить. Вам также стоит убедиться, что поведение врага осмысленно. Ошибки искусственного интеллекта (ИИ) легко проскальзывают, заставляя врагов вести себя немного “странно”.

Как только платформеры перешли к трехмерному пространству — комплексность каждой игры взлетела до небес. Основные проблемы 3D платформеров — управление персонажем, графика и камера. (Если вы когда-либо играли в Conker: Live and Reloaded — вы знаете, что мы имеем в виду.) Управление персонажем — основа 3D платформеров, так что уделите ему достаточно внимания. По аналогии с тем, как 3D графика стала экспоненциально более сложной по сравнению со старыми 2D платформерами, увеличилось и количество визуальных багов, таких как z-fighting, пропавшие текстуры и тиринг экрана.

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

Хотя большинство могут подумать, что жанр shoot ’em up умер, правда в том, что он все еще имеет хардкорную фан базу. Ikaruga продалась чрезвычайно хорошо в Xbox Live Arcade. Ахиллесова пята shoot ’em up в их сложности и управлении персонажем. С тех пор как жанр ассоциируется с хардкорными игроками, довольно просто просчитаться и сделать игру, которой не удастся насладиться. Вам всегда необходимо отслеживать уровень сложности на различных настройках — easy, medium, hard и “insane”. Вам необходимо удостовериться, что игра отлично настроена в этих режимах, иначе она провалится.

Управление персонажем — тоже проблема. Хотя его легко внедрить, важно убедиться, что скорость транспорта корректно воспринимается, а границы экрана хорошо сочетаются с геймплеем остальной игры. Это также включает в себя проверку столкновений (collision detection). Здесь не должно быть никаких недоработок — shoot ’em up живут за счет механик стрельбы и управления персонажем.

Одиночные шутеры от первого лица (Single-player first-person shooters (FPS)) всегда сложны. Массивные уровни, сотни врагов на экране одновременно и сверкающая графика — не только желательны, но и необходимы. Хотя очень много в FPS может пойти не так, ощущение оружия и левел дизайн могут быть наиболее больными их местами. “Ощущение оружия” включает в себя ощущение веса и другие необходимые аспекты оружия, такие как его внешний вид, стрельба и звук. Вам никогда не удастся починить плохой дизайн, но вы можете убедиться, что на хороший дизайн не влияют баги. В Quake 4, Луис смог “защитить” ручной пулемет от бага искаженного звука, внимательно и долго уделяя ему внимание. Помните: всегда уделяйте внимание оружию в FPS больше, чем чему-либо.

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

Многопользовательские шутеры от первого лица (Multiplayer first-person shooters (FPS)) отличаются от одиночных разнообразными проблемами с сетевым подключением. Если вы помните времена онлайн игр по 56-килобитному модему, вы должны согласиться, что важнейшей проблемой является задержка (lag, лаг) — время между нажатием на курок и реальной стрельбой на экране. С тех пор как сетевые соединения стали широкополосными, лаги перестали быть убийцей сетевой игры — но проблема все еще существует. Когда тестируете многопользовательские FPS, обращайте внимание на любые проблемы с соединением. Задержки должны оставаться минимальными и игроки не должны постоянно отключаться (известная проблема “dropped connection”).

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

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

Также важно уделить максимальное влияние сохранению достигнутого игроком. В таких играх как Forza Motorsport и Gran Turismo, игроки могут проводить месяцы в одиночной части. Если что-то случится с сохранением и прогресс потеряется — это подтолкнет бросить игру. Потерять гараж с 30 автомобилями (или что-то подобное) мы не пожелаем и своему врагу.

И последняя область, которая требует внимания, это производительность. Гоночные игры быстрые. Игроки не выбирают Lamborghini Murciélagos потому, что она неплохо выглядит. Если у вас есть 600-сильная тачка на треке в игре, запущенной при 20 кадрах в секунду — у вас проблема. 30 кадров в секунду — совершенный минимум для гоночных игр. В идеале она должна работать при 60 кадрах в секунду. Единственный способ убедиться что фреймрейт адекватный — постоянно за ним следить. Если вы не заметите проблему до поздней стадии производства — разработчики, возможно, не смогут починить ее к запуску игры.

Для многих файтинги (fighting) являются их страстью с тех времен, как Street Fighter 2: The World Warriors от Capcom появился в соседнем зале игровых автоматов. Другие играли в Virtua Fighter от Sega, когда он вышел в 1993 и дал жизнь трехмерным файтингам. Бесспорно, файтинги захватили наше внимание, потому что позволяли отмутузить друзей на экране. Файтинги целиком построены на скорости отклика. Не самая обязательная в других играх (таких как пошаговые стратегии) моментальная отдача, требуется файтингам. Если вы ударяете кулаком — вы должны немедленно увидеть это на экране. Если вы тестируете файтинг — всегда уделяйте внимание времени реакции. (Если ваша игра включает онлайн, это становится еще более важно, потому что онлайн игры страдают от задержек).

Следующая важная проблема файтингов — это баланс. Когда игра несбалансирована — один персонаж сильнее другого до такой степени, что это влияет на матчи. Ранние файтинги страдали от этого. Одной из причин, по которой время от времени появлялись новые “издания”, была балансировка оригинального, несбалансированного геймплея. Это была причина появления Street Fighter 2: Champion Edition и множества других. Теперь консоли подключены к интернету 24/7 и немного проще править баги. И все же, плохой баланс может уронить стартовые продажи в связи с плохими отзывами — так что вам необходимо держать планку. Лучший способ выявить проблемы с балансом — всегда выбирать различных персонажей и делать заметки об их преимуществах и слабостях. Все, что не “так задумано” — точно баг.

Адвенчуры (Adventures, квесты) живут за счет их головоломок (puzzles). Прекрасная графика и затягивающий саундтрек не спасут, если одна единственная головоломка сломана. Потому что адвенчуры линейны: одна сломанная головоломка может не дать возможности игроку продвинуться по игре. Вот почему тестировщикам необходимо провести многочисленные прохождения, чтобы абсолютно убедиться, что прогресс никогда не прерывается. Особые слабости адвенчур — управление персонажем и камерой. Когда жанр перешел в 3D с Alone in the Dark, исследовать окружение неожиданно стало испытанием. Управлять персонажем с клавиатуры уже было достаточно трудным, но эти первые попытки в 3D заставляли иметь дело с “кинематографической” камерой, которая была неуклюжей и мешала игроку.

Если вы вдруг попадете на работу по тестированию адвенчуры, сфокусируйтесь на управлении персонажем и камерой. Оно должно быть очевидным, чтобы не мешать остальному игровому процессу. Некоторые считают, что адвенчуры никогда не оправятся от перехода в 3D. По факту, можем винить в этом QA. Если бы разработчики уделяли больше внимания проблемам управления, возможно игры вроде Fade to Black (сиквел Flashback) не были бы такими разочаровывающими — и жанр сейчас был бы в лучшей форме.

Action-adventure (приключенческие игры) часто располагают бок о бок с шутерами от третьего лица (third-person shooter (TPS)), потому что они оба используют вид от третьего лица. Однако вы легко найдете отличия при сравнении Gears of War и Tomb Raider. В то время как Gears of War сильно фокусируется на аспекте стрельбы, Tomb Raider полагается на исследование и решение головоломок. Так что если проблема с прицеливанием может “убить” TPS, с приключенческой игрой это может случиться из-за управления и головоломок.

Когда вы тестируете игру жанра action-adventure, уделите должное внимание каждой головоломке. Как и в чистых адвенчурах, головоломки могут прервать прогресс, это известно под названием progression break. Учитывая, что движение может быть разнообразным (поднятие по лестницам, прыжки по платформам и исполнение акробатических приемов), точность — это ключ. Потеря контроля в action-adventure гарантирует плохой результат.

Ролевые игры (Role-playing games (RPG) невероятно комплексные. От ранних игр на Commodore Amiga до графически насыщенных ПК игр, тестировать эти массивные игры — это всегда испытание. Если вы возьметесь за RPG, приготовьтесь к невероятной нагрузке. Можете называть это уровнем сложности “insane” игрового тестирования. Каждый аспект необходимо протестировать самостоятельно, а затем еще раз — в паре с чем-либо еще. Прохождение может занимать 80-120 часов вместо обычных 10-20. Альтернативные пути должны работать точно также, как и “основные” пути. Все оружие должно быть проверено против всех врагов или NPC. Вкратце — RPG может быть очень сложным — вам необходимо иметь большую и способную команду. (Вы также можете положиться на технику автотестов, обсуждаемую в главе 6.)

Игры симуляторы (Simulation games) пытаются «порезать» реальность на небольшие кусочки, которыми мы сможем поуправлять. В некоторых гоночных играх динамика транспорта честно воспроизведена, но не изменения погоды. The Sims пробуют симулировать человеческие отношения, но разумно избегают жизненных проблем.

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

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

Головоломки (Puzzle) относительно легко тестировать по сравнению с другими, более размашистыми жанрами. Даже более усложненные игры-головоломки, такие как Lumines, не должны быть такими уж запутанными. В головоломках вам необходимо сосредоточить внимание на всем, что имеет отношение к программированию. Уделите внимание обнаружению столкновений (collision detection), системе подсчета очков (scoring), точности управления (control precision) и динамике геймплея (gameplay dynamics). Даже если элемент — не “истинный” баг (такой как не впечатляющий бонус), о нем необходимо отчитаться, как о предположении. Точность управления чрезвычайно важна. Нет ничего хуже, чем разместить неверно часть пазла из-за неточного управления.

Игры казино (casino) теряют популярность среди консольных игроков, но все еще привлекают казуальных игроков на игровых веб-сайтах. (Xbox Live также привлекает внимание казуальных игроков к традиционным играм казино, таким как покер.) Как и головоломки, игры казино довольно просто тестировать. В азартных играх настоящих казино правила часто не меняются веками, так что видеоигры по ним не могут отклоняться в сторону. Для примера, даже если игра назовет себя «Специальный блэкджек», она не может базироваться на 22 очках вместо традиционных 21.

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

Survival-Horror (SH) — это производная самых первых 3D адвенчур. Alone in the Dark обычно классифицируется как action-adventure. Но также она ответственна за появление SH игр. Более свежие франшизы — это Resident Evil и Silent Hill. В отличие от большинства игровых жанров, SH основывается больше на истории, чем на геймплейных элементах. Если взглянуть с этой стороны — они больше склоняются к фильмам, чем традиционные игровые жанры. Большинство SH игр имеет те же геймплейные элементы, что и игры жанра action-adventure.

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

Massively Multiplayer Online Games (MMOG или MMO) стали популярны в последнее десятилетие. World of Warcraft и его 11 миллионов подписчиков популяризировали MMO на весь мир. Если вы получили работу над MMO, поздравляем: это настоящий "Эверест" тестирования. (Вы можете попробовать его на вкус — принять участие в бета тестировании, проводимом почти всеми разработчиками MMO.) Не только RPG сложно тестировать. Тестирование MMO — все еще “Дикий запад” — где не действуют законы, а любая ошибка может стать последней. Вы будете работать с огромной командой, чтобы иметь хоть какую-то надежду отыскать наиболее важные баги. Также необходимы огромные усилия по бета тестированию — и с закрытой, и с открытой бетой.

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

Многие люди думают, что тестировать игры — значит весело проводить время. Вы, вероятно, согласитесь — мы уже развенчали это заблуждение! А вот что мало кто предполагал — тестирование предполагает необходимость много писать. И те, кто плохо пишут — становятся ужасными тестировщиками. Баг репорт (отчет о баге) — это текстовый документ, который описывает разработчику как баг в точности воспроизводится. Чем более детален баг репорт — тем легче разработчику его починить. Давайте взглянем из чего состоит баг репорт.

Заголовки багов должны быть абсолютно ясными и точными — словно заголовки газет. Хорошее практическое правило — следовать пяти “W” журналистики: кто (who), что (what), когда (when), где (where) и почему (why).

А: Падение сквозь землю

B: Дробовики — отстой

C: Не загружается уровень

A: Не сказано «где» это происходит

B: Это мнение (еще и незавершенное)

C: Не уточнено какой уровень

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

B: Дробовик союзников слабоват в сравнении с дробовиком противников

C: Не загружается уровень «Poisson» в режиме «Захват флага»

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

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

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

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

C: Каждый раз, когда я пробую загрузить уровень “Poisson” — что-то происходит и экран темнеет.

A: Недостает деталей, использование ужасных аббревиатур («перс» вместо «персонажа») и излишние выражения.

B: Остается очень субъективным. Необходимо немного деталей вместо факта «стреляю с очень близкого расстояния».

C: Добавилось только название карты. Все еще недостаточно информации.

A: При пересечении ангара в конце уровня “Enemy Fields”, я неожиданно провалился в дыру в карте. Если смотреть на вход — дыра в метре слева от инопланетного реактивного двигателя. Я продолжал падать до тех пор, пока персонаж не умер, и меня перекинуло к загрузочному экрану.

B: Дробовик союзников слабоват в сравнении с дробовиком противников. Если я встаю в одном метре от вражеского солдата и стреляю — мне необходимо 2 или 3 выстрела для убийства. Если же он стреляет в меня с этого же расстояния — он может убить меня с одного выстрела. Другие тестировщики отчитывались о подобных проблемах около недели назад.

C: Уровень «Poisson» не загружается в 3 случаях из 10. Это случается чаще в режиме «Захват флага». У нас была команда из 16 игроков в лобби, заполненная полностью, когда два других ПК тоже зависли на черном экране (мы зашли в игру примерно в одно и то же время).

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

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

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

A:
1. Идти к выходу.
2. Умереть.

B:
1. Загрузить игру.
2. Экипировать дробовик.
3. Стрельнуть в кого-нибудь.
4. Ничего не произошло

C:
1. Загрузить игру.
2. Выбрать мультиплеер.
3. Выбрать загрузку «Poisson»

A: Слишком упрощенно. Звучит скорее как шутка.

B: Попытка описать проблему, но провал в объяснении порядка событий. Главное случается между 3 и 4 шагами!

C: Не добавляет новой информации. Разработчик остается в неведении.

A:
1. Загрузите уровень «Enemy Fields».
2. Идите по уровню по обычному пути.
3. Близко к окончанию уровня вы увидите инопланетный ракетный двигатель.
4. Расположите игрока в одном метре слева от двигателя.
5. Вы проваливаетесь через дыру в карте.

B:
1. Загрузите любой многопользовательский уровень.
2. Попросите другого тестировщика зайти на карту.
3. Экипируйте дробовик.
4. Попросите тестировщика также экипировать дробовик.
5. Попросите тестировщика выстрелить вам в грудь с расстояния одного метра. Вы должны умереть с одного выстрела.
6. Когда оживете — выстрелите в тестировщика с той же дистанции. Вам понадобится 2 или 3 выстрела, чтобы убить его персонажа.

C:
1. Загрузите игру.
2. Запустите создание многопользовательского матча на карте «Poisson».
3. Измените режим игры на «Захват флага».
4. Пока вы в лобби — попросите второго тестировщика зайти в игру одновременно с вами.
5. Вы столкнетесь с черным экраном в 3 из 10 случаев.

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

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

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

Повторяемость описывает как часто баг случается. “5 из 5” — это намного более серьезный баг, чем “1 из 5”. Каждый баг репорт должен содержать эту информацию. Большинство баг трекинговых систем имеют поле для указания повторяемости бага. Обычно шкала в 5 или 10 уровней. Цель — дать разработчиком представление о повторяемости бага. Даже если это приблизительная оценка — это все еще полезно. Если для повторяемости нет отдельного поля, не забудьте добавить ее в поле описания.

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

Если вы тестируете игру на ПК — вам всегда необходимо добавлять журнал диагностики DirectX: dxdiag. Это “снимок” компьютера, на котором вы тестируете — он содержит важную информацию о версии драйверов, объеме оперативной памяти (RAM), видеокарте (GPU), объеме видеопамяти (video RAM size) и многом другом. Если вы не прикрепите файл dxdiag — у вас могут быть проблемы!

Как получить доступ к журналу dxdiag:

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

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

Методические рекомендации по баг репорту

Ничто не является таким хорошим доказательством наличия бага для разработчиков, как скриншот. Сделать скриншот на ПК просто:

На консолях это может быть несколько хитрее. Вам необходимо снова зайти в меню разработчика (dev menu) и выбрать «сохранить скриншот» («save screenshot») или «запись экрана» («screen capture»).

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

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

Как только ваш баг репорт готов — он отправляется разработчикам для исправления. Неделей позже он вернется вам. Если вы делаете работу хорошо, лид даст вам большую стопку бумаг с назовет ее “верификацией”. Это ваши баги, которые, предположительно, исправлены. Ваша работа теперь — убедиться, что это действительно так. Мы называем этот процесс верификацией. Ниже основные шаги:

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

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

#qa #тестирование #gameqabook