<html><head></head><body><div class="ydpb4c12b05yahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:16px;" dir="ltr" data-setdir="false"><div dir="ltr" data-setdir="false">
Tangential question, who uses non-destructive testing to detect errors?<br></div><div><br></div>
</div><div id="yahoo_quoted_4504540420" class="yahoo_quoted">
<div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
<div>
On Monday, July 6, 2020, 1:37:49 p.m. EDT, Martyn Thomas <martyn@thomas-associates.co.uk> wrote:
</div>
<div><br></div>
<div><br></div>
<div><div dir="ltr">On 05/07/2020 12:47, Olwen Morgan wrote:<br clear="none">> Does anyone here honestly believe that you could successfully defend<br clear="none">> omitting UT in an action for negligence if a system developed using<br clear="none">> CbyC failed and killed someone as a result of a defect that could have<br clear="none">> been detected by UT?<br clear="none"><br clear="none">Can you guarantee that your UT will detect all the errors that any<br clear="none">possible UT would have detected? If so, how?<br clear="none"><br clear="none">Are you using successful tests as the axioms on which you can develop a<br clear="none">rigorous inductive proof of correctness, which (if I recall correctly)<br clear="none">Tony Hoare said was how testing should be used?<br clear="none"><br clear="none">If not, in your hypothetical example, how are you going to defend having<br clear="none">omitted the unit tests that would have detected the errors that caused<br clear="none">the failure that killed someone?<br clear="none"><br clear="none">I think you are doing what the opponents of FMs often do and assuming<br clear="none">that the proponent of C-by-C is claiming they can deliver perfection.<br clear="none">I'm certainly not - I'm saying that software engineering seeks to make<br clear="none">software that is as fit as is reasonably practicable for it's intended<br clear="none">purpose and that in my experience, being as rigorous as reasonably<br clear="none">practicable is tautologically how to achieve that.<br clear="none"><br clear="none">In my experience, most software teams don't even try to be rigorous. At<br clear="none">best they are skilled craftspeople, not professional engineers.<br clear="none">Sometimes that's good enough. Sometimes it may even be what you need.<br clear="none">Caveat emptor.<div class="yqt3860111027" id="yqtfd29537"><br clear="none"><br clear="none">Martyn<br clear="none"><br clear="none"><br clear="none">_______________________________________________<br clear="none">The System Safety Mailing List<br clear="none"><a shape="rect" ymailto="mailto:systemsafety@TechFak.Uni-Bielefeld.DE" href="mailto:systemsafety@TechFak.Uni-Bielefeld.DE">systemsafety@TechFak.Uni-Bielefeld.DE</a><br clear="none">Manage your subscription: <a shape="rect" href="https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety" target="_blank">https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety</a><br clear="none"></div></div></div>
</div>
</div></body></html>