For your context regarding to this question: This past month, I had a painful release experience, required debugging production issue introduced by another cross-functional team right before the New Year Holidays Release. I found out that that this team does not have good QA process and would ship out this new feature assuming that QA complete varying degrees of success.
Their release process seems to be broken and it ultimately lead to production bugs and issues that requires hot fixes.
I joined the retro release meeting with Dev & QA leads. And we all agree that QA should have not signed off the feature release until it's done with regression testing. and future new feature must require proper review and End-to-End testing on Non-Production Env.
However, the issue that this new team raise is that they do not have proper resource and maturity to perform all of the necessary QA testing, and their QA engineers could not test out their feature in the non-prod env, so therefore they cannot catch the bugs before going to production env.
TLTR, here's a Question: Appreciate any thoughts or suggestion on how to work with this new team (a cross-functional inside my Organization)? Given the context I learned that this new team lack of QA resource and engineering maturity and scoping issues. I feel uncomfortable to approve and review this team's changes, as it seems very likely that similar mistakes and defect will get introduced by this team until they fix the QA process. I don't think I want to see any more new bugs added to Production and not discovered during the QA phase.
I also checked the Flow for current QA process for Production HotFix is following:
There's another question (perhaps you discussed in the retro): why was this feature shipped before the New Year holiday? Given that many people are out of office, it seems like poor timing for the team to plan it that way. Or perhaps it wasn't planned.
To your question: I think you should push hard for that team to be more self-sufficient. If they truly can't test until something goes into production (that seems kinda lame though...), I'd ask for the following from them:
There should also be a discussion about the cost (either revenue or user experience) for this -- if it's an internal tool, for example, maybe you can be more lenient.
Ask for this legwork to be done by that team, and I'd also involve various managers as appropriate (depends on how contentious the relationship is).
Certainly you should keep your manager in the loop, and broadcast any decisions made to everyone who attended the retro.