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

AI rendszerek tesztelése: miért teljesen más, mint egy hagyományos szoftveré?

Egyre több cég épít AI funkciót a termékébe: chatbotot az ügyfélszolgálatra, ajánlórendszert a webshopba, dokumentumfeldolgozót a háttérfolyamatokba, döntéstámogatót a szakértői munkába. A vezetők jó része ilyenkor ugyanúgy áll a teszteléshez, mint bármely más szoftvernél: „írjuk meg a teszteseteket, nézzük meg, átmegy-e”. Csakhogy egy AI rendszer másképp működik, és ami fontosabb: másképp is hibázik. Ezért másképp

AI által generált kód = új QA kihívások

Az AI asszisztensek (a GitHub Copilottól a különféle nagy nyelvi modellekig) néhány év alatt a szoftverfejlesztés mindennapi eszközévé váltak. Egy funkció, amelynek megírása korábban órákba telt, ma percek alatt elkészül. A fejlesztői produktivitás növekedése valós és mérhető. Csakhogy a sebesség önmagában megtévesztő mutató. A kód gyorsabb megírása ugyanis nem jelenti azt, hogy a kód jobb

Mit jelent egy sikeres release a CIO szemével?

Kérdezz meg egy fejlesztőt, mikor volt sikeres egy kiadás, és nagy eséllyel ezt hallod: „lefutott a pipeline, a kód bement a main ágba, nem dobott hibát a telepítés.” Technikailag tökéletes válasz. És egy CIO számára mégis szinte irreleváns. Mert egy vezető nézőpontjából a release nem akkor sikeres, amikor a kód kiment. Hanem akkor, ha másnap

Scroll to Top