Тестирование видеоигр, или Легкий способ попасть в геймдев
Шрифт:
Приоритет (Priority) – это фактически скорость, с которой разработчики должны отреагировать на найденный дефект. Похоже на то, как скорая помощь реагирует на разных больных: на скорость реагирования влияют признаки, характеризующие степень тяжести больного. В большинстве случаев определением приоритета занимается менеджер проекта или тест-менеджер, обладающий большей информацией о проекте и продукте, но иногда тестировщик также может выразить свое мнение по этому вопросу.
Про эти два важнейших атрибута я расскажу более подробно чуть ниже.
Традиционно
А вот чтобы определить приоритет, нужно гораздо больше информации: понимание загруженности команд разработки, потенциального влияния дефекта на репутацию разработчика и массу другого. Поэтому определением приоритета занимается как минимум руководитель той команды, которая допустила и будет исправлять дефект, а в идеальном случае – менеджер проекта или продюсер, ответственный за разработку.
Могут быть и другие атрибуты баг-репорта, крайне полезные для разработчика.
Повторяемость (Reproducibility) [12] – этот атрибут важен для определения Приоритета дефекта и показывает, насколько часто появляется дефект в определенных обстоятельствах, определяет его «назойливость». Он также дает понимание, что то, что ты описываешь, – действительно баг, а не однократный сбой неясной этимологии. С этим атрибутом необходимо быть очень внимательным. Часто тестировщики не видят разницы в оформлении повторяемости в процентном или числовом отношении. Однако есть разница, если баг имеет повторяемость 20 % (из 5 проверок) и когда он повторяется 2 из 5 раз. В первом случае повторяемость дефекта будет равной 1 из 5 раз, а во втором – в два раза чаще.
12
Иногда также называется Repro Frequency.
Дарья Касиманова, QA-менеджер Saber Interactive
Аналогом Reproducibility является Repro Frequency (частота воспроизведения) в описании дефекта компьютерной игры. Это мера, которая указывает на то, как часто возникает или воспроизводится определенный дефект или проблема в игре. Это важный параметр при тестировании и отладке игр: он помогает разработчикам определить, насколько критична проблема и как срочно ее необходимо решать.
Чем выше Repro Frequency, тем более часто возникает проблема и, возможно, тем более важно ее устранение, особенно если это критический дефект, который может повлиять на игровой процесс или создать негативное впечатление у игроков. Разработчики игр стремятся уменьшить Repro Frequency до минимума, чтобы обеспечить более стабильный и приятный опыт игры для всех пользователей.
Вложения (Attachments) – это материалы, иллюстрирующие проблему.
Для начала посмотрим, что именно может
1. Изображения
2. Видеофрагменты
3. Логи (файлы системных журналов)
4. Звуковой файл
5. Другие файлы
Все эти файлы нужны в основном для того, чтобы лучше продемонстрировать возникшую проблему. Как говорится, лучше один раз увидеть, чем три раза прочитать баг-репорт. Тестировщики используют разнообразное программное обеспечение (ПО) для создания таких файлов. Например, для создания изображений часто используется ПО, позволяющее делать снимки произвольных областей экрана и редактировать их «на лету».
Для создания видеофрагментов в тех случаях, когда нужно продемонстрировать дефект в динамике (например, когда персонаж упирается в невидимые стены на уровне), используется ПО, позволяющее записывать и обрабатывать видеофрагменты.
В нагрузочном тестировании не обойтись от встроенных системных утилит для демонстрации загрузки процессора или памяти.
В общем, во время тестирования используются десятки различных вспомогательных программ, пользоваться которыми необходимо уметь всем игровым тестировщикам для проведения качественного тестирования и составления хорошего отчета о дефектах.
Вложения в баг-репорте обязательны и играют важную роль по нескольким причинам.
• Скриншоты, видео и логи помогают точно показать, что происходит при возникновении ошибки. Это позволяет разработчикам видеть проблему глазами пользователя и лучше понимать контекст.
• Вместо того чтобы тратить время на попытки воспроизвести проблему по текстовому описанию, благодаря вложениям разработчики могут сразу же увидеть, что не так. Это сокращает время на нахождение и исправление бага.
• Текстовые описания могут быть интерпретированы по-разному. Визуальные и другие вложения уменьшают неоднозначность, предоставляя конкретные доказательства проблемы.
• Логи и дампы памяти могут предоставить ценную информацию о состоянии системы в момент возникновения ошибки. Это помогает разработчикам понять, какие процессы или условия могли способствовать возникновению проблемы.
• Вложения помогают обеспечить более четкое и эффективное общение между теми, кто сообщает о баге, и теми, кто его исправляет. Это сокращает количество необходимых вопросов и уточнений.
• Вложенные файлы могут быть использованы для анализа тенденций и выявления корневых причин проблем, выходящих за рамки конкретного баг-репорта.
• В целом вложения делают баг-репорты более информативными, упрощают и ускоряют процесс их обработки и увеличивают шансы на то, что баг будет успешно исправлен.
Нина Резниченко, QA-менеджер Saber Interactive
В идеале после чтения саммари бага и просмотра вложения (прикрепленный файл – скриншот, видео, логи и т. д) должно быть понятно, в чем проблема и как ее фиксить. Если при взгляде только на прикрепленный к багу файл понятно, в чем баг, то поздравляю, вы достигли вершины искусства. Не стоит пренебрегать скринами даже, казалось бы, в простых проблемах. Сделать скрин и прикрепить его к багу занимает всего пару секунд, а бонус выходит +100 к ясности.