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

Nincs elég tesztelő? Ez az 5 fájdalmas következmény a projektre

Bevezető „Spóroljunk a tesztelésen, majd a fejlesztők megnézik egymás kódját.” Hányszor hallottuk már ezt a mondatot projektindító megbeszéléseken? Logikusnak tűnhet: a fejlesztő ért a legjobban a kódhoz, miért fizetnénk külön embert arra, hogy „kattintgasson”? Ez a gondolkodásmód azonban olyan, mintha a könyvelőt kérnénk meg, hogy auditálja a saját mérlegét. Papíron minden rendben lesz, de a

Miért nem skálázódik QA nélkül egy IT projekt?

Bevezető A szoftverfejlesztés világában létezik egy visszatérő, fájdalmas forgatókönyv, amit szinte minden startup alapító és technológiai vezető átél legalább egyszer. Ez a történet mindig ugyanúgy kezdődik: eufóriával. A projekt elején minden olajozottan működik. A csapat kicsi, agilis, és mindenki mindent tud a rendszerről. A fejlesztők reggel megírják a kódot, délben tesztelik a saját gépükön, délután

QA staffing: hogyan lehet gyorsan és biztonságosan kapacitást bővíteni?

Bevezetés Előző cikkünkben (itt olvasható) arról írtunk, hogy mikor érdemes külsős tesztelőt bevonni, és mikor intő jel, ha csak tűzoltásra használnánk őket. Most, hogy már tudjuk a „mikor”-t, evezzünk gyakorlatiasabb vizekre, és nézzük meg a „hogyan”-t. Hogyan lehet úgy bővíteni a csapatot, hogy az ne a káoszt növelje, hanem a megoldást hozza el? (Megjegyzés: A szakmában gyakran

Scroll to Top
Passed
Adatvédelmi áttekintés

Ez a weboldal sütiket használ, hogy a lehető legjobb felhasználói élményt nyújthassuk. A cookie-k információit tárolja a böngészőjében, és olyan funkciókat lát el, mint a felismerés, amikor visszatér a weboldalunkra, és segítjük a csapatunkat abban, hogy megértsék, hogy a weboldal mely részei érdekesek és hasznosak. Adatkezelési tájékoztató