There has to be some sort of pain point to make Management and front-line employees aware of the need for testing. How your company does that depends on how mission or life-critical the software truly is. The typical Developer/Tester ratio in an unregulated development shop is anywhere from 4:1 to 8:1. NASA uses a ratio of 1:8. That's right, each Developer has 8 Testers.
Life-critical software like medical devices are regulated by the FDA and each requirement has to have a documented link to a test case and to a test case outcome. If this documentation does not exist, FDA marshals can perform investigations until they are satisfied and lay charges. The company may not produce or sell a single thing until the investigation is complete. There are cases where the investigation took so long the company went bankrupt and closed up shop.
Testing is an insurance policy. As such it has no ROI. It's like asking, "What is the ROI of your auto insurance?". You have it not because there is a problem, but because there might be a problem and you want to be protected if something does occur.
If your company is merrily moving along building software that satisfies the customer without the overhead of testing and there are no negative repercussions, good for them! They will probably continue to do so until there is a pain point.
How can you change the culture? Culture change is difficult. Since the business is humming along nicely without the overhead of testing, there may not even be a need for a formal testing group or test procedures.
You have already indicated that front-line workers have great excuses for not creating unit tests. Does Management feel the same way? Ask your boss and your grandboss for feedback on whether or not they care. If they don't care about a lack of tests and test procedures, you will find it nearly impossible to change the culture. You may have to seek a culture that is more aligned with your own.
If you want to start changing the culture yourself, start with yourself. Create a unit test repository. Create unit tests for everything you develop. Share that repository with all the other developers. Create a document that describes the procedures you use for creating and maintaining unit tests so that the rest of the company can use it when they are ready. Make your boss aware of these things. Keep track of the number of times your unit tests find an issue caused by you or someone else changing code. These are bugs that didn't get out into the wild. By catching them before public release your unit tests helped save company reputation. Let your boss and your grandboss know about these. Keep a public running tally, some sort of metrics dashboard that shows this.