Ок.
Уточните понятия «позитивного» и «негативного» тестирования.

И то и другое означает проверка. А разницу придумали тестировщики. Чтобы показать, что они тоже «профессионалы».

Тонкая разница между «а мы сделали правильно» и «а мы правильно сделали» в английском языке воспринимается более адекватно ввиду особенностей английского языка. В русском она воспринимается как ненужная перестановка кроватей при падении доходов и легко поддаётся запутыванию при выяснении деталей.
Предложенное вами разделение достаточно логично, и в отношении программно-аппаратных комплексов может считаться верным, если надо тестировать железо отдельно и опционально прилагающееся к нему ПО отдельно (программно-аппаратных комплексов для систем критических для безопасности в вашем случае).
Но связывать верификацию с «белым ящиком», а валидацию с «чёрным ящиком» — а вот это уже мне кажется странным, бо у меня в фокусе только разработка ПО. Я не знаю, какая именно железяка его обслуживает, подходить к нему с тестером наголо нет необходимости. Можно сервер поднять и на моём ноуте, и подразумевается, что всё должно заработать. И если мы начнём разговор с того, что верифицировать и валидировать можно (и нужно) сами требования к ПО (и железкам в вашем случае), а не само ПО, то картина будет иная. Будет ли она для вас уместна?
Можно же делать верификационные тесты для ПО и не заглядывая ему в код. Если оно делает то, что было заказано, то верификация пройдена методом «чёрного ящика» — без противоречий.
И можно делать валидационные тесты, глядя в код — обычно после этого начинается рефакторинг и швыряние стульев. Но уже сложно представить себе, какие такие неформализованные ожидания от кода могут быть у пользователя ПО, который пользуется ПО, не заглядывая ему под код… Неважно вообще, как организован код кофемашины, бо удобно-неудобно кодом не описывается. Хотя им и задаётся, если речь идёт о восприятии последовательности вывода каких-то сообщений или… тут уже воображать можно долго.
ПО вообще — абстракция.
Тестирование ПО — продумывание предполагаемых и вероятностных ситуаций, в которых это абстрактное ПО должно (и, соответственно, может) оказаться в ходе решения задач.
Тест-кейсы — ситуации, которые мне надо воссоздать искусственным образом (ради, соппсно, проверки, чтобы знать, как ПО будет отрабатывать свои задачи) для выяснения способности ПО выполнять поставленные перед ним задачи предопределённым способом.
Но если ПО в железках можно использовать только определённым образом (для примера подойдёт пульт от ТВ или кондиционера), то в браузерах — или вообще в операционной системе — взаимодействие с ПО может отклоняться от предопределённого способа. Поэтому надо смотреть и придумывать дополнительные ситуации или и ситуации, и способы их создания.
Метафора «белый ящик» заявляет о том, что я буду придумывать/распознавать тестовые ситуации на основе кода ПО и/или его спеки. На основе увиденного можно продумывать все положительные и отрицательные сценарии, которые должны/могут быть выполнены. Но если программист что-то упустил и какой-то IF не учёл, то вероятно, что и я его пропущу. Например, в алгоритме заваривания чая есть множество подразумеваний вроде «вскипятить воду». А если вода придёт зелёного цвета? А если воды нет? Человек это разрулит на ходу. Робот нет. Тесты на основе «белого ящика» тоже могут такие банальности не предусматривать, и это их слабость.
Поэтому есть метафора «чёрный ящик», которая заявляет о том, что для придумывания тестовых ситуаций я буду воображать условия выполнения задач будущим ПО на более высоком уровне абстракции, не привязываясь к реализации. Мы это ещё называем «тыкать пальцем в живое приложение и наблюдать за реакцией», но такие тесты можно (и нужно) придумывать и записывать задолго до момента, когда ПО будет доступно для тыкания в него пальцем.
Программистам всегда кажется, что «белого ящика» должно хватать, и поперву это воспринимается очень обоснованно, бо что нам заказали, то мы и реализовали в коде, case closed. Тестировщики обыкновенные, которые в код смотреть не умеют, вообще не понимают все эти метафоры, и используют «ящики» как средство объяснения своей финтифлюшности, вроде, я мануальный ручник, я тестирую только «чёрным ящиком» и оставьте меня в покое, а «белый ящик» это якась неведома шняга, которой занимаются только программисты.
А дальше другой пласт — соответствие требованиям не всегда ортогонально к ситуациям, которые строго предлагаются в требованиях к ПО или выявляются в ходе его разработки или эксплуатации. Идеальное соответствие требованиям не означает, что ожидаемое качество ПО было достигнуто, бо толку-то, если мне неудобно или некрасиво или что там ещё, так сложно формализуемое на языке логики и математики, но так легко понятное на языке «личностного отношения». Оказывается, ещё надо выявлять и неформализуемые требования, и это уже будем называть «валидацией». И да, это всё можно сформулировать и записать как требования ещё на этапе, соппсно, работы с требованиям, когда нет ни кода, ни тестов, ни точного понимания того, как всё будет в итоге выглядеть. Что-то будет достаточно верифицировать, что-то будет нужно валидировать — вот примерно такая простая картина Босха. Всюду, где в итоге качество будет определять человек — нужно продумывать и верификацию (основа) и валидацию (опционально, но это источник итоговой оценки).
В отношении API или настройки железа валидация бывает и не нужна, бо (условно) видеокамера настроена так, как должна быть настроена, и выдаёт то разрешение, которое в ней заложено конструктивно, а если мне что-то не нравится, то иди покупай другую видеокамеру, с этой ничего не изменится.
Ещё более условно: технологически совершенному современному автомобилю я предпочту старую ГАЗ-21, и никакая верификация технологических параметров не будет аргументом. Да, медленная машина. Да, большой расход. Да, неудобно руль крутить на парковках. А мне в целом — нравится. Валидация тут важнее.
Или, скажем, Windows XP…
Ввиду того, что вы опешили — потребуете ли вы отсылки к трудам признанных богословов церковно-тестировщицкой литературы? Обычно на этом разговоры вянут, бо даже если таковая найдётся, не факт, что она выстоит против новых аргументов. И у каждого собеседника всегда есть спасительное «А я не верю, и таково моё мнение» — а это неоспоримо.