Such domains are often regulated
In some such industries there are external regulations that require certain processes to be in place, not only for testing but also for the rest of the development cycle. I work in the medical device industry, which in the U.S. is regulated by the FDA. The FDA has three "classes" of medical device based on the level of risk: Class I, Class II, and Class III, with Class III devices being things like implantables that have the highest risk.
The types of things the FDA requires (and if you get audited, you must provide documented evidence for), are:
- Reviews of design artifacts (such as requirements and tests) in addition to code
- Traceability of requirements to tests (and for the higher classes, traceability must also extend to design and code)
- Objective evidence of the testing that is performed
- Validation of any third-party software used
- For products involving hardware, ensuring final testing is performed on production-ready hardware as opposed to earlier prototypes
There is more but I'm not an expert by any means, and as developers we operate based on internal procedures that are derived from the FDA guidance by our regulatory and legal teams, so I can't get too detailed without spending a lot of time reading the actual FDA legal-speak.
Some resources if you care for more details, though there's a lot to wade through:
I'm not sure what regulations require it, but we also have stringent requirements when it comes to defects found in fielded products, whether by customers, or by our internal team after a product is shipped. If any employee discovers or hears about a defect from a customer, they are required to enter it into the system within a short amount of time. If it's a defect that has caused, or could cause harm, it may well cause a "stop ship", recall, or field update.
My experience working in this environment
Coming out of school, I had read about the Therac incident and the one field I didn't want to work in was medical devices. Well, here I am. While I haven't worked on any Class III devices, to be honest it hasn't been as scary as I imagined. The regulations, while sometimes requiring more paperwork and process than seems necessary, mostly require things that are good ideas and common sense anyway. I have the privilege of working on a very good team that was committed to quality even before they started building clinical devices; I believe this team commitment is the biggest factor in actually achieving quality. We celebrate finding bugs (because every bug we find and fix is a bug that doesn't harm a customer or patient), but practices such as code reviews, design reviews, pair programming, etc. help prevent many defects before we even have to find them in testing.
When I was an intern at this company, I once ran an overnight experiment on hardware, which my manager walked by in the morning to find the remains of a rather spectacular crash. When I got in, I had an instant message from him saying "so I guess I can call you a certified <product name> engineer now :)". It turned out my simple experiment had uncovered a firmware bug that led to the crash, which a couple more experienced devs then helped me investigate. Essentially being congratulated for my first crash, rather than blamed or scolded, definitely made an impression. Having a blame-free environment takes a lot of the pressure off, especially when the risks and stakes are high.
Some of the downsides/risks
I will add, though, that with such regulations there is more opportunity for abuse of power. What we call our "quality" group is really more about regulatory compliance: they're looking at whether we have all our documentation in place and ensuring our testing is compliant with regulations, versus doing the actual testing. Since we can't ship a product without having that documentation in place, this group is effectively a gatekeeper. However, since many of the actual regulations prescribe more of the "what" than the "how", much is often left to the interpretation of the quality staff assigned to your particular project. While every quality person I have personally worked with has been very reasonable and good to work with, I have heard horror stories about other groups in our company, like documents being rejected for using the wrong font, claiming documents are missing required information without providing details about what that information should be, etc.
In such situations, engineers must often dive into the actual regulations to understand what is an actual requirement versus the whim of the particular quality staff you're dealing with. Otherwise the "compliance" or "policy" card will trump the "common sense" card every time.
Also, if you fail an audit by a regulator like the FDA, the company may have to put "remediation" efforts in place that require extra process, and the actual developers and testers may have little say in what is actually a useful remediation versus busy work that makes your process look better without actually improving quality.