Testy rozpisywane są na podstawie zaakceptowanych wymagań, więc od tej strony nie ma problemu z klientem, bo wymagania będą spełnione/pokryte testami. Ale to klientowi może nie wystarczyć, bo ma on świadomość złożoności systemu i procesów, ma dostęp do przypadków użycia, które były opracowane wspólnie z nim dla testów funkcjonalnych. Ze względu na ich znajomość może sobie zażyczyć rozszerzenia zakresu testów akceptacyjnych.

Najlepiej jakbym mógł odrzucać te jego "życzenia", powołując się na jakąś definicję testów akceptacyjnych np.z  normy. Testy akceptacyjne muszą być wykonane ze względu na zapisy w umowie.

Norma IEEE 829-1998 wyraźnie stwierdza, że plan testów powinien zawierać wyszczególnienie funkcjonalności obejmowanych testami i funkcjonalności, które będą, opcjonalnie, pominięte (IEEE 829-1998, 4.2.4, 4.2.5.). 
Metodyki sekwencyjne oparte na Modelu V też wyraźnie wskazują na powiązanie testów akceptacyjnych z fazą zatwierdzania wymagań użytkownika. Próba rozszerzenia zakresu testów akceptacyjnych o weryfikację procesów zaprojektowanych w późniejszych fazach byłaby odstąpieniem od zasad Modelu V (korzyścią tego modelu jest zachowanie odpowiedniości poziomu ogólności opisu po stronie dokumentacji tworzonej przez zespół wytwarzający i dokumentacji tworzonej przez zespół testujący. Tu ta korzyść byłaby utracona, a testerzy stanęliby przed koniecznością dodatkowych analiz na niższym poziomie, co wymaga dodatkowego czasu. Czyli w zasadzie dokładnie problem, który Pan opisał z autopsji). 
Należy pamiętać jednak, że Model-V  jest już raczej obecnie często uważany za godną szacunku klasykę metodyk projektowych, aniżeli za podejście nowoczesne.