👩‍💻 Тестировщик vs разработчик: как не превратить баг в конфликт

Кажется, почти каждый тестировщик хотя бы раз слышал:

▪️ «У меня работает». ▪️ «Это не баг». ▪️ «Пользователь так делать не будет». ▪️ «А зачем ты вообще туда нажала?» 😄

А разработчик, скорее всего, хотя бы раз получал баг со смыслом: «Ничего не работает. Срочно исправить!»

Так и начинается маленькая QA-драма.

Но вообще-то у тестировщика и разработчика одна цель: выпустить работающий продукт. И несколько привычек помогают не превращать обсуждение дефекта в битву.

1. Обсуждать проблему, а не человека

Не «ты сломал авторизацию», а:

👉 «После обновления при вводе корректного кода пользователь получает ошибку».

Мы проверяем продукт, а не качество работы коллеги.

2. Приносить факты

Чем меньше в баг-репорте загадок, тем проще всем.

Хорошо, если есть:

▪️ шаги воспроизведения; ▪️ ожидаемый и фактический результат; ▪️ окружение; ▪️ логи; ▪️ запрос и ответ API, если они относятся к проблеме; ▪️ скриншот или видео.

Тогда обсуждение «у меня работает» быстро превращается в поиск причины, почему здесь не работает.

3. Не начинать с обвинения

Иногда странное поведение действительно оказывается не багом.

Возможно, изменились требования, тестовый стенд нестабилен или мы сами что-то упустили.

Поэтому вместо:

❌ «Ты неправильно реализовал»

лучше:

✅ «По требованиям ожидаю такое поведение, но сейчас получаю другое. Давай сверим?»

4. Не спорить ради победы

Если разработчик считает, что это не дефект, полезно вернуться к требованиям и пользовательскому сценарию.

А если требования допускают разные трактовки — это уже не спор QA и разработчика, а серая зона, которую нужно уточнить вместе с командой.

5. Помнить, что вопрос «почему?» — не всегда нападение

Разработчик может спрашивать, зачем нужен конкретный сценарий, чтобы разобраться в проблеме.

Точно так же комментарий тестировщика не означает: «Ты плохо написал код».

Иногда конфликт появляется не из-за самой проблемы, а из-за того, как мы прочитали сообщение коллеги.

Мне нравится простое правило:

не доказывать, кто виноват, а вместе выяснять, что произошло.

Потому что хороший баг-репорт заканчивается не фразой «я же говорила», а исправленной проблемой 🙂

А какие фразы из диалогов QA и разработчиков встречались вам чаще всего? 👀

Автор: Кристина Кузнецова