QA needs to be a role in a team, not a separate team. When there's a "QA team", they inevitably end up in an adversarial relationship with development teams. The devs will lie to QA, or withhold the full truth, for a number of reasons: they don't want to be nagged about small things; they don't work for QA so QA has no direct authority; they only interact when things are broken, so the entire relationship is based on negativity; QA comes after the fact and it's too late to change things (or at least too late to change them the right way); QA lacks the engineering background to understand what it is that they're testing (so they test the superficial things and don't test the showstoppers); etc. There are tons of reasons a separate QA teams creates an us-vs-them situation where the path of least resistance is deception and hoping no one finds out what's really broken.
It's ok to have a QA 'team' that represents a group of QA specialists and focuses on their unique interests and areas of responsibility, but the members of that team should be embedded in the development teams, working alongside them as they develop, helping to write test plans, identify problem areas before the code is written, clarifying acceptance criteria, etc. If there's a "QA manager", that person should be more like a mentor, or the kind of good PM who runs interference and supports the development effort, but isn't actively directing the development effort.
If your QA people aren't in the room (covid aside) with the developers, and are instead all gathered together in a separate "QA unit", you've already lost. By the time they identify problems, it's too late to fix them well, and they'll never change the development culture into one that learns to produce fewer bugs in the first place.
It's ok to have a QA 'team' that represents a group of QA specialists and focuses on their unique interests and areas of responsibility, but the members of that team should be embedded in the development teams, working alongside them as they develop, helping to write test plans, identify problem areas before the code is written, clarifying acceptance criteria, etc. If there's a "QA manager", that person should be more like a mentor, or the kind of good PM who runs interference and supports the development effort, but isn't actively directing the development effort.
If your QA people aren't in the room (covid aside) with the developers, and are instead all gathered together in a separate "QA unit", you've already lost. By the time they identify problems, it's too late to fix them well, and they'll never change the development culture into one that learns to produce fewer bugs in the first place.