Let's consider a couple of realities:
- Developers will not run tests that they believe are rubbish.
In all the years I've been building and testing applications, I have never seen a third party write tests that were any good. The most common flaw I've seen is that the third party uses bad techniques to identify the UI elements that must be interacted with or observed. Concretely, this means looking at HTML IDs, and CSS class names that are presentational rather than semantic. Very frequently, the third party will even demand that the UI developer add IDs (or test-ids) to the HTML to facilitate the testing.
All of that is bad, and it inevitably leads to test that are fragile (i.e. start failing when the application changes in irrelevant ways), and to a UI codebase that doesn't make sense to future developers because it is littered with bizarre HTML attributes that misstate their own significance.
The fact is that QA engineers have no place deciding how to build UI, and every developer grasps that intuitively. Fighting it will not only fail, but make enemies. But this does not mean that QA engineers have no power.
- Having quality tests is the only way for developers to have confidence in their own releases.
In all but the smallest applications, it's hard to make changes without breaking something else. Discovering bugs through manual regression testing can be hard and is always time-consuming and error-prone. But if a regression does get released, users will inevitably find it (and usually pretty fast), and that will create a "production fire": a high-visibility emergency that requires developers to immediately scramble to find and fix the bug, and then release it. This is always a stressful situation, as any developer who has lived through one will admit. These things have a way of happening during evenings and weekends -- which means devs get called at odd hours and forced to tackle these problems. (If that is not happening at your org, start doing it.)
But simply having a bunch of tests, or even having pretty high code-coverage, is no guarantee against regressions. The tests themselves must be high-quality.
There is only one way to create such a test suite: the UI developers themselves must write it. It is 100% the job of UI developers to write the tests of their own software. Why?
Only UI developers will know which parts of the DOM are stable with respect to the elements that must be interacted with or observed.
They have that information because they are the ones who made it so! It's a big part of the planning phase. No other person in the organization will even be remotely equipped to figure this stuff out just by looking at the page at runtime. But, with power comes responsibility.
Only UI developers can spot breakage by running the tests before their breaking patch hits the CI pipeline.
Changes to the codebase happen on developer workstations. Ideally, broken code should never make it off the dev's computer. The only way for that to happen is for the developers to be able to run the tests locally (and in the same way as the pipeline, to guarantee identical results). This obviously means that devs must be capable of running the tests, and they should do so before they push their code (or, before they merge their feature branch such that it will be deployed).
The automated test setup needs to fit into developers' workflow.
Devs must be running the tests all the time, locally. That's not going to happen if running the tests is hard or impossible to do on a typical developer workstation. But developers are (rightly) responsible for their own workflow. Again: with power comes responsibility. Devs get to decide what their workflow is, but that also means they must bridge the gap between their preferred workflow and the running of tests.
The only reliable way to make all of this stuff happen right is for the devs to write their own tests. They should choose the tech and tools, but it has to be done.
And by the way, being good at writing tests makes it a lot easier to design and build good app code in the first place. I'm no TDD fanatic (although I know a few), but there are still some cases where even I think it works best to write the tests first and then write app code that passes those tests. Clearly there's no room for a third-party in that flow!
So, where do you fit in?
- Writing tests is hard, just like writing app code is hard.
The test environment is importantly different from the regular browser environment, and there's only one way to handle that difference: the dev has to learn the testing environment just like they learned the browser environment when they first started doing UI work.
That means every dev will have to suffer through that initial, painful learning phase, where they write a test but it doesn't do what they want and they don't know why. Where they have to ask for help with seemingly simple stuff, e.g. "how do I write a test for something that uses timers?"
One thing a QA engineer has that most devs don't is that the QA engineer has line-of-sight on tests from many different teams and projects. That means the QA engineer is ideally positioned to help teams notice shared problems, and to circulate good practices.
This is more of a leadership/mentoring role than a coding role, but no less important.
Try to get yourself added to every code review that includes tests. Even if you don't spot problems or have questions, it'll help you keep abreast of what devs are doing in their tests. (It'll also help you notice when devs start failing to write tests.)
Make sure the pipeline runs the tests and fails the build if anything fails.
Using email to notify people is all well and good, but nothing will get results like putting a brick wall in front of every failed test. Devs probably won't do this. They need someone to do this for their own good.
One thing you may want to consider: make it your org's policy that all new devs must begin their tenure with a significant stint only writing tests. This is something I had never encountered before my current role, but it absolutely improved my testing abilities by an order of magnitude.
In my case, I spent the first 2 months on this job only fixing old tests and writing new tests. And I'm no rookie: I've been a professional dev for over 20 years, and I've shipped software for half a dozen platforms, for clients and of my own design. That first 2 months still made a huge difference in my testing skill and comfort level. And my employer got something out of it, too: upgrades to their old testing codebase, plus a chance to learn whether I was any good without having to take the risk of letting me break their user-facing software.
I don't think you or your org will have much success if the goal is "make the devs use your tests." I think the best sustainable path is for the devs to own their own tests. And it will undoubtedly make them better as devs.