A challenge in software development has long been the division between test and development.
You could do as Microsoft recently did (more or less abolished "test").. the jury is still out on whether that is what has caused the recent Windows 10 quality issues.
Or you could keep a tester/developer separation. Good luck trying to recruit top (e.g. your testers should on average be as smart as your developers) people for the tester positions unless you are Google/Facebook.
Either way, I think this is a really interesting issue.
It should be noted: some pieces of software are a lot easier to test by its developer (say, a compiler) than others (say a GUI).
A glance at a few (edit: random!) users' comment histories is enough to see that this intention (either way) is mostly orthogonal to the topics at hand.
I'm just more interested in calling out drudgery, propaganda, forced fanaticism of boring topics, and adding color
See also: "I'm just saying what everyone else is thinking."
I was referring to both people doing manual testing and doing development of automated testing in the case of Microsoft.
My understanding (from the outside) is a that substantial number of people at Microsoft who worked in those areas were made redundant. From what I could gather the goal was to make the majority of testing automated and have the self test systems be developed by the developer of the respective subsystem themselves.
All of the weird regressions I've seen with Win 10 myself (and read about many people experiencing) matches that story.
My feeling is that with something as complex as a desktop OS that needs to work with the a) the history of Windows releases, b) the history of Windows apps, c) the entire, insanely big spectrum of PC hardware released the past 5-15 years or so you do need an army of relatively highly competent people willing to do lots and lots of manual testing over and over and over and over and over ... again. And of course lots of people to build automated systems.. but you can't really get away from the manual aspect very easily.
You can think of it like the engineers behind rspec vs people who use it. Or the engineers behind Selenium, etc. They're engineers first and foremost and while you're free to have the opinion that this line of engineering is "meaningless and trite" at Google SWEs really appreciate the tools SETI teams build.
I think there's a certain amount of recursiveness in the way we look down our nose at test code; we don't like it, so we write code that isn't easy to test, which makes it even harder to write code that is testable in the next composition layer of the system. Repeat a few times and the test code gets pretty horrifying. But somebody needs to crack that nut.
Developers ought to be appreciative that there are people willing to do QA and test infrastructure for them.