Как будешь решать конфликт между разработчиком и тестировщиком?

Разрешение конфликта между разработчиком и тестировщиком

Этот сценарий встречается часто: разработчик говорит, что bug не воспроизводится, а тестировщик настаивает, что ошибка есть. Как Business Analyst, я подхожу к этому систематически и непредвзято.

Шаг 1: Сбор фактов

До того как принимать сторону, я собираю полную информацию:

От тестировщика:

• Точные шаги для воспроизведения (step-by-step)
• Ожидаемый результат vs фактический
• Какие данные использовались (тестовые пользователи, окружение)
• На каком окружении найдена ошибка (dev, staging, production)
• Скриншоты, видео, логи
• Версия приложения и браузер/ОС
• Была ли ошибка ранее? Воспроизводится ли всегда?

От разработчика:

• Попытался ли он воспроизвести по указанным шагам
• Что изменилось в коде на момент тестирования
• Могут ли быть какие-то окружения-зависимые проблемы (БД, кэш, браузерные данные)
• Есть ли логи на сервере, которые помогут понять проблему

Шаг 2: Переходу к фактам, не эмоциям

Я говорю: "У нас есть расхождение в результатах. Давайте вместе воспроизведём с нулевого состояния".

Я предлагаю совместную сессию:

1. Очищаем браузер (кэш, cookies, localStorage)
2. Используем чистое тестовое окружение
3. Повторяем шаги вместе (разработчик, тестировщик, я)
4. Наблюдаем результат

Это часто решает проблему:

• Тестировщик видит, что ошибка зависит от окружения
• Разработчик понимает воспроизведение
• Все получают полную картину

Шаг 3: Категоризация проблемы

Если конфликт остаётся, категоризирую, что произошло:

Вариант А: Реальная ошибка в коде

• Разработчик воспроизвёл bug
• Оба согласны, что поведение неправильно
• Нужен fix в коде
• Решение: создаём bug ticket, планируем fix

Вариант B: Ошибка в требованиях/понимании

• Тестировщик проверял не так, как задумано
• Разработчик и я согласны, что текущее поведение — правильное
• Решение: обновляем тесты, документируем требования

Вариант C: Edge case/неполная реализация

• Ошибка существует, но в специальном сценарии
• Разработчик его не предусмотрел
• Решение: обсуждаем, важен ли этот сценарий, если да — добавляем в backlog

Вариант D: Окружение-специфичная проблема

• Ошибка существует только на staging, а на production нет
• Вероятно, данные или конфиг отличаются
• Решение: синхронизируем окружения или обновляем test data

Шаг 4: Задаю правильные вопросы

Тестировщику:

• "Когда вы последний раз очищали кэш?"
• "Это воспроизводится на чистом браузере/инкогнито?"
• "Может быть, это зависит от порядка шагов?"
• "Это блокирует основной функционал или edge case?"

Разработчику:

• "Что изменилось с момента последнего успешного теста?"
• "Есть ли рейс-кондишн (race condition) в коде?"
• "Может быть, необходимо очистить БД/кэш?"
• "Может ли это быть проблема браузера (совместимость)?"

Шаг 5: Привлекаю факты в виде логов

Если спор продолжается, смотрю:

• Браузерные логи (F12 → Console → Errors)
• Серверные логи (backend logs, ошибки 4xx/5xx)
• Network tab (какие запросы отправляются, какие ответы)
• Database logs (изменились ли данные)

Логи не лгут. Они показывают истину.

Шаг 6: Документирование решения

Как бы ни разрешился конфликт, я документирую:

Bug ID: BUG-123
Статус: Resolved

Исходное утверждение: Кнопка "Сохранить" не работает

Анализ:
- Тестировщик: ошибка воспроизводится всегда
- Разработчик: не может воспроизвести
- Совместная сессия: ошибка возникает, если НЕ очистить кэш

Корневая причина: В браузерном localStorage были старые данные

Решение: 
- Добавляем очистку localStorage при миграции версии
- Обновляем документацию по подготовке тестового окружения
- Добавляем этап "очистки кэша" в чек-лист перед тестированием

Вывод: Проблема решена, улучшена документация

Принципы при разрешении конфликта

✓ Остаюсь объективным — не беру никакую сторону без фактов

✓ Слушаю обоих — иногда прав тестировщик, иногда разработчик

✓ Ищу первопричину — часто конфликт не в коде, а в понимании требований

✓ Документирую — это помогает избежать повторных конфликтов

✓ Вовлекаю логи — факты важнее мнений

✓ Предлагаю совместное решение — покажи мне, что ты видишь

✓ Защищаю обе стороны — задача BA не выбрать сторону, а найти правду

Частые причины таких конфликтов

• Неясные требования (оба по-разному понимают, что должно быть)
• Проблемы окружения (тестовые данные, конфиг, кэш)
• Race conditions (тестировщик повторяет шаги быстро, разработчик медленно)
• Браузерные несовместимости (работает в Chrome, не работает в Firefox)
• Версионирование (тестировщик проверяет старую версию)

Вывод

Как Business Analyst я медиатор в таких конфликтах. Моя роль — не судить, а:

1. Собрать полные факты
2. Воспроизвести проблему независимо
3. Найти корневую причину
4. Задокументировать для будущих итераций
5. Улучшить процесс, чтобы это не повторилось

Часто оказывается, что обе стороны правы, просто говорили о разных аспектах одной проблемы.