Good enough понятие маркетинговое, а не техническое. Оно означает, что даже с учетом тех, кто будет не доволен и вернет программу (а так же тех, кто под их влиянием программу не купит), все равно выгодно начинать продавать свою вонючую недоделку прямо сейчас, а не когда заработает.

Забавным следствием этого является то, что good enough для недорогих и массовых коробочных програм гораздо более жесткий, чем для програм, которые стоят, например, $10,000. Это получается потому, что содержательно поддерживать по телефону миллионы пользователей очень дорого. А у програм за $10K будет всего несколько сотен покупателей в год, ими можно заниматься и персонально. Т.е., если вы покупаете программу за $100, скорее всего она хоть как-то, но будет работать прямо из коробки. Если за $10K, то работать в конечном итоге будет, но заставить ее это делать будет непросто. Если за $100K, то работать не будет совсем, но зато у вас будет персональный консультант (а за $1000K разработчики переедут жить в Ваш оффис).

Меня же сейчас интересуют критерии корректности софтвария именно в техническом смысле, а не в финансовом.

Чтобы всерьез рассматривать тестирование как способ проверки корректности программы, надо научиться как-то оценивать осмысленность самих тестов. Ведь очевидно, что если уж даже программы теперь пишут "на глазок", то тесты в среднем совсем ни про что. Занимаются ими (к сожалению!) люди, которых в программисты не взяли.

Я вот предложил более-менее формальный способ такой оценки.

2 теста совершенно запросто могут давать одинаковую (по сравнению с каким-то одним из них) вероятность безошибочности. Просто потому, что когда эти тесты придумывали, то вот именно о вероятности безошибочности думали вряд ли.

Тестировать методом Монте-Карло занятие безнадежное. Потому что чтобы убедиться в безошибочности с вероятностью 1/10000, надо сделать порядка 10000 разных тестов. А вот если бы каждый следующий тест делил вероятность незамеченной ошибки пополам, хватило бы 13-и с половиной тестов.