The fundamental problem is that this is a religious issue for both engineers and managers. People generally don't believe until they personally witness the miracle of rapid development with predictable schedules and low customer visible defect rate.
Working solutions in order of increasing time + difficulty:
1. Quit and either start a new team or join an existing one with decent development practices (I insist on a code and test process walk through of every company I consider joining to avoid unpleasant surprises. Obviously this fails for groups yet to build a product, and sometimes teams panic when pivoting and abandon reasonable practices).
2. Get promoted to a leadership role while you remain hands on. Tell every one else to do the right thing like you're doing - getting people to buy in is easiest when you're not making them do something you won't like the case would be with a non-coding manager. Most people fall into line with direction from above. Peer pressure works for most hold-outs. Any one not getting with the program can be replaced.
3. Do the right thing on your code. With your process producing a faster more predictable release cycle you'll have higher productivity and can take over an increasing fraction of the product so the bad people with bad process have less impact.
Applying test driven development variants to new features/subsystems/products helps a lot here because it makes shipping without good test coverage and short predictable cycle times impossible because no product code exists without the necessary infrastructure. While a "code complete" milestone may be farther into the future depending on how that's defined the total time to deliver the project will be lower and ultimately it's the ship date that matters.
Do the same for bug reports. Every reproducible bug gets an automated test case (if it broke the first time it's complicated enough to break again).
After a couple years you should be in good shape with enough infrastructure that the cost to add test cases is effectively zero before their benefits are considered (Perhaps most notable is that the requirement for incremental testing leads to cleaner interfaces which make complexity more linear with respect to project size. That in turn produces a lower defect rate, faster turn around time on repairs, and makes defect rate/time to repair more constant and predictable) and you don't have to worry about new people (or old people who haven't touched a piece of code in a while) breaking things accidentally.
Here are some things which don't work:
1. Talking to your co-workers about doing the right thing
2. Providing anecdotes (personal and otherwise) from other companies about the benefits
3. Buying everyone a copy of a book like
_The Clean Coder: A Code of Conduct for Professional Programmers_ by Robert C. Martin
The jury is in!
Te controversy is over.
GOTO is harmful
And TDD works
in their choice of print or Kindle edition with the direction to read it on "company time."
4. Doing the right thing and providing metrics on things like defect rate, time to repair certain classes of bugs, number of release candidates for a feature, etc. This can be very striking - memory corruption bugs made reproducible by the test environment so you fix them in 30 minutes versus three weeks for co-workers' similar bugs, a major subsystem with no QA or customer visible bugs or just one of each, etc.
Logical people would get on board after seeing such evidence, but this is about religion not logic.