В чём разница между дефектом и багом?

В чём разница между дефектом и багом

Это часто путаемые термины, и различие важно для правильного общения в QA. За 10+ лет я использовал оба и понимаю когда что применять.

Определения

Дефект (Defect)

Определение: Любое отклонение от требуемого поведения, включая найденные и не найденные проблемы.

Дефект = Проблема в коде (потенциальная или реальная)

Это может быть:
- Баг (найденная проблема)
- Потенциальная проблема (предсказуемая)
- Неправильная реализация требования
- Качественная проблема

Баг (Bug)

Определение: Конкретная, документированная проблема, найденная при тестировании.

Баг = Дефект который:
1. Найден (reproduced)
2. Задокументирован
3. Имеет баг-репорт
4. Требует исправления

Это конкретный случай дефекта

Аналогия

Дефект = Все проблемы в системе (видимые и невидимые)
Баг = Конкретно задокументированная проблема

Как в человеческом теле:
Дефект = любые заболевания (даже неопознанные)
Баг = диагностированное заболевание с номером в медицинской карте

---

Дефект = Потенциальная проблема
Баг = Подтвержденная проблема

Статистика

Количество дефектов > Количество багов

Примеры:
- 100 дефектов в коде
- 45 обнаружены и документированы (баги)
- 55 остаются скрытыми

Идеальный scenario: Все дефекты = Все баги
Реальность: Только часть дефектов становится багами

Дефект

Типы дефектов

1. Баги (найденные дефекты)
   - Что-то не работает
   - Задокументировано
   - Имеет баг-репорт

2. Потенциальные дефекты
   - Код quality issues
   - Безопасности проблемы
   - Performance проблемы
   - Архитектурные проблемы

3. Дизайн дефекты
   - Требование неправильное
   - Дизайн не соответствует требованию
   - UX проблемы

Примеры дефектов

1. Дефект: SQL Injection vulnerability
   - Потенциальная проблема безопасности
   - Может использоваться для атаки
   - Баг: Только если найден и документирован

2. Дефект: Memory leak
   - Код имеет утечку памяти
   - Видна при интенсивном использовании
   - Баг: Только если обнаружен и заведён баг-репорт

3. Дефект: N+1 query problem
   - Неэффективный код
   - Медленная производительность
   - Баг: Если someone report performance issue

Баг

Характеристики баги

Баг имеет:
1. Title - короткое описание
2. Description - подробное описание
3. Steps to reproduce - как воспроизвести
4. Expected result - что должно быть
5. Actual result - что происходит
6. Severity - насколько критично
7. Environment - где обнаружен
8. Attachments - скриншоты, видео
9. Status - Open, In Progress, Fixed, Closed

Цикл жизни баги

1. New
   QA находит проблему и заводит баг
   
2. Assigned
   Developer получает баг
   
3. In Progress
   Developer работает над исправлением
   
4. Fixed
   Developer говорит что исправил
   
5. Reopened (sometimes)
   QA проверяет и находит что не исправлено
   
6. Closed
   QA верифицирует что исправлено

Баги vs Дефекты в цифрах

Типичная метрика

Общее количество дефектов: 150
- найденные (баги): 60
- скрытые (не найденные): 90

От найденных 60 багов:
- Critical (must fix): 3
- High (should fix): 12
- Medium (nice to fix): 25
- Low (cosmetic): 20

Средняя статистика:
При отличной QA: 30-40% дефектов найдено (становятся багами)
При хорошей QA: 50-60% дефектов найдено
При плохой QA: 10-20% дефектов найдено

Практические примеры

Пример 1: Login form

Дефект: Password field не mask'ет символы

Варианты:

1. Дефект остаётся скрытым
   - Никто не заметил
   - Нет баг-репорта
   - В production проходит
   - User может заметить потом

2. Баг найден на тестировании
   - QA открыл форму
   - Ввод пароля показывает символы
   - Заводит баг-репорт
   - Developer исправляет
   - Баг закрывается

Пример 2: Payment processing

Дефект: Race condition в платежной системе

Это сложный баг:

1. Дефект существует в коде
   - Когда два платежа обрабатываются одновременно
   - Может быть двойная списание
   - Код имеет дефект

2. Баг возникает только при:
   - Одновременные платежи
   - Specific timing
   - Specific conditions

3. При обычном тестировании:
   - Может не возникнуть
   - Дефект остаётся скрытым
   - Баг не заводится

4. При load-тестировании:
   - Проблема проявляется
   - QA обнаруживает
   - Заводит баг
   - Developer исправляет

Когда дефект становится багом

Необходимо

1. Найти проблему
   - Через тестирование
   - Через code review
   - Через production monitoring
   - Через user report

2. Воспроизвести
   - Повторить проблему
   - Понять условия
   - Документировать

3. Заводить баг-репорт
   - Title
   - Steps
   - Expected vs Actual
   - Severity

4. Assign разработчику
   - Тот кто может исправить
   - С информацией о проблеме

Мой подход при работе

Выявление дефектов

При тестировании:
1. Ищу дефекты (поведение отличается от требования)
2. Если найду → заводю баг
3. Если дефект потенциальный:
   - Может быть issue
   - Может быть suggestion
   - Но не всегда баг

Документирование

Дефект vs Баг документирование:

Дефект в code review:
- "Этот код может иметь проблему"
- "Нужна проверка"
- Issue в GitHub

Баг в баг-репорте:
- "Когда я делаю X, происходит Y"
- "Это неверно, должно быть Z"
- Полная информация для воспроизведения

Таблица сравнения

Цель качества

Идеал: Все дефекты = Все баги

Это значит:
- Все проблемы найдены
- Все исправлены
- Quality = 100%

Реальность: Это невозможно
- Всегда есть скрытые дефекты
- Но можем улучшить поиск
- Через better testing
- Через better code review
- Через better monitoring

Заключение

Дефект и баг связаны, но разные.

Дефект = Потенциальная/реальная проблема в коде
- Может быть скрыт
- Может не быть обнаружен
- Может остаться в production

Баг = Конкретно найденный и задокументированный дефект
- Обнаружен при тестировании
- Имеет полную информацию
- Требует исправления

Как QA:
Моя задача:
1. Найти как можно больше дефектов (сделать их багами)
2. Хорошо документировать (чтобы легко исправить)
3. Verify исправления (чтобы баг не вернулся)

Операционально:
- Я работаю с БАГАМИ (заводу баг-репорты)
- Я ищу ДЕФЕКТЫ (чтобы их превратить в баги)
- Я рекомендую ДЕФЕКТЫ (code review и suggestions)

С 10+ летами опыта я видел: качество = процент найденных дефектов (превращенных в баги) до production. Чем больше дефектов найду в тестировании, тем качественнее продукт достанется пользователям.