[ original gist 3 June 2013 ]
The point of agile is lost when teams fixate on roles and responsibilities. Fixed roles (“dev”, “qa”) harm you in the long run – and the long run is always up sooner than you think.
That’s a noisy prelude to my answer to the question: Should QA Write Unit Tests?
Now, I’ve never run into this – usually it’s Dev & QA siloed away from each other – then writing all their own tests, which duplicates some effort – if dev writes tests at all – with QA running their own tests late in the cycle, finding issues late, etc.
I’m way into TDD, but prefer to work rather than compete with QA. Dev should do some ATDD along with QA anyway. So, if QA wants to – or must – write unit tests in code and hand them over to Dev, they’ve actually done some thinking for me – stuff I can correct and hand back to them with actual working code. I can see that leading to much better collaboration over time, as long as Dev doesn’t mean just coding and QA or test doesn’t mean just run scripts
Whatever you’re doing, your team should be flexible. As long as you are delivering what should work and preventing code rot, I see nothing wrong with that arrangement.