I have experience of working with a team where developers didn't want to do manual testing because they considered it to be wasting of their time - QA work (especially manual testing) doesn't improve their development skills and knowledge.
What should a Scrum Master do in such a situation?
Testing should not mean executing tests (I expect that's what you mean by manual testing). The main business of testing comes in designing, developing and curating automated tests, analysing and understanding defects and fixing them. These are absolutely "development" tasks because development can't be complete without testing. Doing these testing activities does improve developers' skills and knowledge and ultimately makes their lives easier because it's generally quicker to debug a problem when you have code that reproduces the issue than if you have to rely only on someone else's description of a problem. I wonder if the concern you are describing is due to insufficient test automation. Maybe you should encourage the development team to build a better test automation framework.
Modern TDD and BDD are architectural and programming concerns. In fact, I'd go so far as to say that any developer who hasn't embraced best-practice techniques like test-first design, continuous integration, DevOps pipelines, and so forth isn't really well-suited for most modern software projects.
Even if you discount my statement above as personal or professional bias, from a Scrum perspective there are no "Programmer" or "Quality Assurance" roles on a Scrum Team. Everyone but the Scrum Master and the Product Owner is simply a [Product] Developer. In fact, the 2020 Scrum Guide explicitly states:
The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies.
While the Scrum Team is certainly free to self-manage the team's workflows, treating programming and testing as separate concerns is generally a framework implementation smell. It simply doesn't lend itself to Scrum's collaborative model of whole-team product responsibility.
The X in the X/Y problem you describe is the organization's leadership and hiring practices. If the organization is hiring, encouraging, or retaining I-shaped people rather than T-shaped people, they are not actively supporting the Scrum framework.
Scrum won't magically turn a collection of individual contributors into a cohesive team that collaboratively self-manages; it simply provides a framework for talented and motivated people to apply their skills to a shared objective. This may be a good topic for your next Sprint Retrospective, but continuing problems with the skills or composition of the Scrum Team that can't be resolved internally should be made visible to senior leadership. Setting the right "tone at the top" for both company culture and personnel management are part of senior leadership's core responsibilities, so ensure that they have the information they need to make informed business decisions.
There is, almost certainly, a mismatch in expectations here. First, if you are practicing Scrum, the Scrum team is responsible for delivering an increment that meets the definition of done. There are no subteams - no such thing as the developer and tester from the perspective of who is responsible for the increment of work being done.
Next, there needs to be a clear definition of done that also makes clear what level of quality is expected from the work. If quality is separated structurally from development, it only makes the task of creating a working product harder.
Finally, is anyone actually committed to using Scrum? Did the team commit? If leadership made the decision, are they following through or is it a checkmark on someone's yearly plan? I've seen way too many scrum implementations where the real goal was for everyone to collectively agree they were practicing Scrum to meet some OKR while at the same time, changing nothing.
Now, there is a separate concern here - is the developer worried that working in this way will negatively impact his career? Whether he is right or wrong, if he is sincerely worried, then it is a valid concern. This is more of a coaching conversation. This is not about what Scrum says to do, but helping him be comfortable in his workplace. There are a lot of possible solutions to this, depending on his exact worries, but one might be for him to go on a few interviews and mention that in his current role, he is expected to work with test and chip in to get the increment of the product to a done state by the end of the sprint and see how that goes with the interviewers. This may help him feel like this change is a benefit, not a hindrance.
Your question itself raises several questions. If the developers are responding like this to the business need to test, there is probably a bigger problem.
The other answers here assume that you have a properly functioning scrum environment with automated tests, continuous delivery, and all the other modern hallmarks. Based on your question, I suspect the opposite.
From my personal experience, when you don't have a modern environment, you are stuck doing things the old way:
My suggestion is to talk to your programmers. They might already understand the problem, but you aren't asking the right questions.
A simple operational solution is to require developers to check in their unit tests along with the code. No unit tests, no code review. No documentation, no code review.
This does not address the cultural issues, though.
It really is that simple. Every dev I know (and I include myself!) hates testing. But every good dev recognises the need for it, because we all make mistakes. And anyone not yet skilled enough to recognise the need for it, pretty much by definition, is more likely to need it.
It's no-one's idea of a good time, sure. But it's necessary.
QA work (especially manual testing) doesn't improve their development skills and knowledge.
Since when was that something you were guaranteed? If you do get that, great. But often you just have to get the job done.
