Уважаемые Тестировщики. Вы все нам здорово помогаете и приносите неоценимую помощь проекту.
Но еще больше вы сможете помочь если будете составлять свои баг-репорты (отчеты про ошибки) по определенному шаблону.
Почему это так важно. Если кратко, то хороший баг-репорт позволяет:
1. воспроизвести проблему (это не всегда возможно, но надо стремиться).
2. понять, в чем проблема и какова ее важность.
Как написать хороший баг-репорт?
Для начала надо подготовиться. Если вы обнаружили баг, не стоит моментально бежать на форум и писать «ничего не работает!». Воспроизведите ошибку. Воспроизвелась? Отлично. Не воспроизвелась? Значит, что-то вы не учли. Вспоминайте, что делали.
Снова воспроизвелась? Ура! А теперь минимизируйте количество шагов для воспроизведения, удостоверьтесь, что нет ничего лишнего.
Когда вы поняли, какие именно данные и какие ваши действия приводят к проблеме, кратко сформулируйте ее суть — придумайте заголовок баг-репорта. Опишите проблему настолько подробно и конкретно, насколько позволяет заголовок, при этом не увлекаясь его длиной
Пример плохого заголовка: «Все виснет, когда я нападаю на врага»
Пример «более хорошего» заголовка: «Игра зависает при нападении армией гномов на поселение гоблинов»
Старайтесь не писать фразы типа «я нанимаю отряд», «я нажимаю кнопку» и им подобные. И заголовок, и описания шагов — это руководство к действию для тех, кто будет исправлять проблему, поэтому лучше формулировать как «нанять отряд», «нажать на кнопку».
Теперь откройте форум, эту тему и начните заполнять форму баг-репорта.
Запишите
заголовок.
После этого:
Подробное описание, опишите в нем проблему более подробно — уточните те детали, которые пришлось опустить в заголовке. Если вы понимаете, в чем причина проблемы (используется устаревшая формула для расчетов, не прописано какое-то значение, ошибка в определенном скрипте и т.д.) — тоже пишите все здесь. Если не знаете — лучше не гадайте.
Шаги для воспроизведения — основное поле для заполнения в баг-репорте.
Запишите шаги, которые вы определили. Как уже было сказано, шагов должно быть необходимо и достаточно для воспроизведения проблемы. Лишние не пишите. Необходимых тоже не пропускайте
После описания шагов обязательно напишите результат — что получилось.
Далее здесь же опишите ожидаемый результат, если это необходимо. Конечно, не стоит писать «Игра не крашится», но если, например, результаты действий не соответствуют ожидаемым, то это надо указывать.
Таким образом, описание шагов для воспроизведения должно выглядеть как-то так:
Шаги для воспроизведения:
1. Набрать такую-то армию...
2. Ввести армию из цитадели…
3. Напасть на другую армию
4. Кликнуть кнопку оступить
Результат:
В армии погиб генерал
Ожидаемый результат:
Генерал не должен погибать при отсутплении.
Если требуются сэйвы, логи, скрины — сразу приаттачьте. Само собой, файлы должны содержать только информацию, необходимую для воспроизведения ошибки. Подчистите все лишнее. Например если у вас два монитора - не стоит присылать скрин двух мониторов, обрежте лишнее, оставьте только игру.
Если проблема с визуальным отображением, то скриншот обязателен — можно будет понять ошибку и без воспроизведения шагов.
На скриншотах лучше указывать место с ошибкой. Стрелочкой или просто полосой контрастного цвета. Здорово ускоряет «чтение» скриншота.
Но вставлять скриншот в каждый баг-репорт совершенно не обязательно: пожалуйста, не плодите лишних сущностей. Если он ничем не поможет в воспроизведении проблемы — не тратьте время на его изготовление.
Сэйвы и логи так же не всегда нужны. Иногда они лишние. иногда без них не обойтись. Здраво оценивайте их необходимость. И если вы изначально в баг-репорте забыли что-то указать - помните про кнопку - Редактировать.
Severity — это критичность бага с точки зрения тестировщика: фича, опечатка в тексте, мелкая проблема, значительная проблема, падение игры, блокирующая проблема и пр.
«Какой приоритет ставить багу?» На этот вопрос нет однозначного ответа, все зависит от каждого конкретного случая. Но старайтесь не увлекаться и не ставить всем багам подряд высокий или критичный приоритет, реально оценивайте их критичность для проекта.
Но не забывайте - какой бы приоритет вы не поставили - приоритет бага выставляем уже мы, разработчики проекта. Мы сами решим когда исправлять ошибку, кто ее будет исправлять и как оно должно быть на самом деле. Ваше дело - нас проинформировать об ошибке.
Environment - Укажите версию операционной системы, наличие сервис-паков, разрядность. Какие еще моды у вас стоят? (Иногда моды могут конфликтовать)
Итак - краткое резюме - шаблон баг-репорта:
I. Заголовок.
II. Подробное описание.
III. Шаги для воспроизведения
IV. Критичность бага.
V. Данные о вашей системе.
Спасибо за внимание и сотрудничество.
Тема закрыта
Нажмите, чтобы прочитать
по традиции Кислев беру, попробую отразить новое вторжение Хаоса!!!
