If you want people to be able to handle a wide variety of situations, and tools, and so on, you need to give them exposure to a wide variety of situations, and tools, and so on. And, crucially, you also need to understand that they are not going to be very productive for some period of time after every move. You also need to understand that not everyone is going to be suited to be a generalist.
You also need to look at the way teams are structured. Is the plan to have a core group of people (including QA) working on each product, and then move other people around as needed? Or is the plan to let products lie fallow for a time, and then dump a bunch of people onto a product that hasn’t been maintained in a while?
If it’s the former, then you have a better chance of being able to have generalists, because they have an easy way to learn the product. If it’s the latter, you need to assume there’s going to be a very long period of learning required, and you need to be very, very sure that the product and development process was well documented. Having corporate guidelines/requirements about such documentation would be a good idea.
I may be in a somewhat unique situation, but I work on a product where components may not have been touched in twenty years. Having both institutional knowledge and very, very complete development documentation is a necessity in such cases, as otherwise, you have no way of understanding why certain decisions were made, and judging if the decisions are still relevant when the constraints involved have probably changed.