"Az ügyfél használja a programot, dolgozik vele, de nem ő fizet..."

gondolom itt ezt akartad írni:

Az felhasználó használja a programot, dolgozik vele, de nem ő fizet...

Valóban. Javítottam.

Azt tapasztalom, hogy sok helyen az UAT csak egy eszköz az átvétel és a fizetés késleltetésére.

Néha olyan feature-ök lefejlesztését akarják kicsikarni az UAT után, amire eredetileg nem gondoltak, a következő körítéssel: "Oké hogy a specben nem volt explicite benne, de enélkül a rendszer használhatatlan."

Egyébként jó dolog az UAT, ha az összes fél korrekt.

@tvk: a fizetés késleltetésére...

Igen, van ilyen is, de ez nem a tesztelési blog témaköre. Tudnék én is mesélni...

De azért ezzel nem értek egyet. Lehet így is használni az UAT-ot, de nem ez az alapvető célja. Ha nem lenne UAT mi alapján veszi át az ügyfél a rendszert?

Valóban gond van az elnevezéssel.

Az első probléma, hogy az ügyfél és a felhasználó nem tudják, mi ez. Számtalan esetben kellett elmagyaráznom, hogy miért csináljuk ezt, mi a célja, és miért nem tudja az IT önállóan megcsinálni (mert a felhasználók ennek örültek volna).

A másik probléma, hogy habár ez tesztelés, de ez az a pont, amikor - sajnos - a felhasználó szembesül az elkészült termékkel.
Tudom, hogy erről nem a UAT tehet, de bizony sok ember vizuális típus. Ha elolvas egy doksit, attól még nem áll össze a fejében, de ha meglátja és kattintgat, akkor 5 perc alatt megérti. Na és ekkor jönnek az ötletek...

Szerintem az ügyfél-érettség egy fontos szintje, amikor már érti/tudja mi az a UAT és mit kell ott csinálnia.
Annyira fontos szint, hogy nem is engednék senkit se öltönyt vásárolni, amíg ezt nem keni-vágja.

"A másik probléma, hogy habár ez tesztelés, de ez az a pont, amikor - sajnos - a felhasználó szembesül az elkészült termékkel."

Ha ez így van, akkor az sales/projekt menedzsment hiba.

A projekt során a megfelelő fázisban meg kell győződni róla, hogy az ügyfél tudja, hogy mit rendelt, és tudja, hogy mit fog kapni. Ellenkező esetben előfordulhat, hogy nem tudja, és nem lesz elégedett. Ennek vannak különböző módjai, de persze nincs egyedül üdvözítő megoldás.

Minden ilyen irányú tevékenység (kezdve a képernyő terveket bemutató ppt slide-októl, és akár prototípus fejlesztésig) költség. Minél részletesebben mutatja be, hogy mi is fog elkészülni, annál többe kerül. És meg kell találni azt a minimális költségű megoldást, ami már elég.

@akocsis: abszolút egyetértek. Nagyon kellemetlen helyzet amikor a user először szembesül az új bevezetésre váró rendszerrel, és SEMMI nem működik. Aztán amikor meg olyat adunk át ami csak kicsit szebb, de minden kontrol kb ugyanott van, és minden hotkey működik akkor viszont a felhasználó hozzáállása maximálisan pozitív.

Ez szerintem hulyeseg: "Mert technikai és kicsit sem üzleti szemléletű az informatika? Pedig nem ártana."
- Az informatika sokszor uzleti szemleletu, es ez elegge art is! A vegtermek minosegeben legtobb esetben.. Maskeppen: Ha nem uzleti celbol keszitenenek szoftvereket, hanem azert, hogy hasznalhato legyen a 'user/felhasznalo' szamara elfogadott modon es informatikai minosegi szempontbol is elfogadottan, es talan nem azon menne a harc hogy 'uzleti szempotok' szerint legyen jo akkor talan lehet, hogy mindenki jobban jarna. Ez utobbi sok esetben egyaltalan nem azonos ugyanis a szakmai minoseggel es ez baj. Nem tesz jot mert:
- Az ugyfel abban a hitben fizet, hogy valami nagyon profi dolgot kapott pedig ez egyaltalan nem biztos,
- A fejlesztoceg hirneven sokszor csorba esik a minosegen aluli, de draga vegtermekek miatt,
- A programozok egy ido utan kihanyak a beluket is azert, amit kiadnak a kezuk kozul.
Persze ott az erem masik oldala: van aki szerint ezzel a filozofiaval nem lehet megelni, de az ne hivja magat informatikusnak, es legfokeppen ne akarka definialni az informatikat. Az informatika nem az uzletrol szol, ezert nem uzleti szemleletu. Az informatika technologiakrol es mernoki munkarol szol. Az uzletrol egeszen mas szakma gondoskodik, nem veletlenul NEM az informatikusok adjak el az informatikai termekeket. (szerintem)

Elég zavaros fejtegetés. A programozó szempontjából bizony az ügyfél a felhasználó és ő fizet (ki más?). Hogy az ügyfélnék fizikailag kik és hányan használják a programozó által készített felületet az miért kellene, hogy érdekelje a programozót??

Az ügyfél azaz felhasználó (user) egy jogi személyt jelöl és nem egy egyént.

@Akron: A felhasználó a Józsi néni, aki a gép előtt ül. Az ügyfél pedig a vezérigazgató, aki esetleg soha az életben nem ül le az ügyviteli szoftver elé.

@Verhás Péter: Az ügyfeled a cég (vezérigazgatóval, Józsi nénivel)
A cég ellenőrzi le és veszi át a munkát (vagy sem).
Hogy cégen belül mi történik (személy szerint ki dönt) az ebből a szempontból nem lényeges.