Почему конфликтуют тестировщики и разработчики, и как этого избежать

[Stan_1]

Лайфхак: введите тестировщиков в команды разработки. И они быстро начнут работать на одной волне.

[aamonster]

(читая заголовок) А почему, собственно? Никогда не видел конфликта.

[Nialpe]

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

[aamonster]

"Когда по багтрекеру начинают оценивать работу программиста – он превращается в тыкву".

[Quality_department]

Я бы выделил здесь именно психологический аспект:

"Налицо психологический эффект: тот, кто сообщает о баге, как бы нависает в образе более компетентного специалиста."

"Встреча со специалистом по тестированию сама по себе несёт скрытый мотив — «ты не профи»."

На как показывает практика, чем опытнее специалист, тем менее он подвержен подобным искажениям.

Как правильно заметил, Stan_1, если все члены команды преследуют одну цель - производство максимально качественного и полезного продукта, этого можно избежать.

[shprot6]

Забавно, всегда считал что у разработчика и тестировщика общие цели, разные они могут быть только у малоопытных специалистов, не понимающих что они делают. Цель - качественный продукт. Для меня, как для разработчика, наличие в команде компетентного тестировщика - обязательное условие. Тут появляются две проблемы, часто QA инженеры в силу непонимания системы выдают за ошибки то что является частью бизнеса, при этом тратят не только свое время, а ресурс всей команды. Вторая проблема что тестировщики часто занимаются не тем что должны делать, не тестированием а чем угодно кроме, что в итоге приводит к пропущенным ошибкам, которые попадают в прод-среды, где, как известно, цена исправления выше на порядки. Кроме этих двух проблем разногласий у серьезной команды разработки и тестирования быть не могут, и лично у меня, все претензии к QA всегда были и будут только в рамках этих двух пунктов, а со всем остальным надо бороться повышая свою грамотность и компетенцию в независимости от стороны "конфликта". Ну и еще один момент, довольно часто подобные проблемы появляются даже не из-за уровня знаний или квалификаций специалиста, а из-за менеджмента, это тоже надо учитывать и уметь говорить "нет" руководству если их решения наносят прямой ущерб планам и задачам команд и компании в целом.