Szoftver átvételi teszt: mikor áll készen az üzleti rendszer?

Hogyan ellenőrizd megrendelőként az új üzleti szoftvert? Gyakorlati UAT-terv, tesztesetminta, hibabesorolás és ellenőrzőlista az élesítési döntéshez.

Buda Sándor · 2026-09-20

A fejlesztő bemutatja az új rendszert: működik a belépés, megnyílnak az űrlapok, elkészül egy riport. Ettől még nem biztos, hogy hétfő reggel a csapat valóban át tud állni rá. A szoftver átvételi teszt feladata annak ellenőrzése, hogy a megállapodott üzleti folyamatok a gyakorlatban is végigvihetők, és az ismert hibák mellett vállalható-e az indulás.

Ez az útmutató cégvezetőknek, folyamatgazdáknak és bevezetést koordináló munkatársaknak szól. Egy használható tesztterv összeállításától az élesítési döntésig vezet végig, konkrét mintával. A példák szemléltető helyzetek, nem BudaWeb-ügyféltörténetek.

Mit vizsgál az átvételi teszt?

A felhasználói átvételi tesztet gyakran UAT-nak nevezik az angol User Acceptance Testing alapján. A központi kérdése: az elkészült rendszer támogatja-e azokat a feladatokat, amelyekre megrendeltük? Például az értékesítő létre tud-e hozni egy ajánlatot, a vezető jóvá tudja-e hagyni, és a pénzügy a megfelelő adatokat kapja-e meg.

Az ISTQB átvételi teszteléssel foglalkozó szakmai anyaga is hangsúlyozza az üzleti szereplők és a tesztelők együttműködését. A megrendelő ismeri a munkafolyamatot, a fejlesztő és a tesztelő pedig segít ellenőrizhető esetekké alakítani az elvárásokat. Az alábbi gyakorlati keret ezt a közös munkát támogatja.

Az UAT mellett továbbra is szükség van fejlesztői, integrációs, teljesítmény- és megfelelő biztonsági vizsgálatokra. Az üzleti felhasználó sikeres próbamunkája önmagában nem bizonyítja például az alkalmazás ellenállását egy támadással szemben. Az üzleti folyamatokra épülő szoftverfejlesztés átvételi tervében ezeknek külön felelőse és eredménye legyen.

Az elfogadási feltételeket az első bemutató előtt tisztázzátok

A „legyen egyszerű” vagy „működjön gyorsan” fontos igény, de önmagában nem eldönthető tesztfeltétel. Írjátok le, ki végez el milyen feladatot, milyen kiinduló adatokkal, és mi számít helyes eredménynek. Így a próba végén közös viszonyítási pont alapján beszéltek a készültségről.

Az „ajánlatkezelés kész” helyett például ez vizsgálható: az értékesítő létrehoz egy háromtételes ajánlatot, amely a kedvezményhatár túllépése miatt vezetői jóváhagyást kér. Jóváhagyás előtt nem küldhető ki, utána a jóváhagyott összeggel készül el a dokumentum. A módosítás és a döntés visszakereshető.

Különítsétek el a hibát az új igénytől

Ha a megállapodott kedvezményszabály nem érvényesül, az hibajelzés. Ha a teszt közben merül fel először egy új jóváhagyói szint, az változtatási igény lehet. Mindkettő fontos, de eltérő döntést igényel. A besorolást az elfogadott követelményhez kapcsoljátok, és az új igény üzleti hatását külön értékeljétek.

A vitás eseteket ne a tesztelőnek kelljen egyedül eldöntenie. Legyen kijelölt üzleti felelős, aki a fejlesztővel együtt tisztázza, hogy eltérő értelmezésről, hiányzó részletszabályról vagy valóban új funkcióról van szó. A döntés kerüljön ugyanabba a nyilvántartásba, ahol az eredeti jelzés található.

Folyamatokat válasszatok ki, ne menüpontokat

Egy menülista alapján könnyű minden képernyőt megnyitni, miközben a valódi munkavégzés hibája rejtve marad. A tesztterv alapja inkább a munka útja legyen: honnan érkezik az adat, ki dolgozik vele, milyen döntések születnek, és hol jelenik meg a végeredmény.

Egy CRM-bevezetés és értékesítési automatizálás esetén ilyen folyamat az érdeklődő rögzítése, felelőshöz rendelése, utánkövetése, ajánlattá alakítása és lezárása. A teszt akkor teljes, ha az üzleti státusz, a feladatok és a kimutatás is összhangban marad. A köztes képernyők sikeres mentése csak részeredmény.

Először a legnagyobb következménnyel járó folyamatokat ellenőrizzétek. Előnyt élvezzen az, amelynek hibája leállítja a munkát, téves pénzügyi adatot eredményez, jogosulatlan hozzáférést ad vagy nehezen visszafordítható műveletet indít. A gyakoriság is számít: egy napi rutinfeladat apró hibája sokszor ismétlődő terhet okozhat.

Egy teszteset, amelyet más is meg tud ismételni

A jó teszteset rövid, de nem hagyja találgatni a végrehajtót. Egyetlen döntést vagy összefüggő munkafolyamatot ellenőrizzen. Ha túl sok külön célt zsúfoltok bele, egy hiba után nehéz lesz megmondani, melyik rész tekinthető sikeresnek.

1. Azonosító és cél: UAT-07, kedvezményes ajánlat jóváhagyása.
2. Előfeltétel: létezik tesztügyfél, három termék, értékesítői és vezetői tesztfiók.
3. Kiinduló adat: a kedvezmény meghaladja a tesztkörnyezetben beállított jóváhagyási határt.
4. Lépések: az értékesítő ment, jóváhagyást kér, a vezető ellenőriz és jóváhagy, az értékesítő előállítja a dokumentumot.
5. Elvárt eredmény: a jóváhagyás előtt nincs kiküldés; utána a jóváhagyott végösszeg szerepel a dokumentumban.
6. Bizonyíték: ajánlatazonosító, tesztelt verzió, időpont, eredmény és szükség esetén képernyőkép.

Az összegeket előre számoljátok ki egy független mintában. Ha csak azt ellenőrzitek, hogy a program ugyanazt az összeget mutatja két képernyőn, egy következetesen hibás számítás is átmehet. Az elvárt eredmény forrása az üzleti szabály legyen, ne a vizsgált alkalmazás saját kimenete.

A kivételek mutatják meg, mennyire használható a rendszer

A szokásos, hibamentes út mellett tervezzetek elutasítást, javítást és félbehagyott folyamatot is. Mi történik, ha hiányzik egy kötelező adat? Visszaadható-e az ajánlat javításra? Megmarad-e a korábbi döntés nyoma? Ezek hétköznapi helyzetek, amelyek nélkül a rendszer működéséről hiányos képet kaptok.

Jogosultság és helyettesítés

Ugyanazt az esetet megfelelő és nem megfelelő szerepkörrel is próbáljátok ki az engedélyezett tesztkörnyezetben. Az értékesítő láthatja-e más csapat ügyfelét? Egy visszavont hozzáférésű munkatárs tud-e tovább dolgozni? A helyettesítő vezető valóban csak a neki kijelölt időszakban és körben dönthet-e?

A felületi ellenőrzés során azt is figyeljétek, hogy érthető-e az elutasítás. A tiltott művelet ne tűnjön sikeresnek, és ne hagyjon félkész üzleti állapotot. A mélyebb jogosultsági és biztonsági ellenőrzést külön műszaki feladatként kérjétek számon; a gomb elrejtése nem teljes körű védelem.

Ismétlés és párhuzamos munka

Próbáljátok ki az ismételt mentést, az oldal újranyitását és két felhasználó egyidejű módosítását. Egy dupla kattintásból ne keletkezzen két üzleti megrendelés. Ha ketten szerkesztenek ugyanazt az adatot, az eredmény kövesse a megállapodott ütközéskezelési szabályt, és a munkatárs értse, mi maradt meg.

Az integrációt a fogadó rendszerben is ellenőrizd

Az „elküldve” üzenet még nem feltétlenül jelenti azt, hogy a másik rendszerben is helyesen létrejött a rekord. Az átvételi teszt terjedjen ki az adat útjára: azonosítók, státuszok, összegek és kapcsolatban álló tételek egyezzenek a küldő és a fogadó oldalon.

Egyeztetett tesztben vizsgáljátok meg a külső szolgáltatás átmeneti elérhetetlenségét is. A felhasználó lássa, hogy feldolgozásra váró tételről vagy végleges hibáról van-e szó. Legyen felelőse a javításnak és biztonságos módja az újrapróbálásnak. Az ismétlés ne duplázza a már sikeresen átvitt rekordot.

Ha a háttérfolyamatokat egyedi backend kezeli, a Laravel-alapú üzleti alkalmazás fejlesztésénél az átadási csomagba az API-k, az ütemezett feladatok és a hibajelzések leírása is kerüljön be. A technológia neve helyett a megfigyelhető működésből induljatok ki az elfogadásnál.

Készíts használható tesztkörnyezetet és tesztadatot

A tesztkörnyezet legyen azonosítható, és legyen világos, melyik alkalmazásverzió fut benne. Ha a teszt közepén észrevétlenül új kiadás érkezik, az eredmények összehasonlíthatatlanná válhatnak. Jelöljétek ki a frissítési időpontokat, és minden javításnál rögzítsétek, mely eseteket kell újra végrehajtani.

A tesztadatok között legyen egyszerű, összetett és hiányos eset is. Egyetlen mintavásárló helyett használjatok eltérő státuszokat, több telephelyet vagy különböző jóváhagyási útvonalakat, ha ezek a napi működés részei. Alapesetben mesterséges, a valós szerkezetet követő adatokat készítsetek, és korlátozzátok a tesztfiókok hozzáférését.

Az értesítések és külső műveletek célpontját is ellenőrizzétek. Egy tesztajánlat ne menjen valódi ügyfélnek, egy próbarendelés pedig ne indítson tényleges szállítást. A tesztindítás feltétele legyen annak igazolása, hogy a használt kapcsolatok a megfelelő tesztmódra vagy elkülönített célrendszerre mutatnak.

Oszd ki a felelősséget és a tesztelésre szánt időt

Ne csak azt írjátok be a naptárba, hogy „tesztelés”. Minden folyamathoz legyen név szerint felelős végrehajtó, üzleti döntéshozó és műszaki kapcsolattartó. A napi munkát végző kolléga fontos résztvevő: ő veszi észre, ha egy mező értelmezése vagy a lépések sorrendje akadályozza a feladatát.

A tesztelésre biztosított idő ténylegesen rendelkezésre álló kapacitás legyen. Aki közben teljes ügyfélterhelést visz, könnyen csak a legegyszerűbb eseteket próbálja ki. A tervben külön idő kell a végrehajtásra, a hibák tisztázására, a javítás utáni ellenőrzésre és a döntés előkészítésére.

A fejlesztő bemutatója jó belépő, de utána a felhasználó önállóan is hajtsa végre a feladatot. A folyamatos szóbeli segítség elfedheti a használhatósági és dokumentációs hiányokat. Jegyezzétek fel, hol kellett magyarázat: ebből képzési feladat vagy felületi javítás is következhet.

A hibajegy a javításhoz adjon elegendő információt

A „nem működik az export” helyett írd le a szerepkört, a verziót, a használt rekordot, a pontos lépéseket, az elvárt és a tényleges eredményt. Jelöld, hogy minden próbánál vagy csak bizonyos adatokkal jelentkezik-e a hiba. A képernyőkép kiegészítés, nem helyettesíti a leírást.

Használhattok ilyen mintát: „Értékesítői fiókkal a lezárt tesztajánlat exportja üres fájlt ad. Elvárt: három tétel és a jóváhagyott végösszeg. Tényleges: megnyitható, de üres dokumentum. Két ismétlésből kétszer jelentkezett. Érintett verzió és rekordazonosító mellékelve.” Ez már vizsgálható kiindulópont.

A súlyosságot az üzleti következményhez kösd

Indulást blokkoló lehet az adatvesztés, a jogosulatlan hozzáférés vagy egy nélkülözhetetlen folyamat teljes leállása. Jelentős hiba esetén létezhet kerülőút, de annak ideje, felelőse és kockázata legyen ismert. Egy megjelenési eltérés súlyossága attól függ, okoz-e félreértést vagy hibás döntést.

A javítási sorrend és a súlyosság nem mindig azonos. Egy kisebb, minden munkatársat naponta érintő hiba hamarabb sorra kerülhet, mint egy ritka eltérés. A prioritást közösen állapítsátok meg, de a vállalhatatlan kockázatot ne minősítsétek át pusztán a közelgő határidő miatt.

Mit kell újratesztelni egy javítás után?

Először ismételjétek meg a hibát feltáró esetet ugyanazokkal az adatokkal. Ezután nézzétek meg a kapcsolódó működést is: egy kedvezményszámítás javítása érintheti az ajánlatot, az exportot és a riportot. A fejlesztő jelezze az érintett területet, az üzleti felelős pedig válassza ki a fontos ellenőrzéseket.

A korábban működő funkciók ismételt ellenőrzése a regressziós tesztelés része. Legyen egy rövid, rendszeresen futtatható alapcsomag a legfontosabb üzleti utakból. A megismételhető esetek egy része automatizálható, de a felhasználói értelmezést és a teljes munkafolyamat elfogadhatóságát továbbra is vizsgálni kell.

Élesítés előtt legyen egyértelmű döntési pont

A sikeres tesztek aránya önmagában félrevezető. Sok apró siker mellett egyetlen hibás számlázási vagy jogosultsági folyamat is megakadályozhatja az indulást. A döntési összefoglaló ezért a kritikus folyamatok állapotát, a nyitott hibákat, a hiányzó vizsgálatokat és a vállalt kivételeket mutassa.

• Minden induláshoz szükséges üzleti folyamatot végrehajtott a kijelölt felhasználó.
• A kritikus eredményeket előre meghatározott elvárásokhoz hasonlítottátok.
• Nincs megoldatlan, indulást blokkoló hiba.
• A vállalt kivételekhez tartozik felelős, kerülőút és javítási terv.
• A megfelelő műszaki vizsgálatok eredménye és a tesztelt verzió ismert.
• A betanítás, a támogatási kapcsolat és az indulási feladatlista rendelkezésre áll.
• Meghatároztátok, ki és milyen eseménynél állítja meg az átállást.

Az üzleti teszt sikerességét és az élesítés engedélyezését külön is rögzíthetitek. Előfordulhat, hogy a funkciók megfelelnek, de egy külső kapcsolat, az adatbetöltés vagy az üzemeltetési előkészítés még hiányzik. Ilyenkor pontosan írjátok le, mire terjed ki az elfogadás, és mi maradt feltétel.

Összegzés: bizonyíték alapján vedd át a rendszert

A jó szoftverátvétel alapja az előre egyeztetett elvárás, a valós munkafolyamatot követő próba és a visszakereshető eredmény. Nem kell minden kattintást hosszú dokumentumba foglalni. Azt viszont tudnotok kell, ki mit ellenőrzött, milyen verzión, milyen eredménnyel, és ki vállalja a fennmaradó kockázatot.

Első lépésként válaszd ki a bevezetés három legfontosabb üzleti folyamatát, és mindegyikhez írj egy sikeres, egy hibás és egy kivételes helyzetet. Ezt már érdemben át lehet beszélni a fejlesztővel. Ha új rendszer készül, a BudaWeb egyedi üzleti szoftver tervezési és fejlesztési szolgáltatásánál az ajánlatkérés részeként az átadás feltételeit és a tesztelési felelősségeket is érdemes tisztázni.