I have the honor of sharing this story, but I’d like to point out that this was made possible thanks to the vision and efforts from @k.joseph, @christine, @dkayiwa, @kdaud, @sharif, and many more folks involved in our community’s QA Support Team.
Just recently, @dkayiwa was upgrading our platform’s version of Spring (we needed to add a recent patch). No issues with the upgrade on his local, and the Unit tests in our core platform were all passing - but when he merged it, he found that our FE tests were failing (from reviewing the Bamboo build for the 2.x RefApp). This led to a discovery that the Spring upgrade would have broken many 2.x RefApp user workflows. So Daniel was able to address the underlying issues and successfully release the Spring upgrade, without accidentally breaking things for end users.
In the last 2 years, our OpenMRS global mindset has shifted towards more automation of QA. We still do manual testing, but we realized that we struggled to do enough to catch problems as they were introduced By the time we caught issues manually - weeks, months, or even years after the culprit commit was merged - the original devs involved were either no longer able to work on the problem, or had lost cognitive momentum on that task. Plus, we had a whole new frontend starting (O3). To keep an eye on the 2.x RefApp without massively increasing our work, we said “let’s make sure major workflows in 2.x are covered by automated frontend tests” (you can see all these on our live dashboard here).
Well folks, the strategy is working 
Thank you Daniel for sharing this great story with me and for this great reminder of why automated tests should be a priority: they help protect against regressions while doing future essential maintenance work.
This is the beauty of having automated tests!