Что делать если баг не относится к проверяемой функциональности

Как поступить, если обнаруженный баг не относится к проверяемой функциональности

В практике QA-инженера это частая и важная ситуация, которая проверяет не только технические знания, но и профессиональную этику, коммуникативные навыки и понимание процессов разработки. Обнаружение побочного дефекта (side-effect bug) — это не проблема, а возможность повысить качество продукта в целом. Вот пошаговый алгоритм действий, который я выработал за годы работы.

1. Первоначальная валидация и документирование

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

• Воспроизведите сценарий: Четко зафиксируйте шаги для стабильного воспроизведения.
• Документируйте корректно: Создайте баг-репорт в трекере (Jira, Youtrack и т.д.), но с особой пометкой.

    *   В **Summary/Title** укажите, что баг найден вне основной области: `[Side-Bug] Некорректное поведение кнопки "Настройки" при проверке модуля "Отчеты"`.
    *   В **Description** подробно опишите окружение, шаги, фактический и ожидаемый результат.
    *   **Ключевой шаг:** В поле **Component**, **Label** или прямо в описании добавьте метку, например, `out-of-scope`, `side-effect`, или укажите реальный компонент продукта, к которому относится ошибка. Это поможет позже правильно направить дефект.

**Шаги воспроизведения:**
1. Откройте модуль "Финансовые отчеты".
2. Сгенерируйте отчет за текущий месяц.
3. Не закрывая отчет, перейдите в главное меню (верхняя панель).
4. Нажмите кнопку "Настройки профиля" (глобальная кнопка в хедере).

**Ожидаемый результат:** Открывается модальное окно настроек профиля.
**Фактический результат:** Кнопка не реагирует на клик. Консоль браузера выдает ошибку "Uncaught TypeError: Cannot read properties of null".
**Примечание:** Баг обнаружен при тестировании функциональности "Генерация отчетов", но относится к глобальному компоненту UI/хедера.

2. Определение приоритета и срочности

Оцените критичность дефекта самостоятельно, прежде чем эскалировать:

• Блокирующий (Blocker/Critical): Дефект приводит к падению смежного модуля, потере данных, безопасности. Требует немедленного оповещения.
• Серьезный (Major): Функциональность в другой части приложения не работает, но не блокирует текущие тесты.
• Незначительный (Minor/Trivial): Косметическая проблема, опечатка в непроверяемом модуле.

3. Коммуникация и эскалация

Здесь важна тактичность и следование процессу.

• Сообщите команде: На стендапе или в рабочем чате (Slack, Teams) кратко информируйте команду (разработчиков, проджект-менеджера, тест-лида) о найденном нерелевантном баге, его критичности и где он залогирован.
• Следуйте процессу: В большинстве процессов (Scrum, Kanban) такие баги не останавливают текущий спринт, но должны быть учтены. Обсудите с Product Owner или Менеджером проекта:

    *   Нужно ли немедленно починить баг, если он критичен?
    *   Будет ли он добавлен в бэклог текущего спринта?
    *   Или его планируется исправить в одном из следующих спринтов?

• Заведите отдельную задачу: Иногда правильнее не "вешать" баг на задачу текущей функциональности, а создать новую задачу в бэклоге на исправление этого конкретного дефекта. Это помогает правильному планированию и учету.

4. Фиксация в отчетности

Всегда отражайте такие находки в тестовой документации:

• В тест-кейсе, при выполнении которого был найден баг, сделайте примечание со ссылкой на созданный дефект.
• В ежедневном / итоговом отчете о тестировании укажите количество найденных "побочных" дефектов. Это важная метрика, показывающая общее состояние кодовой базы и потенциальные риски регресса.

Почему НЕЛЬЗЯ игнорировать такой баг?

• Профессиональная ответственность: QA-инженер отвечает за качество продукта в целом, а не только за проверенный кусок функциональности.
• Риск регрессионных ошибок: Сегодняшний нерелевантный баг может стать критическим завтра, когда начнется тестирование той самой модуля.
• Экономия времени: Обнаружение бага на ранней стадии (даже если он не в фокусе) в разы дешевле, чем его обнаружение на проде или на поздних этапах тестирования смежной фичи.
• Доверие команды: Активность и внимательность тестировщика укрепляют доверие к нему со стороны разработчиков и менеджмента.

Итог: Найденный "чужой" баг — это не помеха, а ценная находка. Четкое документирование, своевременная коммуникация в рамках принятых процессов и понимание приоритетов позволяют превратить эту ситуацию из потенциальной конфликтной в демонстрацию вашей экспертизы и вклада в общее качество продукта.