Felfedező tesztelés egy API-n?

Nemrégiben az egyik fórumon egy teszter, fejlesztő vagy DevOps-os személy (Nem voltam biztos, melyik is volt) azt kérdezte:

Csináltok bármilyen felfedező tesztelést API-n? Hogyan csináljátok?

Az alábbiakban részletes válaszomat olvashatjátok kiegészítve a mélyebb megértést szolgáló hivatkozásokkal.

Kezdésnek az alkalmazás programozói interfészek (API-k) szándék szerint arra hivatottak, hogy más szoftver eszköz használatával utasításokat küldhessünk  a termék felé annak érdekében, hogy végezzen  el valamit. Igen, magukon az API-kon is elvégzünk néhány tesztet. Az interfészek különböző szoftver alkotóelemek megfelelő nézet alapján történő leképezése. Mélyebb értelemben nem csak egyszerűen leteszteljük az API-kat, hanem a kapcsolt szoftver komponens irányítására használjuk őket, megfigyelve viselkedését, sok dolgot tanulhatunk.

Ennek fényében, az első kérdés megfogalmazásával van egy kis probléma: megfogalmazása sugallja, hogy van nem felfedező tesztelés. De minden tesztelés felfedező. Az elképzelés, miszerint a tesztelés nem felfedező, részben abból a félreértésből ered, hogy mit jelent ellenőrizni, hogy a termék működőképes és mit jelent tesztelni,abból a célból, hogy megismerjük működését és hogyan tudunk működésképtelenséget előidézni.

Mikor egy termék, – szolgáltatás, komponens, keretrendszer, könyvtár, GUI alkalmazás – API-n keresztül elérhető, azt, megfelelő eszközökkel meghajthatjuk. A termék fejlesztése során, a jövőbeni felhasználási módjait is leírjuk, majd ezeknek megfelelő bemenő adatokkal hajtjuk meg az API-n keresztül. A bemenő adatokat algoritmizáljuk, a meghajtást szükség szerint ismételve, hogy a termék belső szabályait kiismerjük, a terméket elvárt módon működtessük.

Ha az elvárt viselkedést és megfelelő kimenetet tapasztaljuk, akkor a tapasztalt működést elfogadottnak, sikeresnek tekinthetjük. Ha ennél egy kicsit óvatosabban fogalmazunk, akkor inkább azt jelentsük ki, hogy a termék képes az elvárt eredmények szállítására.

Amennyiben egy nem tervezett, nem várt változtatás került a termékbe, akkor az elfogadottnak tekintett működés zátonyra futhat, ebben az esetben valószínűleg hibát találtunk.

Kifejezetten csábító, hogy a fentiekhez hasonló, “jó működést” ellenőrző folyamatot tesztelésnek hívjuk, de tesztelés szempontjából ez a megközelítés eléggé korlátolt. A termék valódi tesztelése a határainak feszegetését jelenti, meg kell próbálni invaliddá tenni az elképzelést, miszerint a termék működik. Gyakori tévhit az, hogy a termék jól működésének ellenőrzése és a tesztelés ugyanaz a dolog.

A “Rapid Software Testing” definíciója szerint a tesztelés a termék kiértékelése, bírálata, miután felfedező, kísérletező módon megismertük azt. A tesztelésben, taktikai elemként az ellenőrzés gyakran szerepel. Az ellenőrzés algoritmizált döntési szabályok alkalmazása során fellépő termék viselkedés megfigyelése, majd a végeredmények megfelelő bemutatása. Az ellenőrzés, a tesztelés integrált része.

A tesztelés alapjaiban véve felfedező folyamat . A felfedezés során, néha néha végig mehetünk a jó működést jelentő útvonalakon, melyeket ellenőriztünk – tesztelésünk során.

Tesztelőként, az API-val való első találkozás során, tanulunk. Kapunk majd dokumentációt, valamilyen formában, a funkciókról, a megadható bemeneti adatokról, és a tervezett kimenetről. Kellene lennie leírásnak arról, hogy a termékünk hogyan működik együtt más, nagyobb rendszer különböző komponenseivel. Az adott dokumentumban előfordulhat néhány új fogalom, illetve pár példa az API felhasználási módjait illetően. És valószínűleg lesz benne hiba is – aláhúzva az állítást, miszerint a dokumentáció megértése, ebben hibák azonosítása egy felfedező folyamat.

Egy szkriptnyelv (pld. Python, Ruby) vagy egy eszköz (pld. Postman) segítségével kísérletezhetünk a termék API-ján. Bemeneti adatokat adunk, meghívunk pár API függvényt, megvizsgáljuk a végeredményt. Zavart, félreértést tapasztalhatunk a dokumentációban leírtak és a API tapasztalt működése között. A fenti lépések egy felfedező folyamat részei.

Általában az új területek megértésére mindenkinek van valamilyen megszokott módszere, amelyen önkéntelenül is követ. Ettől eltekintve, nincs követendő recept arra nézvést, hogyan kell egy API működését megtanulni. A termékkel kapcsolatos tanulás, a tanulás közben, a termékben talált hibák feljegyzése ugyancsak a felfedező folyamat részelemei.

A termék megtanulása folyamatában, a jövőbeni üzleti környezetre jellemző felhasználási szkenáriókról is képet alkotunk. Vannak termékek, amelyek egyszerű, elemi szintű funkciókat valósítanak meg; vannak olyanok, amelyek tranzakció kezeléssel, adat vagy állapot kezeléssel foglalkoznak. El is képzelhető, hogy milyen beszélgetéseket folytattak a terméketek programozói a többi termékhez beosztott kollégával. A termék jövőbeni felhasználási módjait leíró modellek felépítése része a felfedező folyamatnak.

Ahogy egyre jobban megismerjük a terméket, úgy a várható kockázatokat is jobban fogjuk látni – a rossz dolgok bizony megtörténhetnek, a jó dolgok elmaradhatnak. Termék specifikus kockázati modell felépítése a felfedező folyamat része.

A kockázatok felismerésével, kezelésükre hivatott, megfelelő stratégia és azt ezt megvalósító tesztelési ötletek is megszületnek. Felfedező folyamat részterméke a kockázat menedzsment stratégia.

A megszületett tesztelési ötleteket ki is próbáljuk, néhány hozza az elvárt végeredményt, néhány nem. Miért nem? Nyomozásunk után kiderül, hogy hiba van az APIban, vagy az eredeti teszt ötletben, esetleg annak megvalósításában. Az eredmények kiértékelése és a potenciális hibák utáni nyomozás a felfedező folyamat része.

Ahogy az ismereteink mélyülnek, speciális részterületek ellenőrzését tűzhetjük ki magunk elé. Megfelelő tervezés után kódot írunk eme területek ellenőrzésére. Mint ahogy bármely más programozási feladatnál, itt sem csak az ötletek kódba fordításáról lesz szó. Az ellenőrző szkriptek fejlesztése része a felfedező folyamatnak.

Választhatjuk azt, hogy ezeket ezen automata kódokat ismétlődő módon, a funkcionalitás változatlanságának ellenőrzésére állítjuk rá, de másrészről, különösen akkor, ha egy új API hívás készül, vagy egy jelenlegi megváltozik, célszerű munkamenetünkbe beilleszteni a fentiekbe még új variációkat, diverzifikitást, adat gyűjtést, analízist, kivizsgálást.

Szükség szerinti stratégia és taktika frissítés része a felfedező folyamatnak.

Más szavakkal, minden, amit a tesztelésben csinálunk, kivéve a mechanikus (újra) futtatásait az ellenőrző rutinjainknak, felfedező munka.

“Csináltok bármilyen felfedező tesztelést API-n?” kérdés egyenlő a “Teszteltek egy API-val ellátott terméket?” kérdéssel.

A válasz, természetesen igen. A hogyanra a cikk második felében adunk választ.