Mit jelent az UAT?

Az UAT (User Acceptance Testing), magyarul Felhasználói Elfogadási Tesztelés, a szoftvertesztelési folyamat utolsó fázisa, amelyben a végfelhasználók vagy üzleti képviselők ellenőrzik, hogy a szoftver megfelel-e az üzleti követelményeknek és készen áll-e a valós használatra. Az UAT célja annak biztosítása, hogy a szoftver azt csinálja, amit a felhasználók elvárnak tőle a mindennapi üzleti működés során.

Az UAT különbözik a fejlesztők által végzett egységtesztektől (unit testing) és az integrációs tesztektől abban, hogy a szoftvert a tényleges üzleti felhasználók szemszögéből értékeli, valós üzleti folyamatok és adatok felhasználásával. Míg a technikai tesztelés a szoftver helyes működésére összpontosít ("megfelel-e a specifikációnak?"), az UAT az üzleti értékre koncentrál ("megoldja-e az üzleti problémát?").

A Capers Jones kutatásai szerint az UAT fázisban talált hibák javítása 10-100-szor drágább, mint ha a hibákat korábban, a fejlesztési fázisban fedezik fel. Ez hangsúlyozza az alapos korábbi tesztelés fontosságát, ugyanakkor az UAT nélkülözhetetlen a szoftver üzleti megfelelőségének végső validálásához.

Alfa tesztelés

Az alfa tesztelést a szervezeten belüli felhasználók végzik, általában a fejlesztési vagy tesztelési környezetben. Ez az első szint, ahol a fejlesztőcsapaton kívüli személyek használják a szoftvert.

Béta tesztelés

A béta tesztelést valódi végfelhasználók végzik saját környezetükben. A szoftvert korlátozott számú felhasználónak adják ki próbahasználatra, és visszajelzéseket gyűjtenek tőlük.

Szerződéses elfogadási tesztelés

Formális elfogadási tesztelés, amelynek sikeres befejezése szükséges a szerződéses kötelezettségek teljesítéséhez és a kifizetés jóváhagyásához. Különösen fontos a kiszerződött szoftverfejlesztési projekteknél.

Szabályozási elfogadási tesztelés

A szoftvert szabályozási követelményeknek való megfelelés szempontjából tesztelik. Különösen releváns a pénzügyi, egészségügyi és kormányzati szektorban.

Operatív elfogadási tesztelés (OAT)

Az üzemeltetési csapat által végzett tesztelés, amely a szoftver üzemeltethetőségét vizsgálja: mentés és visszaállítás, teljesítmény terhelés alatt, katasztrófa-helyreállítás és biztonsági szempontok.

1. Tervezés

• Az UAT hatókörének meghatározása: mely funkciók és üzleti folyamatok kerülnek tesztelésre.
• Tesztelők kijelölése: a megfelelő üzleti felhasználók azonosítása és bevonása.
• Tesztkörnyezet előkészítése: a termelési környezethez legközelebb álló tesztkörnyezet kialakítása.
• Tesztadatok előkészítése: valós vagy valóshoz hasonló adatok biztosítása a teszteléshez.
• UAT terv készítése: a tesztelés ütemtervének, kritériumainak és folyamatának dokumentálása.

2. Tesztesetek tervezése

• Üzleti forgatókönyvek (business scenarios) létrehozása, amelyek a mindennapi üzleti folyamatokat tükrözik.
• Az elfogadási kritériumok (acceptance criteria) alapján készített tesztesetek meghatározása.
• Pozitív és negatív tesztesetek kidolgozása.
• Szélsőséges esetek (edge cases) és hibakezelési forgatókönyvek előkészítése.

3. Tesztelés végrehajtása

• A tesztelők végrehajtják a teszteseteket a tesztkörnyezetben.
• A talált hibákat dokumentálják és jelentik a fejlesztőcsapatnak.
• A javított hibákat újratesztelik.
• Az eredményeket dokumentálják és összehasonlítják az elfogadási kritériumokkal.

4. Értékelés és döntés

• A teszteredmények összesítése és értékelése.
• Go/No-Go döntés: a szoftver készen áll-e az éles üzembe helyezésre.
• Az elfogadási dokumentum aláírása (sign-off).
• Az esetleges ismert problémák dokumentálása és a kezelési terv rögzítése.

Az elfogadási kritériumok (acceptance criteria) azok a feltételek, amelyeknek teljesülniük kell ahhoz, hogy a szoftvert elfogadjuk. Jól meghatározott elfogadási kritériumok:

• Egyértelműek: minden kritérium félreérthetetlenül megfogalmazott.
• Mérhetők: objektíven eldönthető, hogy a kritérium teljesült-e.
• Relevánsak: a valós üzleti igényekre vonatkoznak.
• Tesztelhetők: a tesztelők képesek ellenőrizni a teljesülésüket.

Példa elfogadási kritériumokra

Adva: egy regisztrált felhasználó a bejelentkezési oldalon Amikor: helyes felhasználónevet és jelszót ad meg, majd a "Bejelentkezés" gombra kattint Akkor: átirányításra kerül a főoldalra 3 másodpercen belül És: a nevét tartalmazó üdvözlő üzenet jelenik meg És: a legutóbbi belépés dátuma frissül a rendszerben

UAT a Scrumban

A Scrum keretrendszerben az UAT leggyakrabban a Sprint Review során vagy közvetlenül azt megelőzően történik. A Product Owner és a stakeholderek megvizsgálják a Sprint során készített inkrementumot és eldöntik, hogy az megfelel-e az elfogadási kritériumoknak.

A Definition of Done (DoD) tartalmazhatja az UAT sikeres befejezését mint feltételt, ami biztosítja, hogy az elfogadási tesztelés a fejlesztési folyamat szerves részévé válik.

UAT a Kanbanban

A Kanban rendszerben az UAT gyakran egy külön oszlopként jelenik meg a tablón, amely lehetővé teszi a tesztelési folyamat vizualizálását és a WIP korlátozását. Ez biztosítja, hogy az UAT ne váljon szűk keresztmetszetté a folyamatban.

Continuous Testing

A modern DevOps gyakorlatban az UAT egyre inkább automatizált és folyamatos folyamattá válik. Az automatizált elfogadási tesztek (pl. BDD-alapú tesztek Cucumber vagy SpecFlow segítségével) lehetővé teszik, hogy az üzleti forgatókönyvek ellenőrzése minden build során automatikusan megtörténjen.

• Jira / Azure DevOps: tesztesetek kezelése és hibakövetés.
• TestRail: dedikált tesztmenedzsment eszköz.
• Zephyr: Jira integrált tesztmenedzsment bővítmény.
• Cucumber / SpecFlow: BDD-alapú elfogadási tesztek automatizálása.
• Selenium / Playwright: webes alkalmazások automatizált UAT-je.
• UserTesting / Maze: felhasználói tesztelési platformok.

• Nem megfelelő felhasználók bevonása: ha a tesztelők nem a tényleges végfelhasználók, a teszt nem feltétlenül tükrözi a valós használati mintákat.
• Elégtelen tesztelési idő: az UAT-ra gyakran kevés időt hagynak, ami felszínes teszteléshez vezet.
• Nem valós tesztadatok: szintetikus adatokkal végzett tesztelés nem feltétlenül fed fel valós problémákat.
• Hiányzó elfogadási kritériumok: pontos kritériumok nélkül szubjektívvé válik az elfogadás.
• Nem dokumentált eredmények: a tesztelési eredmények dokumentálása nélkül nehéz nyomon követni a minőséget.

Mi a különbség az UAT és a rendszertesztelés között?

A rendszertesztelést a QA csapat végzi, és a szoftver technikai működésére összpontosít: megfelel-e a specifikációnak. Az UAT-ot a végfelhasználók végzik, és az üzleti értékre koncentrál: megoldja-e az üzleti problémát és használható-e a mindennapi munkában.

Ki végzi az UAT-ot?

Ideális esetben a tényleges végfelhasználók vagy azok üzleti képviselői. Fontos, hogy a tesztelők ismerjék az üzleti folyamatokat és képesek legyenek értékelni, hogy a szoftver megfelel-e az üzleti igényeknek. A fejlesztők nem végezhetik az UAT-ot, mert nem tudják objektíven értékelni a saját munkájukat.

Automatizálható-e az UAT?

Részben igen. A BDD (Behavior-Driven Development) megközelítéssel az elfogadási kritériumok automatizált tesztekké alakíthatók. Azonban a teljes UAT nem automatizálható, mert a felhasználói élmény, a használhatóság és az üzleti folyamatok teljes kontextusában történő értékelés emberi megítélést igényel.

Mi történik, ha az UAT sikertelen?

Ha az UAT során kritikus problémákat találnak, a szoftver nem kerül éles üzembe helyezésre. A fejlesztőcsapat javítja a hibákat, és a tesztelést megismétlik. Kisebb problémák esetén a csapat dönthet úgy, hogy a szoftvert kiadja az ismert hibákkal együtt, ha azok nem akadályozzák az üzleti működést.

Mennyi ideig tart egy tipikus UAT?

Az UAT időtartama függ a szoftver méretétől és összetettségétől. Egy kisebb funkció UAT-je 1-3 napot vehet igénybe, míg egy komplex rendszer teljes UAT-je 2-4 hetet vagy akár többet is. Az agilis módszertanok esetében az UAT folyamatosan, minden Sprint végén történik, kisebb egységekben.