Adatvezérlés 1.

Bevezető

Bocsánat, ez a rész csak egy felvezető a valódi tipp és trükk előtt. Reményeim szerint azért ezt is elolvasod.

2000 ügyfél, 5 ügyintéző

A történet valós eseményeken alapul, de a pontos számokat és neveket megváltoztattuk a túlélőkre való tekintettel. Az arányokat változatlanul hagytuk, ezt szintén a túlélőkre való tekintettből tettük.

Szóval réges-régen, egy messzi-messzi közepesen nagy cégnél teszteléssel töltöttem az időm. Nyílt iroda volt, mindent hallottam, amit a mellettem dolgozó, ügyfelek adatait kezelő (backoffice) munkatársakkal történt. Minden munkahelyi pletykáról tudtam (sajnos). Itt fejlesztettem ki azt a meditációs technikát, hogy munka közben hogyan zárjak ki mindenkit magam körül. De ez technika egy másik történet része.

Nagy zúgolódásra lettem figyelmes. Valami nagy dolog volt készülőben. Évnyitás. Valami programhiba a cég 2000 ügyfelét inaktív állapotba helyezte év végén. Megvolt a lista, kik jártak így. Cég policy és külső, törvényi elvárások miatt adatbázisban nem lehetett hekkelni. Szóval a mellettem dolgozó 5 kolléga kapta meg a feladatot, hogy minden egyes ügyfélnél menjenek az ügyfélprofilra és állítsák át az inaktív kapcsolót aktív állapotra.

Megszámolták: 15 klikkelés, egy id beírás kereséssel és még egy mezőbe is bele kellett írni egy megjegyzést, miszerint „Programhiba miatt inaktívált ügyfél újra aktiválása”: ez ügyfelenként minimum 30-45 másodperc jobb esetben. 2000 ügyfélnél ez kerekítve 17 óra megállás nélküli emberidő. Reálisan ez az 5 ügyintéző fejenként kb. fél napos melója. Nem éppen a legkellemesebb meló, így a zúgolódást megbocsájtottam. Éppen visszameditáltam magam a tesztesetírás csodálatos világába, amikor egy varázsige kezdett körvonalazódni elmém egyik tesztelésre fenntartott zugában. Igen, egyre tisztábban láttam az átkot megtörő varázsigét: adatvezérelt tesztautomatizálás.

Volt már tesztautomatizálás kezdemény a cégben, így gyorsan össze lehetett kötni a megfelelő szálakat és 1,5 óra múlva már mind a 2000 felhasználó vígan élte az aktív ügyfelek gondtalan életét. A világ újra megmenekült. Így sikerült elvennem néhány ügyintéző robotmunkáját, de örültek neki.

Csiribi: Adatvezérelt tesztautomatizálás

Az előző történet megoldása az volt, hogy a cégnél rendszeresített felületi tesztautomatizáló eszközzel, a QTP- vel rögzítettem egy ügyfél esetén a vissza-aktiválási folyamatot. Nem foglalkoztam azzal, hogy szép legyen a szkript, csak annyit reszeltem rajta, hogy stabilan menjen. A rögzített ügyfél ID-t kicseréltem egy változóval és megkértem a rendszert , hogy menjen végig az ügyfelek Excel listáján és mindegyik ügyfélnél az ID értékét vegye ki, tegye a változóba és ezzel az értékkel futtassa az egyetlen tesztet, ami készült.

A teszteset átlag 7 másodpercenként visszaaktivált egy ügyfelet. Fáradhatatlan munkájának köszönhetően 50 perc alatt végzett.

Ezután egy kis szkript módosítással még vissza is ellenőriztük, hogy mind a 2000 ügyfél vissza van-e aktiválva. (Azt a lépést kellett csak cserélni, ami klikkel a checkboxra arra, hogy az értékét ellenőrizte.)

Mindenki boldog volt.

Folytatás következik

A QTP nem volt olcsó eszköz. Az utódja sem olcsó. Sőt, drága.

A fiatalabbak kedvéért:

Nem mondhatom, hogy rossz eszköz, mert nagyon sokat tud. Viszont ár/értékben a Robot Framework sokkal jobb nála. (Nem utolsó sorban azért, mert a Robot Framework open source és teljesen ingyenes.) A következő részben megmutatom, hogy Robot Frameworkben hogyan tudod megvalósítani az adatvezérelt tesztelést.


Megosztás

Kérsz értesítést a legújabb cikkekről?

Kapcsolódó cikkek

Hogyan segíti az AI a tesztesetek generálását?

A modern szoftverfejlesztés egyik legnagyobb kihívása az idő. A sprintek rövidek, a funkciók száma folyamatosan nő, miközben a minőségi elvárások nem csökkennek. Ebben a feszített tempóban a teszt tervezése és a tesztesetek megírása gyakran a fejlesztési folyamat szűk keresztmetszetévé válik. Egy manuális tesztelő órákat tölthet azzal, hogy egy-egy komplex user story alapján pontról pontra kidolgozza

Hol bukik el leggyakrabban a szoftvertesztelés egy projektben? 4 szisztematikus hiba, amit nem szabad elkövetnetek

Minden projektmanager ismeri az érzést: a sprint végi demón minden zöld, az elfogadó tesztek átmentek, a csapat gratulál egymásnak – aztán az élesítés után két nappal becsörög az ügyfél, hogy egy kritikus üzleti folyamat nem működik. De hogyan juthatott keresztül egy ekkora hiba az egész tesztelési rendszeren? A válasz szinte sohasem az, hogy „a tesztelők

AI-alapú Szintetikus Tesztadat-generáló Rendszer Tesztelése

Bevezető Egy biztosítótársaság pénzügyi működésének és értékesítési hálózatának alapköve a jutalékelszámolás. Ha a jutalékszámítási rendszerben hiba lép fel, az nemcsak közvetlen anyagi veszteséget jelent, hanem azonnal erodálja az értékesítési ügynökök bizalmát is. Egy ilyen komplex rendszer teszteléséhez óriási mennyiségű, változatos és élethű életúttal rendelkező adatra van szükség. Ugyanakkor a szigorú adatvédelmi szabályozások (GDPR) miatt az

Scroll to Top