Как определяется баг или не баг
Что проверяют
Умеете ли вы опираться на источник ожидаемого поведения, а не на личное впечатление. Следом почти всегда спрашивают: что делать, если требований нет, и как быть, когда разработчик отвечает «это не баг, это фича».
Как отвечать
Баг это расхождение фактического поведения с ожидаемым. Весь вопрос в том, откуда берётся «ожидаемое», и в тестировании это называют оракулом:
- явные требования: user story и критерии приёмки, спецификация, макеты в Figma, контракт API. Самый сильный аргумент в спорной ситуации;
- неявные ожидания: гайдлайны платформы, стандарты доступности, законодательство (например, 152-ФЗ о персональных данных), здравый смысл пользователя. В требованиях редко пишут «приложение не должно падать на пустом поле», но это всё равно дефект;
- согласованность: продукт сам себе противоречит, соседний экран ведёт себя иначе, предыдущая версия работала по-другому;
- эвристика HICCUPPS Майкла Болтона сводит источники вместе: история продукта, образ компании, похожие продукты, заявления, ожидания пользователя, сам продукт, назначение, стандарты.
Порядок действий: воспроизвести, исключить проблемы окружения (не та сборка, кэш, сломанные тестовые данные, недоступный внешний сервис), найти оракул. Если требования молчат или противоречат друг другу, это вопрос к аналитику или владельцу продукта, а иногда дефект самих требований. Разделяйте баг, улучшение и вопрос: для этого в трекере есть отдельные типы задач.
Решение, чинить или нет, принимает владелец продукта на триаже. Ваша задача: дать факты, шаги, ожидаемый и фактический результат и ссылку на оракул.
Где спотыкаются
Заводят как баг всё, что лично не понравилось, без ссылки на ожидаемое. Такие репорты разработчики быстро учатся закрывать не читая.
Не заводят ничего, потому что «в требованиях не написано». Отсутствие валидации или падение на граничном значении остаётся дефектом, даже если о нём молчит ТЗ.
Спорят с разработчиком в комментариях к задаче неделю. Правильнее вынести вопрос к владельцу продукта и зафиксировать решение в требованиях.