Just a brief comment - testing serves only to create data. You need to analysis the data and conclude on something (and you usually need to have predefined criteria/justification/etc/for the analysis), but then again, results of the testing itself is only the data.
I certainly haven't argued for testing (software, hardware) in the absence of of criteria. My advice to teams working through a medical device RM process is (once risks have been identified) is to establish/identify risk control measure appropriate for the risks, and then, at an appropriate level, establish a requirement which is testable (and correct, non-conflicting, etc.). The requirement can then help to establish the "null hypothesis" (for a frequentist analysis) or can inform prior selection (for a Bayesian approach). Either way, test data doesn't exist in a vacuum. After performing the tests, there is some new state of information about the effectiveness of the risk control. I am not under the delusion that a majority of ME design professionals are consciously applying 14971 in this specific manner, but I do believe that this is a mathematical description of what is happening in a 14971 risk management process.
Coming from the HW world (not necessarily electrical) my first preference is always calculations, or another method of theoretical, robust engineering analysis. It may not always be possible for SW applications, and thus we might have to fall back to testing; that's okay, as long as we don't lose sight of the fact that this is indeed a fall-back, and don't delude ourselves that through testing we fully proofed a proposed solution.
To my way of thinking, 'robust engineering analysis' is another method of testing: If prior to the analysis there were pre-defined criteria and the implemented design was reviewed specifically against the pre-defined criteria then the analysis is in some ways repeatable. That is to say, the same hardware design and review criteria could be sent to two different (but equally capable) engineering reviewers and the outcomes would hopefully be aligned.
I wasn't commenting on this from a "narrow" risk control perspective but from a broader perspective - how do we actually gain upfront confidence in our designs? Be they SW, HW or a combination.
(emphasis mine)
I read the word "upfront" as implying "prior to the implementation of risk controls". Is this what you mean? Or do you perhaps refer to the identification of a risk control that is implemented with something you wish to identify as IBD? If it is the latter, my personal expectation for an IBD risk control is one of the following
(keep in mind that I personally do not like to use IBD to identify 'implementations' that are not actually in the design to rationalize the non-existence of certain hazards, which I have witnessed from some teams):
1) The implemented risk control is uniformly recognized as
prima facie effective for the risk, e.g. for fire risks, materials that do not burn below a certain temperature that is never reached.
2) An analysis of the implementation is performed against appropriate criteria for the identified risk.
If case (1) is true, then I would not expect to see very much in the way of 'supporting evidence'... with the caveat that external/unfamiliar reviewers may have a different baseline and may want to see more.
For case (2), I would expect the analysis to be discoverable in the risk management files.