When I worked at MSFT as a developer in the early 2000s, we had dedicated test developers who wrote tests. You wrote your code and checked it in after a code review and as long as it passed the integration tests, the test developers wrote their (what would now be called) unit tests and checked them in to make sure someone else didn't break your code.
I think writing your own tests gained favor in the early/mid-2000s with the "extreme programming" and TDD movements (https://en.wikipedia.org/wiki/Test-driven_development)
What are "union rules"? Each union is free to bargain their demands collectively with the employer. If your members think such a rule is stupid, they won't demand it. But your lack of knowledge and disdain of unions is noted.
Yes, this is exactly how we QA in fields where software errors can cost lives.
From a personal perspective, I find that trying to design tests as the developer of the code to be tested is fundamentally difficult -- I have embedded assumptions around the functionality of the code that make it cognitively difficult to fully envision complex failure scenarios. Some of the best test producers I've worked with have had no development background at all.
It's horrendously redundant and wouldn't be applicable to most software, but it does work well; when bugs are picked up by the third or fourth layer of testers, which happens from time to time.
Is this based on seniority, as in the new guys have to write the tests? That way you would at least have some experience with how to code in an easily testable fashion.
Until we come to a mature understanding of the place that unions have in our working economy, I hope we never see this kind of bureaucracy form in our profession.