What objectives are you seeking to accomplish through testing? If it is improving the quality and rate of delivery of the solution, consider the following.
First, look at the individuals and interactions around these tests. Are there multiple teams? Just one team? What teams and stakeholders are up/downstream from the product / module. What do they want to have/see?
How to achieve this is? Look for seams. Seams are places where you can insert tests. Seams exist between modules (as you've identified), between teams, and between steps in acceptance/sign-off chain.
For each of these, look at how the tests can facilitate collaboration between the two sides of the team. e.g. design sessions when changing interfaces, coming together to write bdd scenarios for signoff.
Then consider what constitutes working software and craft what the Scrum community calls the "definition of done" this should include performance constraints and any deployment, testing or automation (and if necessary, policies).
Then attempt to apply this definition of done to each feature (or user story if you have them) and see where the gaps are in terms of instrumentation. This will provide a roadmap for what tests need to be written.
Using the instrumentation to measure stories in terms of functionality and performance is the next step on this chain.
By basing your tests on what has emerged from the actual definition of done and how to measure this, you'll have created a lean set of tests. These will be the most able to change if (when) the definition of done changes. Also tests per feature mean you can handle each new feature based on its needs, not limit what new software can be created based on the testing methodology.
In summary, take a step away from the tools, and see how your testing can tie the project together and facilitate lowering the cost of delivering software and improving he chances of successful delivery.
Answer strongly influenced by the manifesto for agile software development.