❓ Что происходит с баг-репортом, если ему ставят статус «Не баг»?
Когда баг-репорт получает статус Rejected, As Designed или Not a Bug, это означает, что система работает именно так, как было задумано, либо ошибка произошла на этапе тестирования.
✅ Основные причины такого статуса:
🎌 Спецификация: поведение системы соответствует требованиям, даже если оно кажется странным или неудобным. Это «фича», а не ошибка.
🎌 Ошибка в ожиданиях: тестировщик неверно понял логику работы приложения или обратился к устаревшей документации.
🎌 Проблемы окружения: баг вызван некорректными тестовыми данными или локальными проблемами на стенде тестировщика.
✅ Что происходит с репортом дальше?
Баг-репорт закрывается. При этом автор отклонения (обычно разработчик или аналитик) обязан оставить комментарий с обоснованием: дать ссылку на пункт в требованиях или объяснить логику системы. Это нужно, чтобы при повторном тестировании вопрос не возникал снова.
✅ Что делать тестировщику в такой ситуации?
🎌 Проверить аргументы. Если аргументы логичны и подтверждены документацией — согласиться и закрыть задачу.
🎌 Защитить пользователя. Если поведение системы действительно «по проекту», но ломает пользовательский опыт (UX), баг-репорт закрывается, но вместо него создается задача на улучшение — Improvement или Feature Request.
Когда баг-репорт получает статус Rejected, As Designed или Not a Bug, это означает, что система работает именно так, как было задумано, либо ошибка произошла на этапе тестирования.
✅ Основные причины такого статуса:
🎌 Спецификация: поведение системы соответствует требованиям, даже если оно кажется странным или неудобным. Это «фича», а не ошибка.
🎌 Ошибка в ожиданиях: тестировщик неверно понял логику работы приложения или обратился к устаревшей документации.
🎌 Проблемы окружения: баг вызван некорректными тестовыми данными или локальными проблемами на стенде тестировщика.
✅ Что происходит с репортом дальше?
Баг-репорт закрывается. При этом автор отклонения (обычно разработчик или аналитик) обязан оставить комментарий с обоснованием: дать ссылку на пункт в требованиях или объяснить логику системы. Это нужно, чтобы при повторном тестировании вопрос не возникал снова.
✅ Что делать тестировщику в такой ситуации?
🎌 Проверить аргументы. Если аргументы логичны и подтверждены документацией — согласиться и закрыть задачу.
🎌 Защитить пользователя. Если поведение системы действительно «по проекту», но ломает пользовательский опыт (UX), баг-репорт закрывается, но вместо него создается задача на улучшение — Improvement или Feature Request.