Automatizált tesztelés minden új verzió előtt, hogy garantálja a minőséget!

Automatizált tesztelés új build kiadása előtt

Az Automatizált tesztelés akkor hasznos, amikor egy új alkalmazásverziót vagy webes felületet még kiadás előtt ellenőrizni kell, gyorsan és ismételhető módon. A magánügyfél ilyenkor nem céget keres, hanem olyan online szakembert, aki átnézi a működést, beállítja a tesztelési folyamatot, és érthető hibajelentést ad. Ez főleg akkor fontos, ha már működik egy rendszer, de minden módosítás után fennáll a veszély, hogy valami régi funkció elromlik.

Én azt látom, hogy sok ügyfél nem magát a tesztelést keresi először, hanem biztonságot. Azt szeretné tudni, hogy az új build nem rontja el a belépést, a rendelést, a fizetést, az űrlapokat, az értesítéseket vagy a felhasználói adatokat. Erre az automatizált ellenőrzés jó válasz lehet, de csak akkor, ha a feladat pontosan van leírva. Egy tesztelő nem találja ki magától az üzleti logikát, ezért a rövid, világos leírás sok időt spórol.

A Qjob.hu felületén magánszemélyek is találhatnak olyan szabadúszót, aki távolról vállal tesztelési automatizálást, hibakeresést és ellenőrzési forgatókönyvek készítését. A munka jellemzően online zajlik. A megbízó hozzáférést, próbafiókot, rövid leírást és határidőt ad, a szakember pedig tesztlistát, hibajegyeket, rövid összefoglalót vagy futtatható teszteket ad át.

Automatizált tesztelés ára és munkadíjak

Az automatizált tesztelés ára több tényezőtől függ. Számít a rendszer bonyolultsága, a tesztelendő felületek száma, a korábbi dokumentáció minősége, a használt technológia és az is, hogy egyszeri ellenőrzésről vagy hosszabb támogatásról van szó. Szerintem a túl olcsó munka ezen a területen gyakran gyengébb minőséget jelent, mert a tesztelési automatizálás nem csak kattintgatás. Gondolkodást, figyelmet és pontos hibaleírást igényel.

Az áraknál nem érdemes csak a legalacsonyabb ajánlatot nézni. Egy drágábbnak tűnő tesztelő néha kevesebb hibát hagy bent, és jobb hibajegyeket ír. Ez végül olcsóbb lehet, mint egy gyors, de felületes ellenőrzés. Tapasztalatom szerint akkor lesz korrekt az ajánlat, ha a szakember először rákérdez a funkciókra, a határidőre, a hozzáférésekre és arra, hogy mi számít elfogadható eredménynek.

Automatizált teszteléshez megfelelő szakember

A megfelelő online szakember nem csak azt mondja, hogy tesztelni fog. Elmagyarázza, milyen részeket tud automatizálni, mi marad kézi ellenőrzés, és hol lehetnek kockázatok. Fontos, hogy legyen gyakorlata hibajegyek írásában, mert egy rosszul megfogalmazott hiba sok félreértést okoz a fejlesztőnek és a megbízónak is.

Érdemes rákérdezni korábbi munkákra, de nem kell hosszú portfólió minden esetben. Egy kisebb feladathoz elég lehet egy világos próbamunka vagy egy rövid szakmai beszélgetés. A jó szabadúszó érthetően beszél a módszerről. Nem bújik el technikai szavak mögé. De azt is jelzi, ha a feladat túl tág, vagy ha a rendszer állapota miatt először alapvető hibák javítására lenne szükség.

Sokan ott hibáznak, hogy csak azt kérik, hogy legyen minden letesztelve. Ez nem elég konkrét. Jobb azt megadni, hogy melyik új build, melyik funkció, melyik felhasználói út és melyik határidő fontos. Ha például a fizetési folyamat, a regisztráció vagy az admin felület a legkritikusabb, ezt külön jelezni kell. Így a tesztelő a legfontosabb részekre figyel először.

Tesztelési automatizálás online munkamenetben

A tesztelési automatizálás teljesen jól végezhető távolról. A megbízó átadja a hozzáféréseket, a tesztkörnyezet címét, a próbafelhasználókat és a rövid leírást. A szakember ezután beállítja a tesztforgatókönyveket, futtatja az ellenőrzéseket, majd jelenti az eredményeket. A kommunikáció általában üzenetben, videóhívásban vagy közös feladatkezelőben történik.

A munka elején érdemes rögzíteni, hogy mi az átadás formája. Lehet egyszerű hibajegyzék, táblázat, képernyőképes összefoglaló, rövid videó vagy futtatható tesztcsomag. Ha a megbízó nem technikai ember, akkor különösen fontos a közérthető leírás. Nem elég annyi, hogy a teszt sikertelen. Tudni kell, mi történt, hogyan lehet megismételni, és mi lehet a következménye.

Volt olyan eset, amikor egy ügyfél csak egy apró módosítást kért az alkalmazásban, és emiatt nem tervezett külön ellenőrzést. A módosítás után a regisztráció működött, de a jelszó visszaállítása elromlott. Egy egyszerű regressziós teszt ezt azonnal kimutatta volna. Az ilyen helyzetek miatt nem tartom feleslegesnek az automatizált teszteket még kisebb frissítés előtt sem.

Automatizált ellenőrzés új build előtt

Új build előtt az automatizált ellenőrzés célja nem az, hogy minden elképzelhető hibát megtaláljon. Inkább az, hogy a legfontosabb működési útvonalak gyorsan át legyenek nézve. Ez lehet belépés, jogosultság, adatmentés, keresés, rendelés, űrlapküldés, értesítés vagy más kulcsfolyamat. A pontos lista mindig a rendszer jellegétől függ.

Szerintem az a jó megközelítés, ha először a legnagyobb kárt okozó hibákra figyelünk. Ha egy szöveg elcsúszik, az kellemetlen. Ha a felhasználó nem tud belépni, az már komoly probléma. Ha az adatvesztés veszélye áll fenn, az elsőbbséget élvez. A tapasztalt szakember ilyen sorrendet tud felállítani, és nem veszik el a kevésbé fontos részletekben.

Az Automatizált tesztelés akkor ad valódi értéket, ha az eredmény nem csak technikai lista. A megbízónak tudnia kell, hogy kiadható-e a build, milyen hibák maradtak, melyek sürgősek, és melyek várhatnak. Ez nem marketinganyag, hanem döntési alap. Egy jó jelentés rövid, de nem homályos.

Gyakori hibák automatizált tesztelésnél

Az egyik gyakori hiba, hogy a megbízó túl későn keres szakembert. Ha a build már aznap kiadásra vár, kevés idő marad tisztességes ellenőrzésre. Lehet gyors tesztet kérni, de az nem ugyanaz, mint egy átgondolt tesztcsomag. A kapkodás sokszor rosszabb döntéseket hoz.

A másik gond a hiányos hozzáférés. A tesztelő nem tud dolgozni, ha nincs próbafiók, nincs jogosultság, nem ismert a tesztkörnyezet, vagy nem világos, melyik verziót kell nézni. És van még egy probléma. Sok ügyfél nem különíti el az éles rendszert és a tesztkörnyezetet. Ez kockázatos, mert egy ellenőrzés közben véletlenül valódi adatok is sérülhetnek.

A túl általános elvárás is gondot okoz. A teljes körű tesztelés jól hangzik, de valójában ritkán pontos. Jobb kisebb, mérhető feladatot adni. Például a felhasználói regisztráció és a fizetés ellenőrzése három böngészőben. Vagy az admin felület jogosultságainak ellenőrzése öt szerepkörrel. A konkrét kérésből jobb eredmény születik.

Minőség, határidő és eredményátadás

A minőség nem csak azon múlik, hány teszt futott le. Fontos a tesztek értelme, a hibák leírása, a határidő betartása és az átadott anyag használhatósága. Egy online szakember akkor dolgozik jól, ha a megbízó a végén tud dönteni. Javítani kell, újra kell futtatni, vagy kiadható a verzió.

Az eredményátadásnál érdemes kérni rövid összegzést. Mi lett ellenőrizve. Mi működött. Mi hibás. Mi kritikus. Mi ajánlott, de nem sürgős. Ez a néhány sor sokkal többet ér, mint egy hosszú, rendezetlen lista. A jó hibajelentés tartalmazza a lépéseket, a várt működést, a tényleges működést és lehetőség szerint képernyőképet is.

Az Automatizált tesztelés hosszabb távon akkor térül meg igazán, ha nem egyszeri pánikmegoldásként jelenik meg. Ha minden új build előtt ugyanazok az alaptesztek lefutnak, kevesebb lesz a meglepetés. És az ügyfél is nyugodtabban dönthet. Nem azért, mert minden hiba kizárható, hanem mert a fő kockázatok láthatóvá válnak.