The Oracle Problem in Software Testing: A Survey
2015 Earl T. Barr, Mark Harman, Phil McMinn, Muzammil Shahbaz, and Shin Yoo
[doi] [pdf]

A Comprehensive Survey of Trends in Oracles for Software Testing
2012 Mark Harman, Phil McMinn, Muzammil Shahbaz and Shin Yoo
[pdf]

Чтобы лучше понять различие между верификацией и валидацией, стоит запомнить главное: у верификации всегда есть Оракул — механизм, который однозначно определяет: результат истинный или ложный. Но стоит отметить, что не обязательно оракул должен знать ответ для всех значений.

Выделяют 4 основных вида таких оракулов (или арбитров):

1️⃣ Implicit Oracles (Неявные оракулы): Мы обращаемся к универсальным истинам предметной области. Например, выход за границы массива — ежу понятно, что это ошибка для любого ПО. Именно поэтому фаззинг такой «успешный»: всё, что он ищет — это нарушения абсолютных истин (краши, утечки памяти), не нужно тратить время на false positive. В своей сути — это избирательное тестирование.
Минус: если программа не делает ничего плохого (не падает), это ещё не значит, что она делает что-то хорошее :)

2️⃣ Specified Oracles (Специфицированные оракулы): Мы подробно описываем, как система должна себя вести (создаем спецификацию). Имея на руках формальное описание эталонного и правильного поведения, мы просто проверяем систему на соответствие ему.
Минус: очень трудоёмко описывать правила и продумывать абсолютно все краевые случаи.

3️⃣ Derived Oracles (Производные оракулы): Случаи, когда мы можем «извлечь» правильное поведение откуда-то извне. Например: намайнить из документации, взять старую версию продукта, использовать альтернативную реализацию, прогнать регрессионные тесты или написать вторую, более простую версию алгоритма (N-version programming).
Минус: источник эталонного поведения сам может содержать баги, быть неполным или устаревшим.

3️⃣ Human Oracles (Человек как оракул): Тут всё понятно: ручное тестирование, Mechanical Turk или Толо́ка :) Человек сам смотрит на результат и выносит вердикт.
Минус: долго, муторно и скучно.

Конечно, статья из 2015 года и больше была попыткой систематизации существовавших подходов к тестированию, чтобы за счёт автоматизации снизить нагрузку на человека. Такая классификация отлично применима к классическому детерминированному ПО, но там, где у нас появляется вероятностное поведение (привет ML), способы тестирования уже меняются.

Мне лично больше нравятся подходы к этой проблеме со стороны философии науки, но об этом — уже в другой раз.