I'll give an example for why the original author of the code should write the test. Say you write a sort and for performance reasons you use a different algorithm beyond collection size 100. This is prone to bugs around collection size 100. Your test needs to shed light on this dark corner. A QA generalist can't know that. They write some generic test cases. Size 0, 1 and 2 since they are inherently dark corners. Then some medium size and some large collections. They'll likely miss the 100. And the bug that's there for size 99.
You need both and ideally the original author writes the test and somebody else reviews the test thoroughly. That reviewer should have an intimate understanding of the spec you are implementing.
The more formal that spec, the less need for that external reviewer since the less ambiguity there is leaving room for missunderstanding. In a perfect world, the spec is completely formalized and instead of a test that shoots in the dark, you'd write a formal machine-verified correctness proof, automatically covering all cases. Then you would not need that external reviewer and could just have the programmer do it by themselves.
You need both and ideally the original author writes the test and somebody else reviews the test thoroughly. That reviewer should have an intimate understanding of the spec you are implementing.
The more formal that spec, the less need for that external reviewer since the less ambiguity there is leaving room for missunderstanding. In a perfect world, the spec is completely formalized and instead of a test that shoots in the dark, you'd write a formal machine-verified correctness proof, automatically covering all cases. Then you would not need that external reviewer and could just have the programmer do it by themselves.