One of the earliest things that Salesforce did that set the stage for DevOps was to prevent people from changing Apex or Visualforce code directly in production (you have to change it in a sandbox and deploy it to production), and to mandate 75% minimum code coverage for Apex code. Code coverage is calculated by running all of the relevant Apex test classes (special Apex code files which function to test other Apex code) and seeing what percentage of lines of the Apex code are executed when the tests run. Code coverage does not guarantee that the tests are comprehensive. It doesn’t even guarantee that you’re actually testing anything, it just means that code runs.
These two steps forced Salesforce developers to use sandboxes, do deployment, and write unit tests, and was thus the genesis for Salesforce DevOps. Admins have reluctantly been forced to follow.
Salesforce devs are notoriously unenthusiastic about writing test code, so “test classes failing” means that they unenthusiastically wrote tests, but over time new changes have caused them to break. Devs haven’t bothered to rerun those tests and check them during development, and so the team only discovers that they’re broken when they attempt to deploy to production.
“No code coverage” means that the devs were lazy and created new Apex code but didn’t write any apex tests. That only causes problems when they attempt to deploy to production and the team discovers that there’s 0% code coverage for some classes.