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

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.

Answer 2

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.

Answer 3

Where I work we all do unit testing but not on your own code. You still write testable code and will still focus on quality. Developers become more familiar with areas of the software they are not working on. Everybody knows the code base and can take over from other developers.

For a non developer of the software to write unit testing I agree with all the other answers. It is a bad idea.

In your question you said that you had one person doing the unit testing. Good unit testing requires a lot of effort depending on the test coverage required. It is anywhere from 50% to 100% of the level of effort of the development team. One person testing a lot of developers code will be totally overwhelmed.

Answer 4

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.