Mi a smoke testing, és hogyan segítheti a minőségellenőrzést?

Egy szoftveralkalmazás minden funkcióra kiterjedő regressziós tesztelése meglehetősen költséges és időigényes dolog, főleg kisebb cégek és teamek számára. A smoke testing (vagy ennek egy variációja, a sanity testing) sokat segíthet abban, hogy a komolyabb hibákat még a teljes tesztciklus megkezdése előtt kiszűrjük, ezzel értékes időt és erőforrást takarítva meg. Ezzel a cikkel az a célunk, hogy megismertessük a módszer előnyeit, és hasznos tippeket adjunk a hatékony smoke testing implementációjához.

Mik a smoke tesztek?

A smoke teszt olyan tesztforgatókönyv, amelyeket egy fejlesztőcsapat azzal a céllal készít, hogy egy alkalmazás alapvető funkcióinak működését ellenőrizze. Bármely ilyen teszt sikertelensége az aktuális release visszautasítását vonja maga után.

Természetesen az, hogy melyek ezek a funkciók és mi minősül smoke tesztnek, teljes mértékben az adott applikációtól függ. Példának okáért ha egy tipikus webalkalmazást nézünk, egy smoke teszt lehet például az applikáció néhány, vagy összes képernyőjének megjelenítése, alapvető regisztrációs és bejelentkezési űrlapok működése, stb.

Az ilyen smoke tesztekből érdemes egy gyűjteményt összeállítani. Ennek előnye, hogy ennek a gyűjteménynek az adott bulid elkészülte utáni ellenőrzésével meggyőzödhetünk arról, hogy a jelenlegi változtatások nem okoztak semmilyen súlyos hibát az applikációban. Akkor is jól jöhet, ha a team valamilyen oknál fogva egy sürgős patchet szeretne kiadni, és az időbeli korlátok miatt nincs lehetőség teljes regressziós tesztelésre. (Ez persze nem kifejezetten jó gyakorlat, de a szükség néha nagy úr.)

A smoke testing előnyei

Az ilyesfajta tesztelésnek számos előnye van, de a legfontosabbak az alábbiak:

A smoke testing az egész QA folyamatot hatékonyabbá teszi. Ez talán magától értetődő, hiszen ha a QA csapat belekezd egy nagyobb teszt ciklusba úgy, hogy a szoftverben teljesen alapvető dolgok nem működnek, akkor mindenki csak az idejét pazarolta.

A bugok korábban felszínre kerülnek. Az ezzel kapcsolatos kutatások szerint itt is érvényesül a jó öreg 80/20 Pareto-elv: bár a smoke testing csak az esetek 20%-át fedi le (a valóságban ez ennél többnyire jóval alacsonyabb), a bugok 80%-a mégis azonnal már ebben a stádiumban elkapható.

Regressziók és bugok gyorsabb javítása. A fentiek ellenére természetesen még mindig fogunk bugokat találni a QA folyamat későbbi szakaszaiban, azonban ezek javítása és az okuk megtalálása sokkal egyszerűbb lesz a smoke tesztek eredményének ismeretében. A smoke tesztekre úgy is gondolhatunk, mint az alkalmazásunk funkciójainak egy elnagyolt térképére.

Miből legyen smoke teszt, és miből ne?

A smoke testing lényege, hogy információt adjon a teamnek arról, hogy egyáltalán érdemes-e részletesebben tesztelni a szoftvert, vagy sem. Emiatt a legideálisabb absztrakciós szint, amelyen ezen tesztforgatókönyvek íródhatnak, az a funkcionális UI szint, tehát a scriptek alapvetően a felhasználói interakciók köré íródnak.

Azt is érdemes megvizsgálni, hány tesztnek érdemes szerepelnie a smoke teszt gyűjteményben. Ez természetesen ismét csak az alkalmazástól függ, de a gyakorlat azt mutatja, hogy a legtöbb esetben ez a szám valahol 20 és 50 között van. Ha a tesztjeink száma ezen a sávon kívül esik, akkor valószínűleg vagy túl kevés esetet fedtünk le, vagy a felvázolt scriptek meghaladják a smoke testing kereteit.

A smoke testing a szoftverhibák kiszúrásának az egyik legköltséghatékonyabb módja (egyesek szerint egyenesen a legjobb módja), így mindenképpen érdemes megfontolnunk a használatát saját projektjeinkben is.