API meghibásodás ellenálló képességének tesztelése

API Tesztelés magánügyfeleknek

Az API Tesztelés akkor segít, amikor egy alkalmazás, weboldal vagy belső rendszer nem látható hibája okoz lassulást, rossz adatátadást vagy bizonytalan működést. A lényeg egyszerű. A szakember nem csak rákattint néhány gombra, hanem megnézi, hogyan válaszol a háttérrendszer, mit küld vissza, hogyan kezeli a hibákat, és mikor omlik meg a folyamat. Magánügyfélként ez különösen akkor fontos, ha már van fejlesztőd, de nem vagy biztos abban, hogy az elkészült munka stabil.

Én azt látom, hogy sok ügyfél csak akkor kér segítséget, amikor a felhasználók már panaszkodnak. Pedig az illesztőfelületek ellenőrzése korábban is hasznos. Egy rosszul kezelt kérés, egy hiányzó jogosultsági ellenőrzés vagy egy túl lassú válasz később több javítási kört okozhat. A Qjob.hu felületén magánszemélyek is találhatnak olyan tesztelőt, aki távolról átnézi a kéréseket, jegyzeteli a hibákat, és érthető formában átadja az eredményt.

API tesztelés mikor indokolt

API tesztelés akkor indokolt, ha az alkalmazás több rendszerrel dolgozik, adatokat küld, fizetést kezel, felhasználói fiókokat használ, vagy külső szolgáltatáshoz kapcsolódik. Ilyenkor a látható felület mögött sok olyan rész fut, amelyet egy átlagos kattintásos próba nem fed le. A tesztelő azt nézi, hogy a kérés helyes adatokkal működik e, rossz adatokkal mit tesz, és a válasz egyértelmű e.

Szerintem a leggyakoribb félreértés az, hogy az ügyfél csak a képernyőn látható hibát tekinti valódi hibának. De az adatkapcsolat hibája sokszor csendben marad. A felhasználó elküld egy űrlapot, a rendszer látszólag rendben van, közben a háttérben nem jön létre a rendelés, nem mentődik a profil vagy rossz állapot kerül az adatbázisba. Ez nem látványos, de üzletileg kellemetlen.

Volt olyan eset, amikor egy ügyfél azt hitte, hogy az új időpontfoglaló modul kész. A felület szép volt, a gombok működtek. A gond az volt, hogy két párhuzamos kérésnél ugyanaz az időpont kétszer is lefoglalható lett. A felhasználói felületen ez nem derült ki elsőre. Az API válaszok és a terhelés alatti viselkedés vizsgálata mutatta meg a problémát.

API ellenőrzés árak és feladatméret

Az ár főleg attól függ, hány végpontot kell ellenőrizni, mennyire részletes a dokumentáció, kell e jogosultsági próba, és szükség van e ismételt tesztre javítás után. A túl olcsó munka ezen a területen gyakran gyengébb minőséget jelent, mert a tesztelő csak gyorsan végigfuttat néhány alap kérést. Ez nem ugyanaz, mint a hibatűrés, a peremesetek és az adatválaszok átnézése.

Tapasztalatom szerint a legjobb ár akkor alakul ki, ha az ügyfél előre elküldi a hozzáféréseket, a leírást, a várt működést és a tesztelhető adatokat. Ha ezek hiányoznak, a szakember ideje nem a vizsgálatra, hanem a találgatásra megy el. Ez drágább és pontatlanabb.

API tesztelő kiválasztása

Az API tesztelő kiválasztásánál nem elég azt nézni, hogy valaki ismeri e az adott eszközt. Fontosabb, hogy érti e a rendszer logikáját, tud e tiszta hibaleírást írni, és nem csak technikai szavakat sorol. Magánügyfélként olyan szakembert érdemes keresni, aki képes egyszerűen elmondani, mi a hiba, miért fontos, és milyen következménye lehet.

A portfólió itt nem mindig látványos. Nem képernyőképekből áll, hanem korábbi tesztelési feladatokból, mint például belépési folyamat, rendeléskezelés, foglalás, külső adatkapcsolat vagy jogosultsági ellenőrzés. Jó jel, ha a tesztelő rákérdez a célra. Más vizsgálat kell egy próbaállapotban lévő kis alkalmazáshoz, és más egy olyan szolgáltatáshoz, ahol már valódi felhasználók vannak.

Sokan ott hibáznak, hogy csak azt kérik, nézd meg, működik e. Ez túl tág kérés. A szakember ilyenkor nem tudja, hogy a gyorsaság, a biztonság, a hibakezelés vagy az adatok pontossága a fontosabb. Jobb röviden leírni, mitől számít sikeresnek a munka. Például a felhasználó csak a saját adatait láthatja, a hibás jelszó nem engedhet belépést, a törölt elem nem jelenhet meg újra.

API próba online munkafolyamata

Az online munkafolyamat általában rövid egyeztetéssel indul. Az ügyfél elküldi a dokumentációt, a próbakulcsokat, a leírt felhasználói útvonalakat és azt, hogy milyen eredményt vár. A tesztelő ez alapján összeállítja a vizsgálati pontokat. Nem kell személyes találkozó, mert a munka távolról is pontosan elvégezhető, ha az adatok rendezettek.

A következő lépés a kérések futtatása. A szakember megnézi a normál eseteket, a hibás adatokat, az üres mezőket, a jogosulatlan hozzáférést, a késleltetett választ és a váratlan megszakítást. Ezután jön a hibák leírása. Egy jó jelentés nem csak azt mondja, hogy valami rossz. Leírja a lépéseket, a várt eredményt, a kapott eredményt és a hiba súlyát.

Az átadás lehet táblázat, szöveges dokumentum vagy hibajegy lista. Én praktikusnak tartom, ha a hibák mellé rövid megjegyzés is kerül arról, melyik javítandó elsőként. Egy magánügyfél így könnyebben tud beszélni a fejlesztővel, még akkor is, ha nem technikai ember.

API hibatűrés és minőségi elvárások

Az API hibatűrés azt mutatja meg, hogy a rendszer mit tesz, amikor valami nem ideális. Rossz adat érkezik. A külső szolgáltatás késik. A felhasználó jogosultsága lejár. A válasz nem teljes. Ilyenkor a rendszer nem omolhat össze, nem adhat félrevezető választ, és nem menthet hibás adatot.

Szerintem itt válik el az alap ellenőrzés a valódi minőségi vizsgálattól. A normál működés sokszor rendben van. A baj a szélső helyzetekben jön elő. Egy hiányzó mező, egy túl hosszú szöveg vagy egy lejárt azonosító is elég lehet ahhoz, hogy a folyamat megálljon. A felhasználó csak annyit lát, hogy nem sikerült. Az ügyfél pedig nem tudja, hol keresse az okot.

Az illesztőfelület vizsgálata akkor ad értéket, ha segít csökkenteni a bizonytalanságot. Nem minden hiba egyformán súlyos. Van, ami csak kényelmetlen. Van, ami adatvesztést okozhat. Van, ami jogosultsági gondot jelent. A tesztelő feladata az is, hogy ezt különválassza.

API vizsgálat tipikus ügyfélhibák

A leggyakoribb ügyfélhiba az, hogy nincs egyértelmű elvárt működés. Ilyenkor a szakember csak részben tud ellenőrizni. Ha nincs leírva, hogy egy kérésnek milyen választ kell adnia, akkor nehéz eldönteni, hogy a kapott eredmény jó e. Ez főleg akkor gond, ha több fejlesztő dolgozott a rendszeren, vagy a dokumentáció régi.

Másik gyakori gond a hiányos hozzáférés. A tesztelő kap egy belépést, de nincs tesztadat, nincs próba felhasználó, nincs leírás a szerepkörökről. Ilyenkor a munka lassú lesz. De ez elkerülhető. Elég egy rövid lista arról, melyik felhasználó mit tehet, milyen folyamatot kell lefedni, és mi számít hibának.

Vannak ügyfelek, akik minden hibát azonnal kritikusnak gondolnak. Ez érthető, mert senki sem szeret hibákat látni. De egy kisebb szöveges eltérés nem ugyanaz, mint egy rosszul működő jogosultság. A jó online tesztelés nem pánikot kelt, hanem sorrendet ad. Így a javítás is nyugodtabb lesz.

API Tesztelés eredményének átadása

Az API Tesztelés vége nem csak egy üzenet arról, hogy kész. Hasznos eredmény akkor születik, ha az ügyfél kap egy átlátható hibajegyzéket, rövid magyarázatot és szükség esetén újratesztelési javaslatot. A jelentésben szerepelhetnek a végpontok, a használt adatok, a válaszok, a hiba súlya és az ismétlés lépései.

Én azt tartom jó átadásnak, amikor a magánügyfél a dokumentumot tovább tudja küldeni a fejlesztőnek, és abból nem kell külön megfejteni a problémát. Rövid mondatok, pontos lépések, tiszta elvárás. Ennyi elég sok esetben. Ha a feladat nagyobb, akkor a tesztelő külön jelölheti, mit érdemes azonnal javítani, mit lehet későbbre tenni, és mit kell újra ellenőrizni a következő verzió után.

Az online szolgáltatás akkor működik jól, ha a kommunikáció végig tiszta. Az ügyfél tudja, mit kell elküldenie. A szakember tudja, mit kell vizsgálnia. A kész eredmény pedig nem elveszik egy hosszú üzenetfolyamban, hanem rendezett formában marad meg. Ez ad valódi biztonságot egy távolról végzett API ellenőrzésnél.