Yes.
A developer writes the unittest te ensure that the "unit" does what it suppose to do. A QA person test the whole application.
Besides, a unit test is code, and developers write code. Most of the times QA engineers don't write code.
Generally, I think it is a bad idea. Unit tests guide the developer to write modular (and therefore useful, reusable) code because their code needs to work with both the production system and the test code.
The developer has to write the unit tests. Otherwise it is like the developer doesn't have to care about the quality. In addition, unit tests help the developer to write better code.
Maybe you've heard about TDD? "Test Driven Development" is a really a good practice for development. Its main purpose is to develop unit tests before write the actual code (which is a strange thing, when we start using TDD, I admit)...
This depends on how you plan to implement your testing workflow.
Bad:
The developer writes his code and the other person then tries to add unit tests to test this code. The problem here is that the developer will not care to write code that is easily testable. Much time may be spent either trying to adapt the unit tests to the badly testable code, or time is wasted by refactoring the original code afterwards to be better testable.
Good:
Another person than the developer writes the unit tests and the developer writes his code afterwards, trying to get all those tests on green. This may be a bit awkward at first because some basic interfaces have to exists to implement the tests against, but the basic interfaces should be defined in the design doc, so the developer can prepare the interfaces for the test developer. The advantage is, that the test developer tries to write as many tests he can think of independent of the real implementation, while the original developer would have written tests depending on the internals of his code, not imagining other problems. Else, he would have warded against them in his implementation already.
The "good" approach worked well on two of my projects, but we used an untyped language (Smalltalk) where we only needed to agree on the class names to get the tests running. In Java you have to implement at least an interface so call functions.
There's a subtle but important difference between the intent of unit tests and QA tests: QA testing validates functionality; unit testing validates design. That is, the outer view contrasted with the inner view of the product.
QA people are unfamiliar with the internal design of the product, which is intentional because they have to mimic the user's perspective. Developers, on the other hand, know intimately the inner workings and it is to them a mechanism to validate design would be meaningful, if at all.
Hence, it is absolutely natural that developers not the QA folks write unit tests.
Having a person dedicated to unit-testing in a team can seem interesting at first sight ; as he will review all the code. This also would alleviate the risk of having one developer making the same error in the production code and in the unit tests.
However, in order to be unit-tested, the code has to be testable ; what can he done when the code it receives is untestable ? Rewrite it ? Refactor it ? Without Unit Tests ?
In short, I think this would not be such a good idea.
I don't think it would be bad, I just don't think it would be possible. If the code wasn't written test first it probably isn't testable.
Is the QA person doing to refactor the code to make it testable?
If so, then that's fine, and I don't care what their title is. If they're not, then I doubt they'll be successful.
I think it's generally bad for QA to write unit tests. Unit tests are code, they are tightly related to how the dev code is constructed. For this reason, the developer knows best what tests would make the most sense.
On the other hand, I believe QA should stay as close as possible to unit testing. QA needs a good relationship with the dev and try to understand the code design. Why? When a developer is writing unit tests, the focus is still on development, not testing. You cannot trust (not in the bad sense) a developer to come up with the best test cases and that she has good coverage. Since QA is specialized in testing, it may be a good idea to keep QA and dev as close as possible during unit testing.