Почему я часто хочу иметь автоматические тесты на варианты конфигураций у конечного пользователя?

Что бы пояснить заказчику изменение поведения в терминах, понятным конечным пользователям, и получить их согласие на это изменение. Или НЕсогласие. Заказчику нужно сравнить неудобство в работе с приложением с затратами на реализацию более удобной работы и либо оплатить эти изменения, либо оставить как есть.

Например, заказчику приложения лекго принять решение после такого моего пояснения:
"Код приводящий к этой ошибке можно отключить. После этого восстановление положения customization form изменится в этих сценариях работы пользователя с приложением: ... [было -> стало] ...."

Сценарии я перечисляю в терминах конечных пользователей: шаги пользователя и результат работы приложения.

С автоматическими тестами на отдельные классы внутренней реализации я часто получаю сценарии в терминах упавших тестов на отдельный класс и заказчик не понимает эффекты  от изменения. А я по результатам работы этих тестов не могу перечислить сценарии конечных пользователей: я уже давно занимаюсь другими сценариями и не могу их вспомнить или проанализировать вызовы и из них перечилить варианты. Еще чаще бывало что этим сценарием занимался другой сотрудник и он у нас сейчас не работает.

В результате в таком раскладе заказчик не может принять решение. Его удовлетворение процессом разработки программы уменьшается. А при большом количестве таких негативных ситуаций заказчик может передать работу над программой другим исполнителям.

ЗЫ: Какие тесты мне помогают?