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

Tanácsadás álláskereső portálnak

Egy piacvezető állásportál működése során a hirdetések feldolgozása nem csupán üzleti folyamat – ez a szolgáltatás alapköve. Ha a hirdetésfeldolgozási rendszerekben vagy a háttéralkalmazásokban hiba lép fel, az közvetlenül befolyásolja a felhasználói élményt és a vállalatok toborzási hatékonyságát. Ebben az esettanulmányban bemutatjuk, hogyan elemeztük egy állásportál tesztelési folyamatait, milyen jelenlegi kihívások fedezhetők fel a működésben,

AI-alapú rendszerek tesztelése: Hogyan teszteljünk, ha nincs egyetlen helyes válasz?

A szoftvertesztelés (és maga az automatizálás is) évtizedeken át egy megnyugtató, determinisztikus alapelvre épült: ha X a bemenet, akkor a kimenetnek minden egyes alkalommal pontosan Y-nak kell lennie. Ha rákattintok a „Mentés” gombra user1-ként a weblapon, akkor egy új sor keletkezik az adatbázisban. A teszteset végeztekor valami vagy Pass vagy Fail. Nincs átmenet, nincs „talán”. Ez a determinisztikus

Milyen lesz a QA engineer szerepe az AI korszakában?

„Elveszi a mesterséges intelligencia a munkámat?” – Ez a kérdés ma a szoftvertesztelői közösség legforróbb és leggyakoribb témája. Ahogy a generatív AI modellek és az intelligens tesztelési platformok egyre kifinomultabbá válnak, sok QA szakember aggódva figyeli a híreket. A kód- és tesztgenerátor asszisztensek, az öngyógyító lokátorok és az automatikus hibadetektálási ígéretek láttán könnyen alakulhat ki

Scroll to Top