The only thing I want to add to Charles is, that the last sentence gives me the feeling of having to decide for the team, what the should do as "good engineering practices", but for me it is the team, that should come up with those practices
Good point, Phillip. When I said "Scrum implementer," I was referring to the Scrum team as implementers, not any one person. In the specific case of testing, I would say that it's really up to the Dev Team as to how to handle it.
but I wonder how common it really is that this is driven by the team.
This one is a bit tricky. The Scrum team, if they are held accountable for quality and bugs escaping into production, will often drive better technical and testing practices. It can also come from outside of the team as the organization realizes the lost business value due to low quality practices. In the end, though, the org needs to give the Scrum team enough room to self organize and specify their own release dates and such so that they can take the time to meet and/or improve their Definition of Done. If the org continues to hammer at the team for missing deadlines, then quality is usually the first thing to get sacrificed. In fairness to the org, the team needs to get better at proposing realistic release dates, too. OTOH, if the org doesn't listen to the team, then the (brow)"beatings will continue until morale improves."