We're in the same boat. We take steps to create test visibility, but ultimately developer behavior falls into the "things I can't control" bucket. The most crucial thing I have to do right now is keep a tight leash on the test environment data. I pay attention to new deployments, and I make sure other parties know it is not OK to make certain changes to the QA data without running them by us first. They can do crazy environment manipulations in their own environment (which they have). The data is such a big issue because in our case we need to maintain referential integrity across entities. > Ideally the test suite would run before any any changes are committed and any failures would be addressed Yes, and to do this eventually I would like to see every service/application/database in our environment containerized, then spun up by the CI process and data quickly seeded. This requires some action from multiple teams in our case, and will take time. But it will happen eventually. This will also be an uncomfortable day for the developers, as they will have no choice but to fix the code or the tests lest their pull request sit there gathering dust. One "right now" change you can make if you're using a CI process is to trigger the tests in multiple places. In our case we trigger all tests when our primary QA website has finished deploying, but we also trigger a smoke test when one of the related services is deployed.