Тестирование видеоигр, или Легкий способ попасть в геймдев

Фактический результат (Result) – это описание того, что ты увидел своими глазами, выполнив необходимые для проверки Шаги. Если он не отличается от Ожидаемого результата, мы можем быть уверены, что система функционирует как нужно. Любое отличие между Ожидаемым и Фактическим результатом будет означать только одно: перед тобой дефект.

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

Приоритет (Priority) – это фактически скорость, с которой разработчики должны отреагировать на найденный дефект. Похоже на то, как скорая помощь реагирует на разных больных: на скорость реагирования влияют признаки, характеризующие степень тяжести больного. В большинстве случаев определением приоритета занимается менеджер проекта или тест-менеджер, обладающий большей информацией о проекте и продукте, но иногда тестировщик также может выразить свое мнение по этому вопросу.

Про эти два важнейших атрибута я расскажу более подробно чуть ниже.

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

А вот чтобы определить приоритет, нужно гораздо больше информации: понимание загруженности команд разработки, потенциального влияния дефекта на репутацию разработчика и массу другого. Поэтому определением приоритета занимается как минимум руководитель той команды, которая допустила и будет исправлять дефект, а в идеальном случае – менеджер проекта или продюсер, ответственный за разработку.

Могут быть и другие атрибуты баг-репорта, крайне полезные для разработчика.

Повторяемость (Reproducibility)[12] – этот атрибут важен для определения Приоритета дефекта и показывает, насколько часто появляется дефект в определенных обстоятельствах, определяет его «назойливость». Он также дает понимание, что то, что ты описываешь, – действительно баг, а не однократный сбой неясной этимологии. С этим атрибутом необходимо быть очень внимательным. Часто тестировщики не видят разницы в оформлении повторяемости в процентном или числовом отношении. Однако есть разница, если баг имеет повторяемость 20 % (из 5 проверок) и когда он повторяется 2 из 5 раз. В первом случае повторяемость дефекта будет равной 1 из 5 раз, а во втором – в два раза чаще.

Дарья Касиманова, QA-менеджер Saber Interactive

Аналогом Reproducibility является Repro Frequency (частота воспроизведения) в описании дефекта компьютерной игры. Это мера, которая указывает на то, как часто возникает или воспроизводится определенный дефект или проблема в игре. Это важный параметр при тестировании и отладке игр: он помогает разработчикам определить, насколько критична проблема и как срочно ее необходимо решать.

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

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

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

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

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

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

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

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