A legnagyobb mítosz: a tesztelés automatizálása

Az egyik leggyakoribb buzzword vezetői oldalról: automatizáljuk a tesztelést! Mindig, mindenhol hallani ezt, teljesen függetlenül attól, hogy a tesztelési kultúra milyen érettségi szinten van a szervezetben, és hogy technikailag mit lehetne egyáltalán automatizálni.

Kezdjük az alapokkal: mit várunk el a teszteléstől? Még az élesítés előtt vizsgáljuk meg a terméket, találjuk meg a hibákat, csökkentsük az élesítéssel járó kockázatokat. Mit lehet ezen automatizálni?

A tesztelés automatizálásának két szituációban van értelme. Az első a regressziós tesztelés: a rendszeresen, ugyanúgy megismételt tesztelési feladatok. Ezeket manuálisan végrehajtani unalmas, nagyobb a hibalehetőség, illetve a manuális tesztelés lassú, automatizálva gyorsabban, több tesztet lehet lefuttatni.

A probléma, hogy a változásokat és a fejlesztéseket az automata eszköznek egyesével be kell programozni – ez viszont csak lassan megy, tehát adott funkció leteszteléséhez az automata tesztelőnek sokkal több idő kell, mint a manuális tesztelő kollégáknak. Az agilis módszertani elképzeléseknek általában része, hogy az adott sprintben az új fejlesztésekhez tartozó automata tesztek is készüljenek el, de én még soha, sehol nem láttam, hogy ez ténylegesen megtörtént volna, az automata tesztelés általában hónapokkal lemaradva követi csak a fejlesztéseket.

Tisztában kell lenni továbbá a Pesticide paradoxon nevű alapelvvel: ha ugyanazokat a teszteket ismételjük újra és újra, végül ezek a tesztek már nem fognak új hibákat találni. Ezért a teszteseteket rendszeresen felül kell vizsgálni, karbantartani, új teszteket kell hozzáadni, hogy az automata hibákat találjon. A regressziós tesztelést hosszútávon érdemes automatizálni.

A másik szituáció, ahol az automatizálás hasznos lehet a load test, a terhelés szimulálása. Például ha manuális tesztelőből nem tudunk annyit felsorakoztatni, amennyien a végfelhasználók lesznek – a számítógép viszont szimulálni tudja ezt a helyzetet, ahogy a hosszan tartó, folyamatos terhelést és sok más nehezítést is.

Kik azok a tesztautomatizálók? Az automata eszközök programozásához programozói tudás kell. Az automata tesztelők ezért a fejlesztők/tesztelők tengelyén a fejlesztőkhöz állnak közelebb, gyakran fejlesztők specializálódnak automata tesztelésre. Mivel a fejlesztők többet keresnek a tesztelőknél, a „tesztelés automatizálása” viszonylag drága mutatvány, mármint ha a cél simán csak a manuális tesztelők kiváltása.

Hogyan mérhető, hogy megéri-e? Minden automata tesztelő előszeretettel hivatkozik a lefuttatott tesztesetek számára. Száz, ezer, tízezer API hívást indítottunk, jó alaposan leteszteltük tehát a rendszert. Valóban?

Szerintem mindenféle tesztelés értelmét és eredményességét végső soron a riportolt, majd kijavított hibák száma mutatja meg – ennyivel fejlődött ugyanis a szoftver a tesztelő tevékenysége nyomán. Ha egy automata tesztelő évek óta dolgozik a csapattal, de soha, egyetlen hibát sem riportolt (megtörtént), ott el kellene gondolkozni, hogy valóban megérte-e a tesztelés automatizálása…

Priority, Severity – mit jelent ez egyáltalán és hogyan kellene a bugokat helyesen priorizálni

Az a helyzet, hogy mindenki gondol erről valamit – de mindenki valami mást.

Minden teszt adminisztrációs rendszerben van a bugokhoz legalább két mező, általában Priority és Severity néven, amelyekkel elméletileg a hiba súlyosságát, a javítás sürgősségét, valamint az okozott kár nagyságát lehet jelölni. Minden cégnél, minden csapatban van valamilyen definíció arra, hogy ezeknek az értékei, és az értékek kombinációi mit jelentenek: azonnal kell a javítás, sürgősen javítani kell, nagyon fontos, kevésbé sürgős stb.

Ezek a definíciók azonban kissé homályosak, egy idő után összefolyik, hogy a Major és a Critical között mi a különbség. Pontosabban, tapasztalatom szerint mindenki pontosan tudja, hogy mi jelentenek – de mindenki másképp…

A hibát ott követjük el, hogy a definíciókat a saját szempontunkból írjuk meg. Ehelyett arra kellene gondolni, ami a fejlesztők oldalán történik:

  1. Dobjanak el mindent azonnal, javítsák ki a hibát és küldjenek hotfixet
  2. Vegyék előre a hiba javítását, és már a következő sprintben, következő buildben szállítsák is le
  3. Később is ráér a hiba javítása, de az élesítésig legyen készen
  4. A hibával az éles működés során is együtt tudunk élni

A fenti besorolásokat nevezzük el például úgy, hogy Blocking, Critical, Major, Minor, és a szerződésbe írjuk le a vonatkozó határidőket (pl. két munkanap / következő sprint / élesítés dátuma) és kész is vagyunk. Minden más (pl. a Severity mező használata) csak felesleges bonyolítása a csapat életének.

A tesztelés adminisztrációjához miért nem elég az Excel?

Röviden: a bugok miatt.

Hosszabban: a tesztesetek megírására és az eredmények (Passed/Failed) rögzítésére bőven elegendő az Excel. Sőt, az Excel tűnik az ideális megoldásnak: kell néhány oszlop (Chapter, Steps to reproduce, Expected result, Actual result, Notes), és lehet is írni a teszteseteket egymás alá. Az Excel erre tökéletes, volt, ahol még akkor is Excelben írtuk meg a teszteket, ha volt erre bevezetett, specializált eszköz – megírtuk Excelben, aztán betöltöttük őket a rendszerbe.

A probléma a hibáknál kezdődik, amiket riportolni akarunk. Eleve túl sok mező kell egy hibajegy leírásához: ID, title, description, environment, reported by, assigned to, priority, status, comments – és ez csak egy elméleti minimum. Nem fér el szépen se vízszintesen, se függőlegesen. És további problémák is felmerülnek majd, ha mégis Excelt akarsz használni:

  • description: nehéz szép, formázott folyószöveget írni Excelben. El kell férjen a probléma alapvető bemutatása, az indoklás, hogy ez miért probléma, elvárt és aktuális eredmény, workaround – nem egy tipikus Excel cella tartalma
  • attachments: ezt nem is tudod Excelben megoldani (vagy csak nagyon rondán)
  • értesítések: minden teszt admin toolban beállítható, hogy a kiválasztott bugok körében minden változtatásról e-mail értesítést kapj. Bárki bármit matat: tudni fogsz róla. Excelben ez nincs, így észre sem veszed, ha valaki pl. az egyetértésed nélkül megváltoztatja a bugod prioritását (megtörtént) vagy lezárja a hibádat (megtörtént)
  • kommentek: sok hasznos információt, kontextust nyújtanak a kollégák által beírt kommentek. Például: nálam is reprodukálható a hiba, másnál viszont nem, kell-e javítani egyáltalán és hogyan, lezártam ilyen és ilyen okból… Számtalan téma felmerülhet egy bug kapcsán, amit egy kommentfolyamban kényelmesen meg lehet beszélni – Excelben ez szintén lehetséges, de ronda lenne
  • history: amiből látszik, hogy hogy milyen változtatások történtek a bugban, tipikusan: ki és miért módosította a prioritását és a státuszát. Excelben ez az információ elvész (vagy csak bonyolultan elérhető a SharePoint history-n keresztül)

A professzionális teszt adminisztrációs eszközök sok más hasznos funkciót is nyújtanak még: kapcsolatot a specifikációval, Jirával, automatizáló eszközzel, kényelmesen lekérhető riportokat, szabályozható felhasználói jogokat… De ezek nélkül még elkezdhető a tesztelés akár Excelben is – a hibajegyek kulturált kezelése viszont már nem.

A legnagyobb tévedés: a kimerítő tesztelés lehetősége

A tesztelés hét alapelvéből az első: kimerítő tesztelés nem lehetséges. Ennek ellenére jaj, hányszor hallottam: ezt most nagyon alaposan teszteljétek le, és ha bármilyen hiba van benne, azt találjátok meg!

Nagyon vicces volt, hányféle szinonimát találtak a kollégák a „kimerítő” szóra:

  • kívülről-belülről teszteljétek le
  • teszteljétek szét
  • tüzetesen fésüljétek át
  • teszteljétek szénné

Elméletben persze érdekes eljátszani a gondolattal, hogy például egy adott szoftver modul kimerítő tesztelése mit jelentene:

  • minden lehetséges input adatot (minden lehetséges ekvivalens input adatot),
  • minden lehetséges futtatási opciót (összes gomb, összes menüpont, összes opció kipróbálása)
  • minden lehetséges futás közbeni beavatkozási módot (gombok nyomogatása, egér kattintás, környezet módosítása)
  • ezeket az összes lehetséges sorrendben
    • leírni
    • lefuttatni

Végtelen ideig tartana vagy végtelen erőforrást igénybe véve lehetne megvalósítani. Hétfőre kell? Nem probléma!

A valóságban pedig nyilván adott már az ún. regressziós teszt set, amit adott idő alatt le lehet futtatni. Hibákat találni pedig a kollégák tapasztalata, és az új fejlesztésekről megismert információk függvényében lehet. Szerintem a fejlesztő kollégák se örülnének, ha belátható időn belül minden hibát megtalálnánk…