It is habitual on the current called "agile" teams to have transversal responsibilities about every task-feature-fix-whatever that wants to be added into the team products. But I'm also surprised about how different this concept is interpreted by the different team members.
Originally, even on "agile" called teams, we could have a mini-waterfall process on a sprint, where the PO-PM will define a small task to be completed quickly. Developers will code the task according to the defined requirements, struggling or not with not really well defined requirements, QA will test the task using the defined requirements, the developed feature and, probably, would have been defining test cases to fill the missing gaps between requirements and implementation details. When everything was developed and tested, this could be deployed, and SysOps would take care that the task is properly placed on production.
The world transversal in this context is what brings the problem to the table. IMHO, a transversal team means that it contains all the resources to bring value to the company's product. So, we don't need to wait to requirements, development, QA seals of approval, DB migrations or deploy trains to be able to deliver new features. Anything that is needed is on the team. If the team is placed on a big company, it acts as a small company inside that big one.
Team members would have a big picture context about what the team is doing, but it does not mean that everyone on the team has every atom of knowledge that every member of the team has. The responsibilities that define a position on a team are responsibilities by themselves because require a degree of knowledge that makes difficult to a single member to be performant on two of them at the same time.
Thinking on transversal teams as a way of accelerate deliveries because "everyone should know about everything", then, everyone is capable of everything is too idealistic when projects become too large. The most idealistic version of this one is handle projects through a simple member.
Based on the living context, given a small list of requirements, develop, test and deliver a feature can be troublesome given the different mindsets needed for everyone of the steps.
- PO perspective: What problem are we solving? What are we solving with this? The recipient of the feature would have its problems solved?
- Developer perspective: How the problem should be solved? How can I assure that the needed problem is properly solved?
- Tester perspective: Is the problem solved with the implemented solution?
Each one of this perspectives require a different mindset and usually each mindset polutes the other ones.
From a PO perspective, the big problem to solve is the WHAT. We have a situation that requires to define a solution, without really caring about the hows (but of course, taking care about the time of implementations).
From a Developer perspective: The big problem is to know HOW to implement a valid solution. The WHAT can be defined on collaboration, but the HOW it's his main responsibility.
From QA perspective: The big problem is to know if the HOW fits the WHAT.
It could be very difficult to define the WHAT, HOW and the fitting of both at the same time by the same person. And specialized roles for everyone of this perspectives would have more sinergy than a single one having the responsibility of both. The real situation typical "QA asks for 1 beer, 2 beers, -1 beers, ? beers on a bar. A customer asks for a bourbon and the bar sets up on fire".
Mindsets mind for every situation. Be at least sure that you keep them isolated.