Unit tests by a QA Engineer

Question

As I understood from some Q&A sessions (see this and this), unit tests should be written by developers.

At my previous workplace we tried to give this task to a QA Engine

Answer 1

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 to call functions.