Что делать если тестировщик говорит что это Change Request а не баг?

Различие между Change Request и багом

Это классический вопрос в управлении проектом, который часто возникает на стыке ролей тестировщика и аналитика. Правильно разрешить такой конфликт — ключевой навык BA.

Определения

Баг — это отклонение от требований или спецификации, когда система работает не так, как было задумано:

• Функция не работает совсем
• Выдаёт ошибку вместо результата
• Нарушает существующую бизнес-логику
• Вызывает потерю данных

Change Request (запрос на изменение) — это просьба изменить, добавить или удалить функциональность:

• Требуется новая возможность
• Нужно улучшить существующую функцию
• Изменился бизнес-процесс
• Требование было неполным или неточным

Методология анализа

Чтобы определить, что перед вами, нужно пройти цепочку проверок:

1. Проверить требования — Соответствует ли текущее поведение утверждённому требованию? Если да — это CR, если нет — баг.

2. Проанализировать источник — Возник ли конфликт потому, что:

   • Требование было написано нечётко (баг в требованиях → CR)
   • Разработчик ошибся в реализации (баг)
   • Бизнес передумал (CR)

3. Оценить влияние — Блокирует ли это функциональность? Нарушает бизнес-процесс? Или просто не нравится пользователю?

Практический пример

Сценарий: Тестировщик говорит, что форма регистрации не отправляет SMS на номер +7, только на +1.

• Если в требованиях написано «система поддерживает только номера +1» → это CR
• Если в требованиях указано «система поддерживает российские номера» → это баг

Как действовать

1. Не спорить в техчате — нужно провести анализ
2. Вернуться к документации — найти утверждённые требования
3. Провести синхронизацию — встреча с тестировщиком, разработчиком и Product Owner
4. Классифицировать и приоритизировать:
   • Баг → в текущий спринт (если критичный) или в бэклог
   • CR → в бэклог на оценку и планирование
5. Документировать решение — записать в ticket для истории

Красные флаги

• Тестировщик говорит «это же очевидно!» — значит требование было неполным
• Разработчик защищается — нужна нейтральная оценка
• Требование писал один аналитик — стоит пересмотреть

Профилактика

Чтобы избежать таких ситуаций:

• Писать критерии приёмки (Acceptance Criteria) чётко и измеримо
• Проводить pre-testing review с тестировщиком до старта спринта
• Использовать макеты и примеры в требованиях
• Обсуждать граничные случаи на планировании

Короче говоря: хороший BA предотвращает такие конфликты ещё на этапе написания требований, а если конфликт всё же возник — быстро и профессионально его разрешает.