PrepBro
← Назад к вопросам

Какие знаешь атрибуты баг репорта?

1.0 Junior🔥 221 комментариев
#Тестовая документация

Комментарии (1)

🐱
claude-haiku-4.5PrepBro AI26 мар. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

Атрибуты баг репорта

Баг репорт — это документ, который описывает найденный дефект. Правильно написанный баг репорт позволяет разработчикам быстро понять и исправить проблему. Вот основные атрибуты.

Критические атрибуты

1. ID (номер баги)

Уникальный идентификатор.

Пример:

BUG-001
BUG-2026-03-26-001

Автоматически генерируется системой (JIRA, Azure DevOps).

2. Title (Название)

Краткое описание проблемы (5-10 слов).

Хорошее: "Кнопка Submit не работает при пустом email"

Плохое: "Баг с формой" "Что-то сломалось"

3. Description (Описание)

Полное описание проблемы. Дай контекст.

Должно содержать:

  • Что нужно было сделать
  • Что произошло вместо этого
  • Почему это проблема

Пример:

Пользователь пытается оформить заказ, но кнопка "Купить" не реагирует на клик.
В console видна ошибка: TypeError: Cannot read property 'id' of undefined.
Это критичная проблема, так как пользователь не может завершить покупку.

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

Пошаговая инструкция как повторить баг.

Формат:

1. Открыть страницу https://shop.example.com/checkout
2. Оставить поле Email пустым
3. Нажать кнопку "Complete Order"
4. Ожидается: ошибка валидации
5. Фактическое: баг (кнопка не реагирует)

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

Что должно происходить.

Пример:

При нажатии кнопки должно показаться сообщение об ошибке:
"Email is required"
Кнопка должна остаться disabled.

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

Что происходит на самом деле.

Пример:

Кнопка не реагирует на клик.
Ошибка в console: TypeError: Cannot read property 'email'
Юзер может попробовать нажать ещё раз, но ничего не меняется.

7. Severity (Важность / Серьёзность)

Как сильно это влияет на функциональность.

Уровни:

  • Critical/Blocker — приложение упало, основной функционал не работает
  • High — основная функция не работает, есть обход
  • Medium — побочная функция не работает, основное в порядке
  • Low — косметическая проблема, не влияет на функциональность

Примеры:

Critical: Пользователь не может залогиниться
High: Фильтр по цене не работает, но сортировка есть
Medium: Иконка неправильного размера
Low: Опечатка в тексте

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

В каком порядке это исправлять.

Уровни:

  • P0/Urgent — исправить немедленно
  • P1/High — исправить до следующего релиза
  • P2/Medium — исправить когда будет время
  • P3/Low — можно оставить на потом

Примеры:

P0: Баг выше P0 (проблема на production)
P1: Новая фича не работает перед релизом
P2: Косметический баг, не срочно
P3: Проблема в старом фиче, мало пользователей

9. Status (Статус)

Текущее состояние баги.

Значения:

  • Open — только что открыта
  • In Review — разработчик анализирует
  • In Progress — разработчик чинит
  • Fixed/Resolved — разработчик исправил
  • Verified — QA проверил, баг реально исправлен
  • Closed — баг закрыта
  • Reopen — была закрыта, но проблема вернулась
  • Wontfix — разработчик решил не чинить (например, по дизайну)

Важные атрибуты

10. Environment (Окружение)

Где найден баг.

Примеры:

Dev (локальное окружение разработчика)
Staging (тестовое окружение, похоже на prod)
Production (реальное приложение пользователей)
QA (QA окружение для тестирования)

11. Browser / Device

На каком браузере / устройстве найден.

Примеры:

Chrome 120.0 на Windows 10
Safari на iPhone 15 Pro
Firefox 121.0 на macOS
Edge на Pixel 8

12. OS (Operating System)

Операционная система.

Примеры:

Windows 11
macOS Sonoma 14.2
iOS 17
Android 14
Ubuntu 22.04

Вспомогательные атрибуты

13. Assignee (Назначено)

Кому назначена бага для исправления.

Пример:

Иван Петров (Backend разработчик)

14. Reporter (Автор)

Кто открыл баги.

Пример:

Мария Сидорова (QA инженер)

15. Labels / Tags

Метки для группировки.

Примеры:

front-end
api
performance
security
regression

16. Component

Какой компонент затронут.

Примеры:

UI/Form
Authentication
Payment
Search
UserProfile

17. Sprint / Version

В каком спринте / версии найдена.

Примеры:

Sprint 45 (март 2026)
v2.5.0
Release 3.1

18. Due Date (Дедлайн)

Когда должна быть исправлена.

19. Created Date

Когда баги была открыта (обычно автоматически).

20. Updated Date

Когда последнее обновление (автоматически).

Дополнительная информация

21. Attachments (Вложения)

  • Скриншоты
  • Видео
  • Логи
  • HAR файлы (Network tab export)
  • Console ошибки

22. Comments / Activity

Жизненный цикл баги:

26.03.2026 10:00 - Maria opened bug
26.03.2026 11:30 - Ivan: "Я это чинить буду"
26.03.2026 14:00 - Ivan: "Исправил в коммите abc123"
26.03.2026 16:00 - Maria: "Проверила, баг закрыта ✓"

23. Related Issues (Связанные задачи)

  • Дублирующиеся баги (разные люди нашли одно)
  • Следствие этого баги (может быть две проблемы)
  • Epic (большая фича, которая этот баг содержит)

Пример полного баг репорта

ID: BUG-2026-03-234
Title: Кнопка Submit в форме регистрации не работает с длинными email

Severity: High
Priority: P1
Status: Open
Assignee: Ivan Petrov
Reporter: Maria Sidorova

Environment: Staging
Browser: Chrome 120.0
OS: Windows 11

Component: Registration Form
Sprint: Sprint 45
Labels: front-end, regression

Description:
При регистрации с email длиной > 50 символов кнопка Submit не реагирует на клик. Это регрессия (работало в v2.4.0).

Steps to Reproduce:
1. Открыть https://app-staging.example.com/register
2. Заполнить форму:
   - Name: John Doe
   - Email: verylongemailaddresswithatestdomainname@verylongdomainname.com
   - Password: SecurePass123!
3. Нажать кнопку "Register"

Expected Result:
Пользователь регистрируется и перенаправляется на подтверждение email.

Actual Result:
Кнопка не реагирует на клик. В DevTools console видна ошибка:
TypeError: Email validation failed: index out of bounds

Attachments:
- screenshot_error.png
- console_error.log
- network.har

Comments:
(26.03.2026 10:00) Maria: "Найдена при регистрации с корпоративным email"

Лучшие практики при написании баг репорта

✓ Будь точен (конкретные числа, адреса) ✓ Воспроизводимо (шаги должны быть понятны) ✓ Добавляй скриншоты/видео ✓ Не придумывай — докажи (console errors, logs) ✓ Один баг = одна проблема ✓ Проверь что это не дубль ✓ Используй правильный язык (русский или английский, не смешивай) ✗ Не пиши эмоции ("это ужасно", "разработчик неправ") ✗ Не указывай решение, если не просили ✗ Не открывай баги с низким приоритетом после релиза

Вывод

Хорошо написанный баг репорт — это 50% решения проблемы. Разработчик может быстро понять и исправить, QA может быстро проверить. Атрибуты баги — это язык общения между тестировщиком и разработчиком.