The way we think about software testing and test strategy is important.
Here are 2 examples of mindmaps that are mentioning wurthy:
​
click to zoom in...  :)

Related: Test Methodology

Crux / klokhuis / Kern
Missing link
uitgangspunt
pre-conditie / voorwaarde(n)
Diepgang
Exotisch route (niche pad)
Kwinkslag
​samenhang van factoren en variabelen: correlatie

Goed idee? Twitter je aanvullingen met titel:     LEXICON: [woord] 

When at first, 100% of the Scrum stories were about the development process of the application in the sense of coding. Now with the QA process introduced especially the Product Owner has to take into account that some of the tickets for the refinement will be for progression of the software process.
That is a big change in work orientation for some of the ICT fellows.

Also, when QA is introduced more formally than in many cases there was "always some dude that actually tested the stuff", but he was never formal a QA/software tester. This means that there are persons with a ton of knowledge about the application, but the knowledge is in their brains, in the head.
But that doesn't mean that the newly introduced QA people don't need that knowledge, so there has to be reserved time to transfer that knowledge.
That reserved time must be something that is very firmly and certain, it should not be something optional.
Also, when it gets complex it should not be the case "this dude" says... oh let me check this quickly for you, so the story can be dragged to the 'done' column. NO! There must be(e) cross-pollination of knowledge! Knowledge transfer to the new QA('s).

More items related to software testing should enter the Sprints.

Next step is to Scrum poker those software process related items.
Bring them on the table.

What I unfortunately have seen a lot is that a QA asks for a certain functionality in the software to help the software testers check quicker for a certain correct functioning of a module or functionality. But that request gets shot down by the Product Owner (or others) because 'other things are more important'.
Then what you see is some recurring patterns.
1) When finally that request is met (coded and pushed into test environment(s), it is many times especially the users of the information system that really like the new functionality. (not only the testers that asked for it)
2) The requests are not fulfilled, but the nagging about the throughput time of the functional/regression testing starts in heavy amounts to enter the podium.

All in all, hiring software testers and/or a QA Manager in the company and thinking everything will work out just fine automagically is not a good idea.

You really have to do this aware and thoughtful!