In short, Continuous Integration (CI) is where you are heading. Remember that CI is a set of good practices that include automation, committing many times in a short period of time, running tests, communicating all parts involved in the project, using a source code management system, using a close of the production environment to execute your tests plus others.
Without much information about your team and the philosophy in which they develop its a bit more difficult to impose any sort of framework on you without stressing some part of your process.
Most automated testing can reach any sort of test case management system that has an API or integration.
You want to be able to adjust for when integrating a CI process with test management:
1. Detail > screen shots, log files, details on the environment and other data available
2. Direction > the build server can be used to trigger the execution, manual or automated, of tests.
3. Granularity > From one test case to executing all the builds related to a certain test case in your test management tool.
Without knowing the whole process from end-to-end the above might not help. The goal is to break your software and as early as possible. Once interface is possible as the automation is generally placed as early as possible in the development cycle.
If you are referring to automating the manual testing, there are a host of tools on that front with integrations into most of the leading tools.
My team can easily advise, put together a solution and/or framework with a bit more information. I'd prefer to have a chat in order to build a true quality assurance system that doesn't expose any risk and breaks your software sooner and faster under one roof.