Remember that the goal of an agile team is to be self organising. To achieve this they have to have the opportunity to identify their own faults and come up with their own solutions.
It can be very tempting to step in and guide the retrospective. But this runs the risk of removing the responsibility from the team to fix their own problems, which can be counterproductive. There is nothing wrong with suggesting solutions, but you want the team to spot the problems.
As a Scrum Master, when I identify problems I will typically try and find some way of highlighting them. For example, if the team is splitting stories across time-boxed sprints I would start to track this and make the results visible. Usually the team starts to address the problem once they recognise it.
Reading through your list, it surprises me that none of these items have been mentioned in the retrospective. For example, has the tester not commented on the the way the QA work is being divided up? Has nobody mentioned that they are breaking tasks across the time box?
Perhaps the format of retrospective you are using does not encourage team members to speak out? This is one of the reasons a common approach to retrospectives is to have the team members write their feedback independently at the start of the retrospective. Then the team as a whole discusses each item in turn. This ensures that everybody gets a voice.