Continous Integration is a best practice per se, which main goal is to ensure that your code assembles correctly and pass both unit and integration tests.
CI should happen continuously regardless the changes (not sporadically only when changes happen). This is especially important for projects involved in continuous deployment and delivery.
Tests can fail anytime during the CI process. Let's say that 3rd party APIs contracts could have been changed or just might have stopped working. Or even worse, someone may have changed the RDM. These things happen oftener than we think. By continuously enforcing our code to pass the tests we are anticipating ourselves to unexpected issues before releases or deployments.
Regarding your role as a tester, Q&A developers are focused on validating end-to-end functionalities and users experience rather than code. They contribute to the SDLC with manual or automated end-to-end tests so that if developers change, remove or add new features to the project, this still accomplish with its main purpose under the agreed premises. Acceptance testing.
Q&A devs are somehow a very demanding customer. The less familiar are they with the code the better because tests are not going to be biased by implementation details.
The automated tests are integrated into the deployment pipeline, contributing to the CI and CD.
From the DevOps point of view, there's no role A or B, there's a team where everybody does tests, develop, look after the quality and the integrity of the project.
Attending your comments related to how to automate acceptance tests, to my latest experience we have 3 possible approaches
1. Manual testings
Well, just do manual tests. We perform these tests in small projects. For us, small means 1-5 screens. Here, documentation is your friend. Get documented the use case to execute and the expected result. Perform the use case in the right order and check the result.
2. Automate test - machine event oriented
In few words. Selenium. The idea behind Selenium is to mimic the browser. No more no less. Ten years ago that was relatively doable because web browsers were not so sophisticated as they are today. Neither were the web applications. Today's web applications are quite more complex, they are quite more event based, more dynamic and the rendering is no longer sequential. Selenium doesn't fit well in such conditions. Agile methodologies don't help here because changes happen oftener and some of them might take us to re-type the whole automate.
3. Automate test - human action oriented
We recently started to play with Computer vision and we got very good results. It's not exempt of shortcomings and it's far more complex to make it work. For instance, we have to reach pixel perfect for any possible resolution, for any possible S.O, for any possible device. We also have to implement an X-server to render the web browser on a remote server when these tests are executed from Jenkins.
This article might interest you. We implemented Skulli as computer vision engine. Our tests are executed against deployed applications which are being monitored during the whole test phase by Jacoco, so we can determine the coverage degree of the use case.