Hogy kerüljük egy a „Swiss Cheese” tesztelési szindrómát

Sok csapat szenved a világon a „Swiss Cheese” tesztelési szindrómától, és úgy hiszem itt az ideje, hogy megosszam a gyűjtött információimat. Végighaladva ezen a bejegyzésen képes leszel megelőző diagnosztizálást tenni a tesztelési aktivitásaidon, és megállapítani a megfelelő gyógyírt.

A híres svájci sajt

Azoknak akik nem sajt specialisták, a svájci sajt egy általános elnevezés a lyukas sajtokra, mint ahogyan a képen is látható egy szelet svájci ementáli.

Rétegek tesztelése

Hogy bevezesselek ebbe a szindrómába, gondolj át mindenféle tesztelési aktivitást ami előfordul egy alkalmazás fejlesztésénél. Az egész általában a unit-, integrációs-, funkcionális-, automatizált-, manuális-, folyamat tesztelés és mindenféle tesztípus részhalmaza.

Nagyon valószínűtlen, hogy egy egyszerű tesztelés lefedje az egész alkalmazást. Ez az ahol a svájci sajt szeletéhez hasonlót láttam: képzelj el lyukakat, területeket, amelyek nincsenek lefedve egy tesztelési aktivitással sem.

Fejlesztésről-fejlesztésre a tesztelési tevékenységeket különböző emberek végzik. A fejlesztők általában a unit teszteket, míg a QA tesztelők a funkcionális teszteket hajtják végre. Különféle eszközök használatával segítik a saját tesztelésüket, mint például keretrendszerek (JUnit., …), web service tesztelő eszközök (SoapUI, …), funkcionális automatizált tesztelési eszközök (HP QC, Test Complete, Selenium, …), teszt menedzsment eszközök (TestLink, HP QC, …).

Az összes felsorolt tesztelési réteget tegyük egymás tetejére, ahol minden szeletnek vannak bizonyos lyukai.

Ez a szindróma akkor jön elő, amikor csak külön-külön követjük nyomon a tesztelési aktivitásainkat. Ebben az esetben a tesztelési lyukak összeadódnak és alagutakat alkotnak, ahol a hibák és regressziók rejtve maradnak a végtermékig.

Tovább növelheted a hatékonyságot, ha térképet vezetsz a tesztelési résekről és a kódmódosításokról, mert gyakran ezeken a területeken bukkannak elő az új hibák.

Ez összefüggésben van a teszt piramis fogalmával, amelyet Mike Cohn fejlesztett ki a „Succeeded with Agile” című könyvében. Mike adott még egy magyarázatot: „A tesztelés egy befektetés, és a befektetés amelyet egy rétegen végeztünk befolyásolhatja, hogy mennyire jól teszteltünk a többi rétegen.” Azonban ehhez szükséges egy összesített perspektivikus lefedettség nézet az összes tesztelési aktivitásról, hogy lássuk az előző tesztelési tevékenység mit fedett le jól, és mit nem érintett.

Néhány orvosság

A Kalistick-nál, kifejlesztettünk egy eszközt, ami segít eldönteni a csapatoknak, hogy fennáll-e a szindróma esete és kell-e azt kezelni. Bemutatok pár kulcsfontosságú koncepciót.

Először is össze kell gyűjtened a tesztelési tevékenységek összes kódlefedettségét. Például a Kalistick Testing Booster megoldás összegyűjti az összes tesztelési tevékenység lefedettségét bármilyen platformon (CI, functional testing, …). Másodszor pedig rögzíteni kell a szoftver változásait a lefedettség változása érdekében. Ez megtehető egy nyílt forráskódú forráskezelővel (pl.: SCM). Mindazonáltal a Kalistick olyan innovatív alkalmazás elemző, amely egyszerű mint egy vírusirtó szoftver, viszont az utasítások mélységéig analizálja az alkalmazást, hogy azonosítsa benne a változásokat.

Szóval az összes így összegyűjtött adat tiszta képet alkot arról, mit teszteltünk és hol maradtak lyukak a tesztelésben. Lásd a következő ábrát mintaképp; ez megkülönbözteti a funkcionális teszteket (manuális és automata) és a build teszteket (unit és integrációs). A kék terület mutatja a lefedetlen területeket amit semmilyen teszt nem fed le. A piros terület a kód változásokra fókuszál, amely nem érintett egy teszteset által sem.

Annak megfelelően, hogy mekkorák a lyukak azt javaslom, hogy funkcionális szempontból értékeljük ki a kapcsolódó üzleti kockázatokat és azonosítsuk, hogy mely lyukakat kell betölteni elsőként.

Ahogy priorizáltuk a kitöltendő lyukakat, el kell döntenünk, hogy milyen típusú tesztekre van még szükségünk (unit, funkcionális, feltáró, manuális, automatikus, stb.). A manuális tesztekhez a Kalistick egy Test Coverage ScoresTM-et kínál ami felméri, hogy az egyes tesztek mekkora lefedettség változást eredményeznek. Találhatsz néhány példát a Kalistick platformon (használd a demo/demo-t login/jelszó-ként.

Tanulság

A svájci sajt hatalmas lyukai markáns ízt kölcsönöznek, így nem jelent gondot kivéve, hogy nehezebben szeletelhető és szétesik a gépi szeletelésnél. Ugyanakkor egy szoftvernél a nagy lyukak a tesztelés hiányosságára utalnak és hibás működést eredményeznek, ezáltal nagyobb a valószínűsége, hogy az alkalmazás az élesbe állítás során szétesik.

Kérjük, oszd meg a meglátásaidat a Swiss Cheese szindróma kapcsán és ha találsz rá akkor a gyógyírt is.

Forrás: http://www.eurostarconferences.com/blog/2012/8/31/testing-swiss-cheese-syndrome

Szerző: Marc Rambert