@Adam Budoch:
Twój problem jest ciekawy i wcale nie tak łatwo go rozwiązać. W praktyce nie występuje, gdy jesteś dobrym profesjonalistą. Nie dlatego, że Twój pozbawiony bugów kod tak zachwyca każdego klienta, tylko dlatego, że profesjonalista potrafi dobrać sobie dobrego, normalnego klienta. To profesjonalista bierze odpowiedzialność za to, jakich ma klientów.
Normalny klient nie odstawi takich chamskich akcji.
Niemniej jednak, podobnie jak Ty, widzę tu teoretyczną możliwość exploitu.
I słyszałem o pojedynczych sytuacjach, w której klient faktycznie zgłaszał błędy, za które autor projektu nie odpowiadał. Błąd tak naprawdę nie istniał, istniał na maszynie klienta z powodu wirusa czy innego ustrojstwa, czy też (częściej) błąd wprowadziła inna osoba, która później grzebała przy projekcie. To jednak były pojedyncze przypadki i nie przypominam sobie, by któraś przydarzyła się akurat mi.
Wypadałoby się jednak zabezpieczyć przed tym exploitem. Bo przecież każdy błąd mamy niby obowiązek sprawdzić, przynajmniej w okresie gwarancyjnym. Klient-psychopata (z którym nie powinniśmy współpracować w pierwszej kolejności) może nas zarzucić raportami wyimaginowanych błędów. My musimy je sprawdzać. Całość przypomina trochę atak DoS na nasz mózg ;).
Dobrze by było zabezpieczyć się przed czymś takim w umowie. Np. klauzulą "3 zgłoszenia nieistniejących błędów i gwarancja znika" (wiadomo, że raz czy dwa ktoś może niezłośliwie zgłosić coś, co wg niego jest błędem).
Ktoś wcześniej wspomniał, że klient dostaje jednego dnia aplikację i tego dnia podpisuje jej "odbiór", tj. że spełnia ona wymagania funkcjonalne. Takie coś może kompletnie nie wchodzić w grę. Aplikacje mogą przecież być bardzo złożone. Na tyle, że w jeden dzień nie sposób nawet sprawdzić, czy realizowane są wszystkie wymagania funkcjonalne.
Poza tym, co to oznacza "spełnić jedno z wymagań funkcjonalnych"? Czy jeśli aplikacja zawiera opcję np. edycji nazwy produktu, ale w 50% przypadków użycie tej funkcji powoduje usunięciem produktu / zmianą nazwy innego, losowo wybranego / zupełnie niczym, to wtedy wymaganie funkcjonalne edycji produktu jest spełnione, czy nie? A gdy funkcja ta nie działa w 90% przypadków? To wtedy też mówimy, że funkcja jest, tylko lekko zbugowana? ;)
Przetestowanie, czy wszystkie podstawowe funkcje skomplikowanej opcji działają MNIEJ WIĘCEJ jak należy może spokojnie zająć więcej niż dzień. Tym bardziej gdy ktoś stosuje (głupią, moim zdaniem) taktykę pokazania klientowi najpierw szkiców i statycznych layoutów projektu, a po X miesiącach, w dniu oddania, już gotowej, działającej aplikacji. Wtedy klient musi się najpierw zapoznać z aplikacją i wszystkimi jej funkcjami, a dopiero potem je porządnie przetestować.
Dlatego pytania z pierwszego postu @Adama Budocha wydają mi się rozsądne.
Jeszcze a propos testowania przez autora i przez klienta -- przypomniała mi się anegdota z "Pragmatycznego programisty" (bodajże).
Całkiem dobra firma napisała klientowi aplikację służącą do rysowania. Po pewnym czasie klient zgłasza telefonicznie, że gdy narysuje skośną kreskę pewnym narzędziem, to aplikacja się wysypuje. Firma programistyczna była zdziwiona, bo przecież regularnie testowała wszystkie narzędzia dostępne w aplikacji. Chłopaki zdziwili się jeszcze bardziej gdy przetestowali dokładnie to narzędzie jeszcze raz -- rysując skośną kreskę -- i wszystko zadziałało jak należy. W pewnej konsternacji zgłosili to klientowi. On sprawdził jeszcze raz u siebie na tym samym buildzie i podtrzymał, że błąd występuje. Po jeszcze paru wymianach maili i telefonów zaciekawiona ekipa programistyczna pojechała do klienta sprawdzić, co tam się u niego dzieje. Okazało się, że klient rysował kreskę od prawej do lewej w dół, tymczasem programiści testowali u siebie tylko od lewej do prawej :-).
I tym optymistycznym akcentem...