Раздел 07 — Дефекты и баг-репорты

Баг-репорт читают несколько человек, и каждому нужно своё: руководителю — насколько это плохо и когда чинить, разработчику — как увидеть дефект у себя, тестировщику через месяц — как проверить исправление. Хороший баг-репорт отвечает всем без устных пояснений. Плохой возвращается с комментарием «не воспроизводится» — и дефект уходит к пользователям.

Одно правило важнее остальных: один баг-репорт — один дефект. Если в одном описаны три проблемы, исправят две, а третья потеряется вместе с закрытым баг-репортом.

Шаблон для копирования в трекер — bug-report.md. Пример заполненного баг-репорта о вымышленном магазине:

Корзина: купон ОСЕНЬ10 не уменьшает сумму при количестве больше 1

Версия и окружение: «Магазин» 2.3, test.example.ru; Windows 11, Chrome 141
Серьёзность: серьёзная     Приоритет: высокий     Требование: 5.3

Предусловия: пользователь test01 вошёл; в корзине «Чайник» за 2000 ₽
Шаги:
  1. В поле «Количество» ввести 2
  2. В поле «Купон» ввести ОСЕНЬ10, нажать «Применить»
Фактический результат: сумма 4000 ₽, сообщение «Купон применён»
Ожидаемый результат: сумма 3600 ₽ (скидка 10%)
Дополнительно: воспроизводится всегда (5 из 5); при количестве 1 сумма верная — 1800 ₽

Строка «при количестве 1 сумма верная» сэкономит разработчику час: он сразу ищет ошибку в умножении на количество, а не в купонах вообще.

Серьёзность (severity) — насколько дефект мешает пользоваться программой. Её ставит тестировщик по фактам. Приоритет (priority) — как срочно исправлять. Его предлагает тестировщик, а решает руководитель продукта: он знает сроки, планы и важность клиентов.

Обычно серьёзность и приоритет совпадают, но не всегда:

• Незначительная серьёзность, высокий приоритет — опечатка в названии компании на главной странице перед рекламной кампанией.
• Критическая серьёзность, низкий приоритет — падение при выгрузке отчёта в формат, которым пользуется один клиент, и тот перешёл на другой.

Перед тем как писать баг-репорт, дефект воспроизводят ещё раз — с чистыми данными и строго по записанным шагам. Для «Задачника» это значит: py tasker.py --reset, вход, шаги.

Затем шаги сокращают. Отказ часто находят в длинной цепочке действий, но для дефекта важны два-три из них. Убирайте шаги по одному и проверяйте, остаётся ли дефект:

Что ещё выяснить перед отправкой:

• Как часто: всегда или иногда? Если иногда — сколько раз из пяти и есть ли закономерность (только первый раз, только после обновления страницы).
• Где границы: при каких данных дефекта нет? Количество 1 — нет, 2 — есть, 10 — есть.
• Окружение: есть ли в другом браузере, под другим пользователем?
• Нет ли уже такого: поиск в трекере по ключевым словам. Дубликат тратит время всех.

Вложение подтверждает текст и экономит время, но не заменяет шаги: снимок показывает итог, а не путь к нему.

На снимке выделяйте главное (рамкой в «Ножницах») и убирайте лишнее: личные данные, пароли, чужие вкладки. Запись экрана нужна, когда важна последовательность — дефект появляется во время перехода или анимации. Держите её короткой: 10–30 секунд.

У баг-репорта есть статусы, как у заказа в разделе 06. В разных трекерах они называются по-разному, суть одна:

  [Новый] ──► [В работе] ──► [Исправлен] ──► повторная проверка ──► [Закрыт]
     │                             ▲               │ не исправлен
     │                             └───────────────┘ (переоткрыт)
     └──► [Отклонён]: не дефект, дубликат, не воспроизводится

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

Закрывает баг-репорт тот, кто его открыл, — после проверки, а не по словам разработчика «я поправил».

В курсе баг-трекер — раздел «Проблемы» репозитория на GitFlic: бесплатно, без отдельной программы, и той же учётной записью вы потом будете вести свой проект. Создайте репозиторий tasker-bugs (можно закрытый — тогда добавьте преподавателя участником) и в нём ведите баг-репорты «Задачника».

Что есть в проблеме GitFlic и как это используем:

Отдельного поля приоритета в GitFlic нет — пишите его в описании строкой «Приоритет:». В рабочих трекерах (YouTrack, Jira, Kaiten, Redmine) серьёзность и приоритет — отдельные поля, а набор статусов шире, но заполняется баг-репорт так же.