Как QA договариваться с разработчиком: «это не баг», приоритеты и тон без войны

Найти баг — половина дела. Вторая половина — сделать так, чтобы его починили, не превратив рабочий чат в окоп. Именно на общении с разработчиком спотыкаются многие сильные технически тестировщики. Разберём, как договариваться, а не воевать.

«Это не баг, это фича»

Классический ответ, на который нельзя реагировать эмоциями («нет, баг!»). Верни разговор к объективной опоре:

К требованию/спеке. «В критерии приёмки написано X, поведение — Y». Если расхождения с требованием нет — возможно, ты прав, что это не дефект.
К ожиданию пользователя. Если спеки нет: «пользователь вводит корректные данные и получает ошибку — это ожидаемо?». Часто «фича» не проходит проверку здравым смыслом.
К договорённости. Если реально спорно — не тяни канат, а вынеси решение туда, где оно принимается (PO/аналитик): «давай уточним у Х, каким должно быть поведение».

Цель — не «победить», а зафиксировать: это ожидаемо или нет. Иногда «не баг» — правда, и это нормально.

Хороший баг-репорт снимает половину споров

Больше всего трений рождает плохой репорт. Хороший — почти не оставляет места для «у меня не воспроизводится»:

Шаги воспроизведения — по пунктам, с конкретными данными.
Ожидаемо / фактически — раздельно и явно.
Окружение — сборка/версия, ОС, браузер/девайс, аккаунт, данные.
Доказательство — скриншот, видео, лог, трейс, номер запроса.
Частота — всегда / иногда (тогда добавь, при каких условиях).

Репорт без «ожидаемого» — это не баг-репорт, а жалоба; такой законно отфутболят.

Severity ≠ Priority

Частая точка конфликта, потому что путают два разных измерения:

Severity (серьёзность) — техническое влияние: упало приложение = высокая, даже если экран видит один человек в год.
Priority (приоритет) — как срочно чинить с точки зрения бизнеса: опечатка на главной для миллиона юзеров может быть срочнее редкого краша.

Твоя зона — честно оценить severity и описать влияние. Priority обычно решает не тестировщик единолично (PO/лид, с учётом бизнеса). Не продавливай «критично» там, где технически это minor — подорвёшь доверие к своим оценкам.

Тон: «сломано поведение», а не «ты сломал»

Баг — не обвинение разработчика, а факт о продукте. Формулируй нейтрально:

✅ «При отправке формы с пустым email — 500 вместо валидации».
❌ «Ты опять не проверил email, всё падает».

Факты, не оценки. Без «опять», «как обычно», «сломал». Разработчик, которого не атакуют, чинит охотнее и быстрее — а ты не тратишь репутацию на эмоции.

Когда «у меня не воспроизводится»

Это не «ты не так смотришь». Чаще всего — разница в условиях. Разбирайтесь вместе:

Сверьте окружение: версия/сборка, данные, фича-флаги, роль/права, кэш.
Дайте точные входные данные и аккаунт, на котором воспроизводится.
Приложите видео/трейс — иногда видно, что шаги отличаются.
Если баг плавающий — так и напишите (флаки/гонка), не выдавайте за стабильный.

Совместная позиция «давай найдём, почему у нас по-разному» работает; позиция «у меня-то работает / а у меня-то падает» — нет.

Эскалация без «стука»

Порядок важнее эмоций:

Сначала — напрямую к разработчику, спокойно и с доказательством.
Не сходится в приоритете/оценке — выноси на лида/PO как вопрос решения, а не жалобу: «есть спор по severity/приоритету, нужно решение».
Формулируй риск, а не обиду: «если не чиним — вот что увидит пользователь/бизнес».

Эскалация — это про снятие блокера через того, кто решает, а не про «пожаловаться на человека».

Выбирай битвы

Репутация и доверие — ограниченный ресурс. Не бросайся на амбразуру из-за каждой опечатки.

Крупный риск (данные, деньги, безопасность, падение) — стой до конца.
Мелочь — зафиксируй в трекере и отпусти; вернётесь, если станет важно.
Тот, кто спорит по делу и по-крупному, весомее того, кто воюет за каждую запятую.

Коротко

QA не «побеждает» разработчика — вы вместе решаете, ожидаемо поведение или нет.
«Это не баг» разбивай не эмоцией, а требованием/ожиданием пользователя.
Хороший баг-репорт (шаги, ожидаемо/фактически, окружение, доказательство) снимает половину споров.
Severity (техвлияние) ≠ Priority (срочность для бизнеса); приоритет решаешь не ты один.
Тон: «сломано поведение X», а не «ты сломал»; факты, не оценки.
«Не воспроизводится» — разбирайте окружение вместе, а не бодайтесь.
Эскалируй порядком (разработчик → лид/PO) как риск, а не жалобу. И выбирай битвы.