TLDR: Optimize for throughput and your people will become T-shaped.
First of all, I should address
Is this the right approach?
To which my answer is "Don't ask strangers on the internet. Try it and see." Agile incorporates two concepts that are relevant here:
- Attempt-inspect-iterate cycles
- Self-managing Teams
Regarding the first... try it and see. Make sure you have some measurable baseline, such as throughput (the time it take to get an individual ticket from 'In Progress' to 'Done'). Then try your suggested change for a week or three. Then measure again and inspect.
Because of the second, though, I would strongly suggest against just forcing this down on the Team. The 'try and see' approach should help this somewhat, but you'll still need to address their concerns. Which brings me to...
Developers [...] need their code merged into the develop branch at the earliest so their next feature [...]
To which my suggestion would be... don't immediately jump onto the next feature. The feature you just 'finished' may be done, but it's not Done yet! Instead of jumping to something new and cramming more work in-progress, focus on getting that one ticket all the way to Done first.
Now, yes, the non-QA devs don't have experience with
microservice integration and e2e tests
but... so? They can learn. One of them can pair with the QA while another researches on his/her own and the third can work on an unrelated pet project (for example). By including slack time (optimizing for throughput rather than utilization), you focus on getting individual tickets Done while allowing your team members to sharpen their saws. In this way, over time, your developers will gain new skills (become T-shaped) and may be able to take on some of the QA tasks themselves, thereby allowing the team to get tickets from In Progress to Done as fast as possible.
Which in the end is what you want, isn't it?