How do the team looks like? Is it 10 geniouses keeping the whole system in their heads or 4000 replacable cogs? If the second how do you make sure they all act in coordination?
There's this classic article about programming for the space shuttle (https://www.fastcompany.com/28121/they-write-right-stuff) that probably has reasonable parallels to how the raptor software was written.
These approaches aren't problem free of course. They're definitely slow, and can appear to be inefficient depending on your frame of reference and constraints.
My experience is in medtech which has similar ideas (but again obviously isn't the exact same). Ultimately all simulations used to prove that the software is working correctly are supposed to be validated (either in part or in whole) by some sort of real testing. The most expensive/real version of that is when they go off and do real test flights (or in medtech, when we go and do stuff on real people).
The type of tests of they have is probably "all types of tests". You pick the right set of tests to test your software components at the scale and detail required, while finding ways to validate the assumptions you made along the way. For example, maybe you have a pure function that takes pitot tube measurements to generate air speed. You could test that function with something like a unit test, and then back it up with another set of test cases (integration or system or whatever) that show that the function is being called correctly in all cases.
Every company/project will have their own Change Control process and defect resolution process defined. Typically they consist of someone reporting a defect, some sort of investigation into the defect (determining rate of occurrence, root cause if able, estimating the severity of the defect), which then gets fed into some sort of risk based problem solving algorithm to determine if an immediate fix is needed, or if there's flexibility. Then you go ahead and try to fix the thing, and when you're done, you go ahead and run more analysis to determine the scope of retest you need to do. If you're lucky, everything is self contained within the "pure software" part of your project and the "worst thing" that can happen is you have to re-run the whole software test suite. If you're not lucky, the change interacts with non-software components in ways that cannot be safely mocked out, and you have to add some kind of real world testing.
I think most places lean more towards replaceable cogs - that is the whole point of all of this process and documentation. It's to minimize the overall risk of the project (which isn't the same thing as maximizing benefit). It's hard to minimize risk while requiring super top tier talent.