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

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

Описание дефекта, а фактически задача для разработчика, как правило, содержит следующие обязательные атрибуты.

1. Краткое описание (Summary)

2. Подробное описание (Description)

3. Шаги воспроизведения (Steps)

4. Ожидаемый результат (Expected Result)

5. Фактический результат (Result)

6. Критичность (Severity)

7. Приоритет (Priority)

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

Краткое описание (Summary) – название атрибута говорит само за себя. Задача тестировщика – максимально кратко и в то же время понятно описать найденный дефект. Иногда тестировщики говорят: «Всегда есть Description, где можно описать баг во всех деталях», но разработчики считают суперабилкой тестировщика именно его способность описывать баги кратко и понятно. Это объясняется простым фактом: в Jira и других баг-трекерах разработчик видит задачи списком, каждая задача представлена кратким описанием. Теперь представь, что таких задач (баг-репортов) несколько сотен, больше половины из которых непонятны без прочтения Description. Представь только, сколько времени потеряет разработчик для вникания в суть проблемы. И как он будет называть при этом тестировщика. Кроме того, при грамотном написании Summary в огромном списке задач довольно легко находить дубликаты.

Способность описать дефект в рамках поля Summary – действительно одно из главных достоинств и профессиональных навыков специалиста по тестированию. Есть несколько способов обучения этому навыку. Приведем три самых действенных и простых.

Метод «Что? Где? Когда?»

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

1. Что произошло и в чем суть неполадки?

2. Где был обнаружен дефект?

3. Когда и при каких обстоятельствах возник дефект?

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

Метод выделения ключевой информации

Весьма действенный метод, особенно когда у тебя уже есть длинное описание дефекта.

1. Попробуй описать дефект со всеми необходимыми деталями.

2. Внимательно прочитай свое описание и выдели из него ключевую информацию, то есть самые важные моменты.

3. Попробуй сложить эти ключевые моменты вместе.

То, что получится в итоге, и будет составлять Summary.

Метод тождественности атрибутов

Составь описание дефекта по следующей схеме.

1. Шаги воспроизведения

2. Ожидаемый результат

3. Полученный результат

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

Но вернемся к прочим атрибутам дефекта.

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

Следующие два атрибута – Шаги (Steps) и Ожидаемый результат (Expected Result) – берутся непосредственно из твоего тест-кейса[11], с помощью которого ты обнаружил дефект. Это и понятно. Разработчик должен сделать абсолютно то же самое, чтобы увидеть этот баг. О том, как проектировать тест-кейсы, я расскажу тебе чуть позже.

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

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

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

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

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

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

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

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