Párhuzamos Használat Melletti Terhelési Tesztelés Szakszerű Kivitelezése

Párhuzamos tesztelés online alkalmazásokhoz

A Párhuzamos tesztelés akkor hasznos, amikor egy alkalmazást több eszközön, több felhasználói helyzetben vagy több folyamat mentén kell egyszerre ellenőrizni. A cél egyszerű. Gyorsabban kiderül, hol akad el a rendszer, melyik funkció viselkedik eltérően, és mi történik akkor, ha több művelet fut egymás mellett. Magánügyfélként ez főleg akkor fontos, ha egy új mobilalkalmazás, webes felület vagy online szolgáltatás már majdnem kész, de még nem biztos, hogy stabilan működik.

Én azt látom, hogy sok megrendelő csak egyetlen készüléken nézi meg az alkalmazást, majd ebből von le következtetést. Ez kevés. Egy felhasználó más sorrendben kattint, más hálózatról használja a felületet, közben bejelentkezik, adatot tölt fel, fizetést indít vagy értesítést kap. A párhuzamos ellenőrzés azért értékes, mert nem egy tiszta laborhelyzetet vizsgál, hanem több valós használati helyzetet egymás mellett.

A Qjob.hu felületén olyan magánszakembert lehet keresni, aki távolról végzi el a tesztelést, majd érthető hibajegyzéket, képernyőképeket, videókat vagy rövid összefoglalót ad át. Itt a megrendelőnek nem kell saját tesztcsapatot szerveznie. Elég pontosan leírni, mit kell vizsgálni, milyen eszközök fontosak, és milyen eredményre van szükség.

Párhuzamos tesztelés célja

A párhuzamos tesztelés lényege nem az, hogy valaki sokszor megnyomja ugyanazt a gombot. A lényeg az összehasonlítás. Ugyanaz a folyamat több környezetben fut. Közben látszik, hogy az alkalmazás mindenhol ugyanúgy reagál-e, vagy bizonyos helyzetekben hibát ad. Ez lehet bejelentkezési hiba, lassú válasz, törött elrendezés, rossz adatmentés vagy olyan működés, amely csak egy adott készüléken jelentkezik.

Szerintem ez a módszer akkor ad jó eredményt, ha előre megvan a tesztelendő folyamatok listája. Például regisztráció, belépés, adatlap kitöltése, keresés, rendelés, fizetési kísérlet, üzenetküldés, értesítés fogadása és kijelentkezés. Ezeket a lépéseket több irányból lehet ellenőrizni. Így nem csak az derül ki, hogy működik-e valami, hanem az is, hogy mennyire kiszámítható.

Volt olyan eset, amikor egy ügyfél azt hitte, hogy az alkalmazása készen áll az indulásra. Egyetlen telefonon valóban rendben működött. De amikor két tesztelő egyszerre próbált adatot menteni, a rendszer néha régi adatot írt vissza. Ez nem látványos hiba, de éles használatban nagyon kellemetlen. A párhuzamos ellenőrzés pont az ilyen rejtett problémákat hozza elő.

Párhuzamos ellenőrzés árak

Az ár attól függ, hány eszközön, hány felhasználói útvonalon és milyen részletességgel kell dolgozni. Egy rövid füstteszt olcsóbb, mint egy többnapos összehasonlító vizsgálat. A túl olcsó munka ezen a területen gyakran gyengébb minőséget jelent, mert a tesztelő ilyenkor csak átfutja a felületet, és nem dokumentálja rendesen a hibákat. Tapasztalatom szerint a jó ár nem a legalacsonyabb, hanem az, ahol pontosan látszik, mit kap a megrendelő.

Az árakat érdemes feladatra bontva nézni. Ha csak azt kéred, hogy nézze meg valaki az alkalmazást, akkor pontatlan ajánlatot kapsz. Ha viszont megadod a fő funkciókat, a kívánt eszközöket és az elvárt jelentést, a szakember jobban tud árat adni. Ez mindkét oldalnak tisztább helyzet.

Párhuzamos tesztelés menete távolról

A munka általában rövid egyeztetéssel indul. A megrendelő átadja a tesztelhető verziót, a hozzáféréseket, a felhasználói szerepköröket és a fő célokat. Ezután a tesztelő összeállítja a próbafolyamatokat. Nem kell hosszú dokumentum, de egy érthető lista sokat segít. Például mit kell kipróbálni, milyen adatokat lehet használni, hol nem szabad éles fizetést indítani, és milyen hibát kell azonnal jelezni.

A távoli munkában a kommunikáció különösen fontos. A tesztelőnek nem elég annyit írnia, hogy nem működik. Jó hibaleírásban szerepel a lépés, a környezet, az elvárt eredmény, a tényleges eredmény és valamilyen bizonyíték. Ez lehet képernyőkép vagy rövid videó. Ha a hiba csak párhuzamos használat közben jön elő, akkor a pontos időpont és a használt fiókok is fontosak.

A kész eredményt általában táblázatban, dokumentumban vagy hibajegylistában lehet átadni. Kisebb munkánál elég lehet egy rövid összefoglaló. Nagyobb vizsgálatnál jobb, ha minden hiba külön sorban van. Így a fejlesztő, a tulajdonos vagy a megrendelő könnyebben látja, mit kell javítani először.

Szakember választása párhuzamos teszthez

Magánügyfélként nem mindig könnyű eldönteni, ki ért valóban a teszteléshez. A portfólió hasznos, de önmagában kevés. Olyan szakembert érdemes keresni, aki tud konkrét példát mondani korábbi hibakeresésről, érti a felhasználói folyamatokat, és nem csak technikai kifejezésekkel válaszol. A jó tesztelő egyszerűen le tudja írni, mit fog ellenőrizni.

Fontos kérdés, hogy milyen eszközökkel dolgozik. Nem kell minden létező készülék, de legyen világos, milyen rendszeren, milyen képernyőméreten, milyen böngészőben vagy alkalmazásverzión végzi a próbát. Ha párhuzamos tesztelés a feladat, akkor az is számít, hogy tud-e egyszerre több folyamatot figyelni, észreveszi-e az eltéréseket, és képes-e azokat érthetően rögzíteni.

Sokan ott hibáznak, hogy csak az árat nézik. Ez érthető, de kockázatos. Egy olcsó, rövid átnézés után lehet, hogy maradnak olyan hibák, amelyek később sokkal többe kerülnek. Szerintem jobb kisebb, de pontosan meghatározott tesztet rendelni, mint nagy ígéretet kérni kevés pénzért.

Párhuzamos próba és terhelésközeli helyzetek

A párhuzamos próba nem ugyanaz, mint a nagy teljesítményű terheléses vizsgálat, de közel tud vinni a valós használathoz. Ha több felhasználó egyszerre lép be, keres, ment vagy üzenetet küld, a rendszer másképp viselkedhet, mint egy magányos próba során. Ez különösen fontos olyan alkalmazásoknál, ahol időben érzékeny műveletek vannak.

Egy privát megrendelőnek nem mindig van szüksége bonyolult mérőrendszerre. Néha elég az, hogy a tesztelő több szerepkörből és több eszközről próbálja ugyanazt a folyamatot. Például egyik fiók létrehoz egy kérést, a másik válaszol rá, a harmadik módosítja az adatokat. Ilyenkor gyorsan kiderül, ha az állapot nem frissül, az üzenet késik, vagy a felület rossz adatot mutat.

De nem szabad túl sokat várni ettől a módszertől. Ha több ezer egyidejű felhasználót kell modellezni, az már külön technikai teljesítményteszt. A párhuzamos ellenőrzés inkább gyakorlati, felhasználói szemléletű vizsgálat. Pont ezért jól használható indulás előtt, kisebb frissítés után vagy akkor, ha valami bizonytalanul működik.

Tipikus hibák párhuzamos tesztelésnél

A leggyakoribb hiba a homályos feladatleírás. A megrendelő azt írja, hogy teszteld le az alkalmazást, de nem mondja meg, melyik rész fontos. Ilyenkor a tesztelő talál valamit, de lehet, hogy nem azt, ami üzletileg vagy használhatóság szempontjából lényeges. Egy rövid, pontos leírás sokkal jobb eredményt ad.

Másik gyakori gond, hogy nincs tesztadat. Ha a szakember nem kap külön felhasználói fiókot, próbaadatot vagy biztonságos hozzáférést, akkor lassabban halad. És több lesz a kérdés. Ez nem baj, de növeli az időt. A párhuzamos tesztelés akkor működik jól, ha a tesztelő nem akad el az első belépésnél.

Én gyakran látom azt is, hogy a hibákat nem rangsorolják. Pedig nem minden hiba egyforma. Egy elcsúszott gomb kellemetlen, de egy rosszul mentett rendelés sokkal súlyosabb. A jó jelentésben külön látszik, mi kritikus, mi közepes súlyú, és mi csak javításra javasolt részlet.

Párhuzamos teszt eredménye és javítás utáni ellenőrzés

A munka végén nem csak hibák listájára van szükség. Kell egy rövid, érthető kép arról is, mennyire stabil az alkalmazás. Mi működik jól. Hol bizonytalan a rendszer. Melyik folyamatot kell először javítani. Ez a rész sokat segít annak, aki nem fejlesztő, de dönteni szeretne a következő lépésről.

Javítás után érdemes újratesztelést kérni. Nem teljesen ugyanazt a munkát jelenti, hanem a korábban talált hibák célzott ellenőrzését. Ilyenkor derül ki, hogy a javítás valóban megoldotta-e a gondot, és nem rontott-e el valami mást. Rövid munka, de sok felesleges vitát megelőz.

A párhuzamos tesztelés jó választás, ha az alkalmazás már használható állapotban van, de még nincs elég bizonyosság a stabil működésről. Nem helyettesít minden más ellenőrzést, viszont gyorsan megmutatja, hogyan viselkedik a rendszer több egyidejű helyzetben. Ez magánügyfélként is fontos, mert a végén nem csak egy fájl vagy jelentés kell. Hanem egy tisztább döntés arról, mehet-e tovább az alkalmazás, vagy előbb javítani kell.