Ответ
Конфликт часто возникает из-за разной интерпретации требований или поведения системы. Ключ к разрешению — переход от субъективных мнений к объективным данным.
Сценарий: Тестировщик обнаруживает, что поле для ввода номера телефона в форме принимает буквы.
- Позиция разработчика: "Это не баг, а фича для поддержки мнемонических номеров, например,
1-800-FLOWERS." - Позиция тестировщика: "В спецификации требований (SRS) явно указан формат
+7 (XXX) XXX-XX-XXдля России. Буквы сломают интеграцию с SMS-шлюзом, который ожидает только цифры."
Алгоритм конструктивного разрешения:
- Сверка с документацией: Совместно изучить актуальные требования (SRS, пользовательские истории).
- Анализ последствий: Обсудить, как данное поведение влияет на смежные системы (SMS-сервис, БД) и пользовательский опыт.
- Привлечение арбитра: Если расхождения остаются, обратиться к продукт-оунеру или бизнес-аналитику для финального решения.
- Фиксация результата: Внести правки в требования или завести баг-репорт с чёткими шагами воспроизведения и ссылкой на спецификацию.
Итог: Фокус должен оставаться на качестве продукта, а не на личностях.