Игровая разработка без боли и кранчей. Как выжить в игровой индустрии и сохранить вдохновение - Ричард Лемаршан
Приоритет
Внутри каждого класса можно также назначить приоритет. Баг «B1» нуждается в срочном исправлении, но не таком срочном, как баг «A3», в то время как баг «B3», вероятно, может подождать.
Категория
Если можно отнести баг к какой-то категории, то лучше отсортировать ошибки по отделам, которые смогут затем их устранить – это также поможет быстрее назначить ответственного за исправление. Можно сортировать по следующим категориям:
• Программирование;
• 2D-графика;
• 3D-графика;
• Гейм-дизайн;
• Тексты;
• Анимация;
• Аудио;
• Музыка;
• Визуальные эффекты;
• Тактильная отдача;
• Пользовательский интерфейс;
• Субтитры;
• Другое.
Описание
Здесь баг описывается подробнее, чем в кратком описании. Хорошее описание багов – само по себе искусство. Лучше всего использовать ясный, лаконичный язык, чтобы описать, что ожидал тестировщик и что произошло на самом деле. Не включайте информацию о том, где возникает ошибка, как часто или как ее воспроизвести – эта информация будет в других разделах.
Локация в игре
Тем, кто будет исправлять ошибку, не помешает точно знать, где в игре баг. Это особенно важно для ошибок, которые случаются только в одном конкретном месте в игре. Лучше всего записать 2D- или 3D-координаты места из игрового движка или сделать скриншоты.
Воспроизводимость
Некоторые ошибки возникают стабильно каждый раз, когда вы пытаетесь их воспроизвести, другие случаются только иногда, а некоторые можно увидеть только один раз. Вы можете использовать эти категории для описания воспроизводимости ошибки:
• всегда;
• иногда;
• редко;
• единожды.
Шаги для воспроизведения ошибки
Это подробное описание шагов, которые необходимо сделать, чтобы воспроизвести ошибку. Этот раздел также уменьшает объем раздела «Описание».
Задействованный скрипт[166]
Если тестировщики могут сказать, какой скрипт (или другой фрагмент кода) вызвал проблему, стоит это записать. Отладочные сообщения часто показывают, где в коде произошла ошибка.
Ответственное лицо
В этом разделе назначается ответственный за исправление бага.
Статус
Каждому багу при его первом обнаружении присваивается статус «Новый». Статус бага будет меняться в течение всего срока его существования по мере того, как он будет передаваться между QA-отделом и другими членами команды разработчиков, а также по мере починки.
• Новый
☉ Статус бага при его первом обнаружении.
• Известный
☉ Разработчик дает ему этот статус, когда получает баг, над исправлением которого он будет работать.
• Запрашивается информация
☉ Если человеку, который собирается исправить баг, требуется дополнительная информация для его исправления, он меняет его статус на этот, и ошибка передается обратно менеджеру QA-отдела или тому, кто обнаружил баг.
• Исправлен
☉ Когда разработчик думает, что исправил баг, он помечает его как «Исправлен» и передает обратно в QA-отдел для проверки, действительно ли баг устранен.
• Невозможно воспроизвести
☉ Если разработчик не может воспроизвести баг, он меняет его статус и передает обратно в QA-отдел для проверки. Отдел обеспечения качества проверяет, воспроизводится ли все еще этот баг.
• Дубликат
☉ Багу присваивается этот статус, если он уже есть в базе данных с другим номером.
• Не исправлен
☉ Если во время проверки баг, помеченный как «Исправлен», на самом деле не был устранен, он помечается как «Не исправлен» и возвращается разработчику, который над ним работал, или его руководителю.
• Подтвержден
☉ Если во время проверки баг, помеченный как «Исправлен», действительно оказывается устранен, он получает статус «Подтвержден» и отправляется на большое райское кладбище ошибок.
• Закрыт (нельзя исправить)
☉ Иногда баг по той или иной причине не может быть исправлен, и тогда он помечается таким образом. В большинстве команд только очень высокопоставленные члены команды могут закрывать баги.
• Закрыт (отклонен)
☉ Иногда члены команды решают, что баг по какой-то причине не надо исправлять – возможно, это займет слишком много времени, или он не такой уж серьезный, или это вообще не баг, а фича. В таком случае ошибка получает этот статус. Опять же, обычно это решение принимается только старшими членами команды.
• Повторно открыт
☉ Иногда баг, который был закрыт, снова открывается, и тогда он помечается таким образом.
Приложения
Зачастую к отчету стоит добавить скриншоты или видеоролики, иллюстрирующие баг.
Примечания
Раздел примечаний к багу – это хороший способ передавать информацию между QA-отделом и командой разработчиков. Например, когда запрашивается дополнительная информация о баге или когда баг помечен как «Не исправлен».
Примечания к исправлению
Если есть что-то особенное в том, как был исправлен баг, или если баг по какой-либо причине закрыт, надо написать об этом в этом
