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

• Дата и время билда (или номер билда);

• Краткое описание;

• Класс;

• Приоритет;

• Категория;

• Описание;

• Локация в игре;

• Воспроизводимость;

• Шаги для воспроизведения ошибки;

• Задействованный скрипт;

• Ответственное лицо;

• Статус;

• Приложения;

• Примечания;

• Примечания к исправлению.

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

Номер бага

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

Дата и время обнаружения

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

Дата и время билда (или номер билда)

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

Краткое описание

Этот столбец должен включать очень краткое описание ошибки – затем оно будет служить ее названием.

Класс

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

• Блокер (Showstopper)

☉ Ошибка, которая должна быть немедленно исправлена, поскольку она в какой-то момент препятствует прохождению игры – следовательно, и тестированию[164].

• Класс А

☉ Серьезная ошибка, которая существенно мешает функционированию игры и должна быть исправлена[165].

• Класс Б

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

• Класс В

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

Комментарий

☉ Этот класс багов используется тестировщиками для отправки отзывов или идей разработчикам. Может стать ценным каналом связи между QA-отделом и разработчиками игры.

Приоритет

Внутри каждого класса можно также назначить приоритет. Баг «B1» нуждается в срочном исправлении, но не таком срочном, как баг «A3», в то время как баг «B3», вероятно, может подождать.

Категория

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

• Программирование;

• 2D-графика;

• 3D-графика;

• Гейм-дизайн;

• Тексты;

• Анимация;

• Аудио;

• Музыка;

• Визуальные эффекты;

• Тактильная отдача;

• Пользовательский интерфейс;

• Субтитры;

• Другое.

Описание

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

Локация в игре

Тем, кто будет исправлять ошибку, не помешает точно знать, где в игре баг. Это особенно важно для ошибок, которые случаются только в одном конкретном месте в игре. Лучше всего записать 2D- или 3D-координаты места из игрового движка или сделать скриншоты.

Воспроизводимость

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

• всегда;

• иногда;

• редко;

• единожды.

Шаги для воспроизведения ошибки

Это подробное описание шагов, которые необходимо сделать, чтобы воспроизвести ошибку. Этот раздел также уменьшает объем раздела «Описание».

Задействованный скрипт[166]

Если тестировщики могут сказать, какой скрипт (или другой фрагмент кода) вызвал проблему, стоит это записать. Отладочные сообщения часто показывают, где в коде произошла ошибка.

Ответственное лицо

В этом разделе назначается ответственный за исправление бага.

Статус

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

• Новый

☉ Статус бага при его первом обнаружении.

• Известный

☉ Разработчик дает ему этот статус, когда получает баг, над исправлением которого он будет работать.

• Запрашивается информация

☉ Если человеку, который собирается исправить баг, требуется дополнительная информация для его исправления, он меняет его статус на этот, и ошибка передается обратно менеджеру QA-отдела или тому, кто обнаружил баг.

• Исправлен