Придумываем хороший шаблон для отчёта о багах

Автор оригинала: разработчик из Польши Лежек Горняк (Leszek Górniak). Гейм-дизайнер в Teyon, Unity-девелопер в Bob Games и колумнист в Gamasutra.

Лежек Горняк

«Некоторые виды оружия не выбивают дамаг у пещерного тролля». «Индикатор показывает неправильное количество боеприпасов». «На третьем уровне слетели текстуры».

Каждое из этих предложений похоже на сообщение о баге. Но ни одно из них не предоставляет разработчикам достаточной информации для того, чтобы исправить проблему. Понятное дело, что с примерами я немного преувеличил, но вообще я видел немало таких вот неточных, неполных и просто непонятных жалоб. Я сталкивался с ними и работая тестировщиком в IT-индустрии, и когда стал игровым дизайнером.

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

• заголовок;
• категория;
• важность/приоритет;
• шаги для воспроизведения проблемы;
• что происходит в результате;
• что должно происходить;
• версия программы;
• повторяется ли проблема;
• платформа;
• приложенные файлы.

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

Во-вторых, крайне рекомендую использовать какую-нибудь систему для отслеживания ошибок. Для маленьких проектов вполне достаточно Google Docs. Но если у вас более масштабный проект, то подберите подходящий инструмент, который позволит категоризировать баги, настраивать фильтры и приоритет. Я лично рекомендую Mantis для небольших проектов (10-30 человек) и JIRA для более крупных. Проблему упорядочения отчётов об ошибках вам нужно решить в первую очередь.

Интерфейс JIRA

Теперь пройдёмся по конкретным пунктам шаблона.

Заголовок

Попросите пользователя написать короткий заголовок, который ясно описывает проблему. «На третьем уровне слетели текстуры» — короткий, но недостаточно описательный заголовок. А вот «У небоскрёбов на третьем уровне слетели текстуры материалов» — намного лучше. Из одного заголовка уже ясно всё, что нужно для исправления ошибки (если, конечно, не произошло так, что текстуры слетели не у всех небоскрёбов — тогда понадобится уточнение).

Категория

Каждую проблему можно отнести к какой-то конкретной категории: Интерфейс, Аудио, Диалоги, ИИ и так далее. Включайте эти категории в шаблон — это поможет фильтровать отчёты и распределять задачи по устранению проблем между разными сотрудниками.

Важность/Приоритет

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

«Приоритет» обычно полностью соотносится с важностью проблемы. Хотя есть системы отслеживания ошибок, в которых предусмотрены отдельные фильтры для важности (Незначительная проблема, Серьёзная проблема, Критическая проблема, Препятствие для прохождения) и приоритету (Низкий, Нормальный, Высокий, Срочный).

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

Это САМАЯ ВАЖНАЯ часть отчёта! Без пошагового описания воспроизведения бага программист либо вообще не сможет обнаружить проблему, либо потратит на её воспроизведение чересчур много времени и сил. Описание должно быть одновременно подробным и простым. Ниже я приведу несколько примеров.

Что происходит в результате

Это должен быть ответ на вопрос, что происходит, когда все шаги из предыдущего пункта будут выполнены. Не забывайте, что иногда один-единственный скриншот или лог будет лучше тысячи слов (вот почему важен пункт с Приложенными файлами).

Что должно происходить

Это необязательный пункт. Хотя в некоторых случаях без него отчёт выглядит неполным. Нужно понимать, что именно должно было произойти в случае, если бы бага нет.

Версия программы

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

Повторяется ли проблема

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

Платформа

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

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

Приложенные файлы

Это могут быть:

• скриншоты (они очень полезны, когда отчёт касается среды или пользовательского интерфейса);
• видео (с помощью них, например, можно продемонстрировать странное поведение ИИ);
• логи (нужны, например, в случае крашей).

Но я не сохранялся полтора часа!..

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

Пример 1. Некоторые виды оружия не выбивают дамаг у пещерного тролля

Заголовок: Секира не наносит повреждений пещерному троллю.

Категория: Геймплей.

Важность/Приоритет: Критическая/Высокий.

Шаги для воспроизведения проблемы:

1. Дойти до второго акта.
2. Попасть в Гномье царство.
3. Поговорить с Гхотреком для активации квеста «Пещерный тролль».
4. Перейти в логово тролля.
5. Взять в руки любое оружие типа «Секира».
6. Атаковать тролля и попытаться нанести повреждения.

Что происходит в результате: Пещерный тролль не получает урона.

Что должно происходить: <Очевидный ответ, поэтому можно опустить>

Версия программы: 0.3.1.

Повторяется ли проблема: Да, всегда.

Платформа: Любая.

Приложенные файлы: Нет.

Пример 2. Индикатор показывает неправильное количество боеприпасов

Заголовок: Слишком много боеприпасов отображается в индикаторе после перезарядки.

Категория: Интерфейс (UI/HUD).

Важность/Приоритет: Серьёзная/Высокий.

Шаги для воспроизведения проблемы: 

1. Взять огнестрельное оружие, например на 30 патронов.
2. Выстрелить пять раз.
3. Перезарядить.

Что происходит в результате: Индикатор показывает 55 пуль (25 до перезарядки + объём магазина).

Что должно происходить: Индикатор должен показывать 30 пуль (25 до перезарядки + 5 после).

Версия программы: 0.3.1

Повторяется ли проблема: Да, всегда.

Платформа: Любая.

Приложенные файлы: Скриншоты, на которых видно некорректное количество патронов на индикаторе.

Пример 3. На третьем уровне слетели текстуры

Заголовок: У небоскрёбов на третьем уровне слетели текстуры материалов.

Категория: Среда.

Важность/Приоритет: Незначительная/Нормальный.

Шаги для воспроизведения проблемы: <Очевидный ответ, поэтому можно опустить>

Что происходит в результате: См. скриншот.

Что должно происходить: <Очевидный ответ, поэтому можно опустить>

Версия программы: 0.5b.

Повторяется ли проблема: Всегда.

Платформа: PS4.

Приложенные файлы: Скриншот с небоскрёбами.

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

Также по теме:

• Что делает игровые предметы ценными?
• Как делать игры быстрее и дешевле — советы Spearhead Games

Источник: Gamasutra