A software project testing cycle encloses several steps - including the ones you mentioned. However, happens that in most of the cases such testing cycles overlaps each other pretty much because the projects aren't big enough. In the end, both technical and functional aspects are tested all together, as a big pile of tests and checks.
There are cases, however, when testing cycles must be split and clearly defined.
The test you have right now, as per your description, sounds like an automated Unit Testing (or a pack of Unit tests). The objective of this is to make sure each functionality or deliverable (you name it) works fine from a technical perspective. That's the kind of testing most of the projects have.
I assume you might also have some sort of System Testing, to make sure that the changes are fine from a functional point of view.
What seems you're missing now is the testing to be applied in between both, which is called the Integration Testing.
In big projects, such tests are usually covered by specific team(s) with specific checks to be done. Is important to make sure that the testing pack used by the Integration Testing is not the same as the System Testing, as the objective of the former is to make sure the interfaces between modules are working as expected. If you don't define clear boundaries, you'll have a never ending testing cycle, so good to define beforehand the expected results and coverage of each testing cycle.
So yes, what you need is a specific team (that could be built by one resource from each module) with a specific set of integration testing to be done. To build up this test pack, I'd strongly suggest to have clear the interfaces between each deliverable.
A last tip: The testing lifecycle names, expressions and flows depends a lot on the company methodologies, so when talking with other PMs make sure what's the phase you need assistance for.
