I agree that there's some tension in the jobs, but on healthy teams devs and QA are allies.
Every bug report should include three things:
Clear steps to reproduce the bug.
A description of the expected behavior.
A description (with screenshots) of the actual behavior.
On those occasions when I've seen friction develop between devs and QA, one of those three things is usually faulty:
The steps to reproduce the bug were unclear, so the dev fixed a bug, but not the bug that QA intended, so the fix fails QA.
The expected behavior is missing, so the dev fixes it in a way that QA doesn't like, so the fix fails QA.
The actual behavior is missing/unclear, which leads to devs not being sure what they should change/fix. (If the dev can't reproduce the bug, they also can't be sure they fixed it.)
When the steps, expected, or actual is missing, it's totally worth the extra effort to get up from my desk and go talk with the original reporter and get things clarified. I get to know my coworkers better, we stay on good terms, and my tickets pass QA on the first try... most of the time. ;)
I agree that there's some tension in the jobs, but on healthy teams devs and QA are allies.
Every bug report should include three things:
On those occasions when I've seen friction develop between devs and QA, one of those three things is usually faulty:
When the steps, expected, or actual is missing, it's totally worth the extra effort to get up from my desk and go talk with the original reporter and get things clarified. I get to know my coworkers better, we stay on good terms, and my tickets pass QA on the first try... most of the time. ;)
Great comment!
A good communication between Dev and QA is very important for things to work properly.