Чем выше Repro Frequency, тем более часто возникает проблема и, возможно, тем более важно ее устранение, особенно если это критический дефект, который может повлиять на игровой процесс или создать негативное впечатление у игроков. Разработчики игр стремятся уменьшить Repro Frequency до минимума, чтобы обеспечить более стабильный и приятный опыт игры для всех пользователей.

Вложения (Attachments) – это материалы, иллюстрирующие проблему.

Для начала посмотрим, что именно может быть использовано в качестве Вложений.

1. Изображения

2. Видеофрагменты

3. Логи (файлы системных журналов)

4. Звуковой файл

5. Другие файлы

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

Для создания видеофрагментов в тех случаях, когда нужно продемонстрировать дефект в динамике (например, когда персонаж упирается в невидимые стены на уровне), используется ПО, позволяющее записывать и обрабатывать видеофрагменты.

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

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

Вложения в баг-репорте обязательны и играют важную роль по нескольким причинам.

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

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

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

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

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

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

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

Нина Резниченко, QA-менеджер Saber Interactive

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

Часто можно встретить баги с названиями вроде «Неправильное отображение иконки». У меня к таким багам сразу вопрос: что значит неправильное? А как правильно? Или «Работает некорректно». Хорошо, а как корректно? Почему бы сразу не написать, в чем проблема, избегая выход на такие абстракции?

Уточнив, в чем проблема (например, иконка отображается лоу-резно, с темными краями и т. д.), и прикрепив дополнительно скрин или видео, вы сэкономите время как себе (потому что за уточняющим вопросом придут к вам), так и исполнителю.

Мой совет: всегда старайтесь уйти от широких понятий или давайте конкретные числа и данные, если все же их используете. Например, вы описываете баг про Low FPS. Укажите в цифрах, сколько это Low – 10–15 (5 и т. д.)? Кому-то и 60 мало:)

Суммируя сказанное выше, любая ошибка, найденная тестировщиком, должна быть описана как можно подробнее. Для этого в отчете о дефектах, который может представлять собой как обычную таблицу, так и задачу типа «баг» в одном из баг-трекеров[13], у любой ошибки есть атрибуты, которые необходимо заполнить. Эти сведения должны помочь тому, кто будет исправлять эту ошибку, сделать это наиболее рациональным способом.

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

1. Степень влияния на работоспособность игры, то есть насколько сильно дефект затрудняет игровой процесс.

2. Степень заметности для пользователя – насколько дефект заметен для большинства игроков[14].

3. Степень влияния на удобство использования – насколько дефект ухудшает удобство игрового процесса.

Только анализ всех этих факторов вместе позволит получить правильное представление о критичности бага.

С точки зрения критичности принято выделять следующие виды дефектов.

Blocker (Блокирующий, Блокер) – самый критичный и самый заметный дефект, который вызывает самые большие трудности при использовании игрового продукта. Более того, блокер, как правило, – это такой дефект, который не позволяет нам больше играть, и обойти это препятствие не представляется возможным. Помнишь синий экран смерти в Windows? Вот это как раз пример блокера! Другими примерами могут стать «вечный» фриз, утечка памяти и многие другие неприятные вещи. Но есть и хорошая новость для тестировщика: ты никогда не пропустишь блокер, если увидишь его, это просто нереально. Ты внезапно теряешь контроль над игровым процессом и получаешь его назад только после полной перезагрузки. Хотя и в этой ситуации, если подходить строго, блокеры можно разделить на софтлок (softlock) и хардлок (hardlock).

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

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

Представь, что ты находишься в комнате, в которой нет окон, дверь заперта, а ключа нет: выйти из нее невозможно.

Critical (Критический) – этот баг очень похож на предыдущий. Он тоже может превратить игровой процесс в кошмар и выглядит как начало Армагеддона, но, в отличие от предыдущего дефекта, предполагает некий способ выхода из ситуации. Например, появляющееся каждые пять минут окно с ошибкой, останавливающее игровой процесс, можно закрыть, нажав Alt+F4, и продолжить игру.