5 story point ( 3 for Dev and 2 for QA ) - do you keep track of QA and Dev story point split up in each story
The Developers are collectively responsible for making their own estimates, because they are jointly accountable for ensuring their work will be Done.
Why then would they wish to "split" and "track" their estimates in the way you describe? What purpose would this fragmentation of their estimates serve? Might it reflect a lack of consensus, teamwork and collective ownership?
Perhaps it would make more sense for them to monitor their Sprint progress in terms of a technical plan. A task burndown, for example, is commonly used for this purpose.
Scrum does not care about job titles. It cares about the roles of Product Owner, Scrum Master and Developer. A role describes responsibilities that need to be accounted for in order to produce a result. If your organization uses different job titles matters not, as long as the role responsibilities are being covered. Scrum also does not provide process as it is a framework. So how your organization chooses to organize the work is also outside of Scrum guidance.
So, if I apply that knowledge to your original question, I am reading you ask this question instead.
How do you use Story Points to keep track of all the different types of work that is needed to have an item reach Done?
Since Story Points are not referenced in the Scrum Guide and the Scrum Guide does not provide instructions for how a team's process should work, I'll say that you should be asking your Scrum Team that question because they are the only ones that can provide an answer.
However, the Scrum Guide does provide some ways to ensure that they correct work is being done.
Definition of Done
This definition provides common understanding within and outside of the Scrum Team as to what it means when the Scrum Team says "this piece of work is Done". It can contain statements such as "all new code has been tested" or "all new functionality has been verified to work correctly and no existing functionality has changed in ways that were not intended". Those kind of statements help to communicate that a level of testing is being undertaken while the code is being changed.
This goal provides guidance to the Scrum Team about why the current Sprint is happening. It also allows people external to the team to understand the same thing.
This is from the Scrum Guide.
The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).
The "how" will provide enough detail for individuals to understand what work is being undertaken. However, since that is a process related question, the Guide does not provide anymore guidance and it is up to your Scrum Team to decide how that will be accomplished.
My answer would be No. An individual is never an owner of a Story or PBI, they care collectively owned by the Team.
If individuals start keeping track of only their individual estimates would they not feel responsible only for their part and not the whole story or PBI collectively?
Of course Dev and QA can get together to estimate the length of a Story or PBI but they have to be collectively responsible for the estimate.