Obviously, we can't solve this remotely, we'd need to actually sit and talk together with their team and think together why the testing is not what it should be (whatever it means in your context). That's the whole point, communication, talking about what they do, what they don't do and why and what needs to be done in order to deliver a better product. It's a team effort, not an effort of one person, one manager or even one team in this context. You need to bring people together and approach it as a problem you all have, not just them vs. us, that creates a blaming culture, but will hardly help you deliver a better product in the long term.
What would you recommend as a handover process?
Nothing. More formal rules won't help much in the long term. Working together, pairing, more communication will help. I know, it's more difficult, definitely harder than throwing more rules on them and ordering them to follow them.
What are the deliverables that we should expect from QA? A list of test cases? A list of findings? Pass/fail scenarios?
Testing is a performance, not one thing, a state, a document etc. you can hand over. Just think about it: you require them to give you a list of test cases. You'll definitely get some, especially if they're affraid of losing their job. But it says nothing about whether or not the test cases are appropriate in the context. Therefore, it will not help you with the overall quality.
I think what you're describing is a typical problem of teams that do now work in an agile style, but rather have their own departments and strictly defined roles. This creates these silos where people do not talk to each other much, blame each other, don't even know what other people do etc. As a (partial) remedy, I'd recommend:
- sit down with their QA team, try to understand what testing they do, what they don't do, why, what they are missing if something (maybe you don't provide them with enough business context, so they don't know what the important things for business people are)
- try to talk to each other more, perhaps you can bring them over to your meetings or standups (if they exist), you can plan testing together, create test data together
- you might pair with them when testing, this might be the most straighforward way of finding what tests they run and how they go about designing them and executing them
I even feel this doesn't need to be a slow or lengthy change. If people are willing to work together, you might resolve these problems fairly soon. Sustaining (some of) these changes will be harder.
