Как остановить конфликт между QA и разработкой

Когда команда спорит о природе дефекта, это уже не техническая проблема. Конфликт тестировщика и разработчика — это столкновение мировоззрений.

Часто спор возникает не вокруг кода, а вокруг обязанностей. Тестировщик фиксирует отклонение от ожидаемого поведения, а разработчик видит код, который по своей задумке работает правильно. Это фундаментальный разрыв в ответственности и методологии. Моя задача — научиться «гасить» это напряжение до того, как оно перерастёт в политический спор, который замедляет релиз в разы.

Конфликт дебаггинга и кодинга всегда провоцируется одной из трех зон.

Первый триггер — это «зона восприятия». Тестировщик описывает ситуацию, используя язык пользователя («Я пытался оплатить картой X в мобильном приложении, и мне показало сообщение Y»). Разработчик автоматически переключается в язык системы («Контроллер A вызвал сервис B, который вернул код ошибки 500»). Разница в уровнях абстракции делает диалог невозможным, поскольку стороны говорят на разных языках. Конкретика: В одной из продуктовых команд мы столкнулись с попыткой воспроизвести сбой только на последней версии Android. Разработчик требовал логи, которые могли бы «доказать» ошибку на стороне клиента. Я остановил спор, запросив не логи, а полную запись процесса на целевом устройстве (например, через Screen Recording или CDP), чтобы создать общее поле визуальных фактов, которое нельзя интерпретировать в одностороннем порядке.

Второй триггер — «конфликт допущений». Происходит, когда не совпадают границы тестирования. Тестировщик предполагает, что данная функция должна работать в контексте, который не был явно прописан в требованиях. Разработчик же опирается на то, что написанное — и это и есть истина. Конкретика: В банке возник спор о проверке платежа через внешнюю систему. Разработчик настаивал, что проверка ограничена по лимиту транзакции, а тестировщик настаивал, что логику нужно проверять через граничные значения, которые «могли возникнуть». Вместо спора мы составили таблицу «Ожидаемое поведение в разных контекстах», которая формально вывела из дискуссии все допущения и заставила команду прописать, что именно считается «нормой», а что — «крайним случаем».

Третий триггер — «передача ответственности». Это самая опасная форма спора, где стороны начинают защищать свою работу, а не продукт. «Я сделал всё, что мог, проблема в другом конце» — это мантра. Конкретика: В телекоме разработчик завершил модуль авторизации, заявляя, что он идеален. Тестировщик обнаружил, что после успешной авторизации система выбрасывает сессию. Обвинение перешло с кода на команду. Я перевел фокус обсуждения не на то, кто виноват в срыве сессии, а на точный момент и условие, когда сессия обрывается, зафиксировав это как единый технический артефакт, а не как «погрешность кого-то».

Чтобы конфликт не вышел из-под контроля, нужен строгий алгоритм, который заменяет эмоцию на факты.

Мой подход всегда включает четыре этапа: Факт → Воспроизводимость → Критерий → Решение.

Сначала мы пасуем над эмоциями и фокусируемся только на факте. «Что произошло?» — не «Кто виноват?». Затем — воспроизводимость. Как добиться этого эффекта, чтобы он случился снова? Должен быть один или набор действий, которые гарантированно приводят к результату. Если воспроизвести нельзя, то пока это просто гипотеза. Третий шаг — критерий. Что по факту должно произойти? Это не функция «быть красивой» или «работать хорошо», а измеримое, изменчивое и контролируемое состояние системы. Это якорный критерий, от которого исходит вся правда. Последний шаг — решение. Определяем, какие элементы в системе противоречат критерию и кто за них отвечает за исправление.

В такие моменты очень помогает «охлаждающая» фраза. Я использую: «Давайте сейчас отложим обсуждение по вине, и сфокусируемся на поведении системы». Эта фраза моментально меняет вектор с человеческой драмы на инженерный анализ, возвращая людей в рабочее состояние.

Главный вывод из этого процесса: я никогда не выступаю «за тестировщиков» и не «за разработку».

#QA #qaсетка #баг #багилифича