Какая ошибка не является багом?

Что такое баг и чем он не является?

Прежде чем определить, какая ошибка не является багом, нужно чётко понять, что такое баг в контексте разработки ПО. Баг (дефект) — это отклонение фактического поведения системы от ожидаемого (требований, спецификаций или ожиданий пользователя), которое ухудшает качество продукта и требует исправления.

Ошибки, которые НЕ считаются багами

Следующие ситуации, хотя и могут восприниматься как "ошибки", не являются дефектами ПО:

1. Ошибка в требованиях или дизайне

Если система работает строго в соответствии с документацией, но сама документация содержит логическую ошибку или неполное описание — это дефект требований, а не ПО. Например:

# Ошибочное требование (спецификация):
# "Пользователь может добавить в корзину более 999 товаров"
# Технически система это позволяет, но бизнес-логика (складские остатки) — нет.

Исправлять нужно не код, а спецификацию.

2. Ошибка конфигурации или среды выполнения

Проблемы, вызванные неправильными настройками среды (сервера, БД, сети), а не кодом приложения.

• Пример: Приложение работает медленно из-за недостатка памяти на сервере. Код оптимизирован, но инфраструктура не соответствует нагрузке.

3. Ошибка данных (Data Issue)

Некорректные входные данные, предоставленные пользователем или внешней системой, при корректной обработке их приложением.

• Пример: Пользователь вводит буквы в поле "Возраст". Если приложение показывает корректное сообщение об ошибке валидации — это не баг, а ожидаемое поведение.

4. Ошибка использования (User Error)

Ситуация, когда пользователь применяет систему не по назначению, не понимает её логику или совершает последовательность действий, не предусмотренную сценарием использования.

• Пример: Нажатие кнопки "Сохранить" до ввода обязательных данных, если кнопка при этом неактивна (правильная реализация). Если же пользователь ожидает, что система "додумает" за него — это может быть дефект UX, но не обязательно баг в коде.

5. Запрос на новую функциональность (Enhancement Request)

Когда система работает как задумано, но стейкхолдер или пользователь хочет изменить или расширить её поведение.

• Пример: "Кнопка слишком маленькая" при соответствии гайдлайнам или "Хочу, чтобы отчёт выгружался в PDF, а не только в Excel" при изначальном наличии только Excel-экспорта.

6. Проблемы сторонних компонентов

Дефекты в библиотеках, фреймворках, API или службах третьих сторон, которые использует ваше приложение. Пока не доказано, что ваша интеграция реализована некорректно, это — внешняя проблема. Часто её нужно отслеживать, но не исправлять своими силами.

7. Архитектурные или технические долги

Неоптимальные, но рабочие решения (например, медленный запрос), принятые осознанно на определённом этапе для соблюдения дедлайнов. Их устранение — задача технического рефакторинга, а не исправления срочного бага.

8. Недокументированная, но корректная функциональность

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

• Пример: Автоматическое исправление опечатки в URL браузером — это фича, а не баг вашего веб-приложения.

Ключевой принцип разграничения

Главный вопрос, который задаёт себе QA-инженер: "Соответствует ли поведение системы зафиксированным и согласованным ожиданиям (требованиям, спецификациям, стандартам)?"

• Если ДА, и ожидания корректны — бага нет.
• Если НЕТ — есть баг.
• Если ДА, но ожидания ошибочны или неполны — баг в требованиях.
• Если поведение можно улучшить без нарушения текущих требований — это улучшение (enhancement).

Вывод: Наиболее яркий пример ошибки, которая не является багом — это ошибка в исходных требованиях или спецификации. Система работает в точности так, как её попросили, но результат не устраивает заказчика, потому что его изначальная "инструкция" была неверной. Исправление таких ошибок лежит в плоскости бизнес-анализа и управления требованиями, а не тестирования и разработки ПО в их чистом виде. Умение отличать подобные ситуации — важный профессиональный навык QA-инженера, экономивший команде огромное количество времени и ресурсов.