Что значит статус not a bag?

Что значит статус Not a Bug?

В контексте управления ошибками в QA (Quality Assurance) и процессах разработки, статус Not a Bug (или его русскоязычные варианты: "Не баг", "Не ошибка", "Не дефект") — это одно из ключевых решений, которое может быть присвоено заведенной проблеме (баг-репорту). Это означает, что описываемое поведение системы, согласно мнению ответственного лица (чаще всего разработчика, инженера QA или менеджера продукта), не является ошибкой, дефектом или нарушением требований.

Суть статуса "Not a Bug"

Статус присваивается, когда поведение системы считается корректным, но оно:

1. Не соответствует ожиданиям тестировщика или пользователя, хотя формально не нарушает зафиксированные требования или спецификации.
2. Совпадает с проектной документацией или техническими ограничениями, даже если это поведение кажется неудобным или неожиданным.
3. Является следствием внешних факторов, не подконтрольных системе (например, сетевые проблемы, поведение сторонних API, действия пользователя).

Типичные причины присвоения статуса "Not a Bug"

1. Неверное понимание требований

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

**Пример:** Приложение отображает время в формате `HH:MM`. Тестировщик ожидает `HH:MM:SS`. В спецификации указан только формат `HH:MM`. Статус: Not a Bug.

2. Несогласованность с общепринятой логикой или дизайном

Иногда дизайн или логика продукта могут быть нестандартными. Если это согласовано и реализовано в соответствии с дизайн-Mockup или бизнес|lогикой, это не ошибка.

**Пример:** Кнопка "Отмена" в диалоговом окне расположена справа, а "ОК" — слева, что противоречит распространенной практике. Если дизайн утвержден, статус: Not a Bug.

3. Ограничения среды или технологии

Система может работать определенным образом из-за технических ограничений (фреймворк, библиотека, протокол).

# Пример технического ограничения
# API возвращает список пользователей с максимальным размером страницы 50 элементов.
# Если тестировщик ожидает возможность получить сразу 100 элементов без пагинации,
# это техническое ограничение API, а не ошибка реализации.
response = api.get_users(per_page=100)  # Возвращает только первые 50
# Статус: Not a Bug (ограничение стороннего API)

4. Проблема в тестовых данных или окружении

Дефект может наблюдаться из-за некорректных данных, настроек тестового окружения или действий тестировщика.

# Пример окружения
# Приложение не запускается на тестовой машине из-за конфликта версий Node.js.
# На других машинах и в production-окружении работает корректно.
# Проблема в конфигурации тестового окружения, не в коде приложения.
node --version  # 14.17.0, требуется >=16.0.0
# Статус: Not a Bug (проблема окружения)

5. Запрос на изменение (Change Request / Enhancement)

Часто тестировщик выявляет не ошибку, а возможность улучшения продукта (новый функционал, изменение UI/UX, оптимизацию). Это должно быть переведено в отдельный тип задачи.

**Пример:** "При нажатии на поле ввода оно не выделяется цветной рамкой." Это может быть запросом на улучшение UX, но если в текущем дизайне такое поведение не предусмотрено, исходный баг-репорт закрывается как Not a Bug, а идея переносится в backlog как enhancement.

Процесс и последствия присвоения статуса

1. Присваивается обычно разработчиком или ответственным лицом после анализа баг-репорта.
2. Баг-репорт закрывается с этим статусом и соответствующим комментарием, объясняющим причину.
3. Обязательно требуется подробное обоснование. Простое "Not a Bug" без объяснений приводит к конфликтам и непониманию.
4. Тестировщик должен либо согласиться с решением, либо, если считает его неверным, переоткрыть дефект с новыми аргументами или обратиться к менеджеру/архитектору для разрешения спорной ситуации.
5. Статус помогает очищать баг|трекер от некорректных или не относящихся к дефектам записей, фокусируя команду на реальных проблемах.

Важные рекомендации для работы со статусом

• Для тестировщика: Перед созданием баг-репорта всегда сверяйтесь с актуальными требованиями, спецификациями и дизайнами. Если поведение субъективно "неудобно", формулируйте его как предложение по улучшению (enhancement), а не как критический дефект.
• Для разработчика: При закрытии бага как "Not a Bug" всегда предоставляйте четкую ссылку на требование, дизайн или техническую документацию, которая подтверждает вашу позицию.
• Для всей команды: Статус "Not a Bug" — не признак "победы" одной стороны над другой. Это инструмент для достижения консенсуса и точного соответствия продукта его проектной документации. Спорные случаи должны разрешаться на уровне требований к продукту (Product Owner, Business Analyst).

Влияние на метрики и процесс

Статус "Not a Bug" напрямую влияет на метрики качества:

• Снижает количество "действительных" (valid) дефектов в отчетах.
• Может указывать на проблемы в процессе: большое количество таких статусов часто сигнализирует о:

    *   Недостаточно детальных или противоречивых требованиях.
    *   Плохой коммуникации между QA, разработкой и дизайном.
    *   Недостаточном обучении тестировщиков о продукте или технологиях.

Таким образом, статус "Not a Bug" — это важный механизм контроля качества, который отделяет реальные дефекты программного обеспечения от субъективных ожиданий, проблем окружения или запросов на новые функции. Его корректное использование требует четкой документации, хорошей коммуникации в команде и понимания, что конечной целью является создание продукта, точно соответствующего согласованным и зафиксированным требованиям.