I don't want to speak for all testers. I'm a tester, though, so I'll speak for me.
I'm someone who has to span the entire project. Someone who can use their time to collect contextual information, learn the users and their habits/patterns/preferences, talk with support, influence design by testing the documents, etc.
I study science, experimentation, epistemology, general systems thinking, metrology, and much more, as well as research what there may be out there to learn to improve my testing.
I also practice my testing skills. Focus/defocus, progressive mismatch, software testability heuristics, reporting, whatever they may be. I understand coverage models, quality criteria and environmental context.
I take a critic's stance. I'm free of many of the assumptions that get installed when coding software. I'm not beholden to the idea that I've made something to work, so therefore it works. I'm not incentivised to push forward, I'm incentivised to critique the push to see it made better. I can challenge "safe" assumptions freely, and be creative and maybe even glaringly obvious in a way that the skilled author was too focused to see. Sometimes I work with developers and ask them questions about their code or their diagrams, upsetting and invalidating their assumptions about various abstractions of meaning in a useful and anti-fragile way.
I'm also free of much of the personal investment in the work. It's no bother to me if there are problems and issues with the project, it's only a bother to me that people who need to know don't know that. I'm free to take a sledgehammer to their beloved creation, or sneak in and cut the breaks in a way the documents suggest I should not just to see what happens. A developer can do this, but it's easier for me.
I don't consider myself replaceable by a developer. I have a huge amount of respect for developers, who do a difficult enough job as it is, and I strive to support them in what they do, make them appear and feel better, and make myself invaluable to their efforts. I would never give them another full-time job, nor ask them to be interested in what I love.
So maybe you could get developers to replace testers. I don't know those testers, but if those testers are endeavouring to make themselves expert craftspeople then I think they have value beyond what developers have the time, energy or passion to be doing. What the value is worth to a company is not a decision for me.
I think it's absolutely normal that developers do testing. Most people who ever interact with software do software testing. Developers do it when they compile something whether they want to or not. I think that creating close-to-code checks and performing testing that leverages their knowledge and understanding and tool expertise is a good idea. The problem is that the ability to do testing at all and the ability to do it very well, in a way that is independently valuable, are two different concerns with different skillsets and live in different paragraphs of the social contract.
It's very appealing to get rid of testers, and there are plenty of testers who begin to offer less for their price tag as software development evolves, so I understand the push to squeeze some savings out and discover/pretend nothing is lost or that the cost/benefit analysis meets a target. There are bound to be contexts where expert testing isn't valuable enough for the price. There's a raft of misinformation about what testing can and cannot do, what it's for, and how it can be measured. Some people think that regression checks are equivalent to testing. Some people think that requirements documents can be complete. So I guess I'm saying that when we say "testing", I think it's hard to come to some mental concept we all share.
While I'm here, if we're going to tell developers to do all the testing then why don't we just ask them to write code without bugs in it?
