I didn't say that and that's not true. I've never worked in a place where the QA department "wrote tests", no. Probably this is confusion as to what "writing tests" means.

For example, I worked for five years at Google, the American search engine. You, the engineer, were responsible for writing your own automated testing. QA was responsible for using the product as a human would and reporting user-facing bugs as issues.

I had little interaction with them directly, so they might be writing some sort of automation, but it certainly didn't give that impression. Certainly they never created any tests I could re-use, which is what I mean by "writing tests", as opposed to "testing".

In the previous place I worked, much smaller, it was rather different - there was one QA guy who was a genius at breaking things who sat a few feet away from us. Again, though, his job was simply to find problems, and then we, the engineers, would write unit tests to demonstrate them and prevent regressions.

I really am not sure how any other system would work. 90%+ of my non-trivial commits have unit tests, or at least, changes to unit tests - I write them as I write the code, because otherwise, how do I have any idea if my code would work? Generally just writing the tests exposes all sorts of flaws in my code as I go.

If I had to stop every time I needed a test and wait for someone else to do it, progress would be glacial. I wouldn't use it even if the facility existed: I have my reputation as a so-called 10x engineer to keep up!