This has lead to a mandate that we "are not allowed to ship bugs" and must do everything we can to ensure software quality. The product I work on is old and has a very complicated code base (1M+ loc). For years the CTO evangelised his opinion that unit testing is worthless and the junior and mid-level engineers took this to heart. Test coverage is therefore basically non-existent, and existing tests fail. It would take months to fix them, and we can't delay deliverables to do this.
We have a formal QA team, but full regression testing takes a week+ with 2 or more people (our team has only 1 tester). Some of the QA staff are also young and inexperienced and log issues that are irrelevant (or extremely low priority issues, mostly UI related or convoluted edge cases) and miss core business cases.
I've also always thought fast iterations are better than extremely rigorous testing.
It has repeatedly been made clear that the engineers are ultimately responsible for the work they deliver, and are held accountable for any defects.
How could we increase the quality of our work to a state where we ship without defects? Are there formal methods, or specific processes we can adopt? Is it worth spending our free time to get the tests working and expand them to test most of the application?
You should first tell management that their expensive and unrealistic expectations (including the zero-detect business model), certainly without matching support for you and the team (hire more skilled team members, resources, understanding, time, accept delays in deliverables, ...) is not the right way to go about this or realistic.
With that out of the way, in terms of improving the code and platform, take your wins where you can get it, it will be a gradual process.
Do you know what parts of the system have the most defects and high severity?
Adding a unit/integration testing framework, along with build automation that runs the tests, and training in the team about the benefits and how to write a test, would probably be my first stop.
You could then start to add tests (and would need some code refactoring as needed) to the high-defect parts of the code to start adding some defenses.
If this is a web based app with no framework, using a browser-based tool to run web based regression tests may be appealing too (see https://reflect.run/ - I saw it mentioned on HN recently).
It has repeatedly been made clear that the engineers
are ultimately responsible for the work they deliver,
and are held accountable for any defects.
guy tapping the side of his head meme: You can't ship any DEFECTS if you don't ship any CHANGES