Egy korábbi bejegyzésünkben összeszedtük azokat a nyomós érveket, amelyek a szoftvertesztelés nélkülözhetetlensége mellett szólnak. Tesztelni muszáj, mert hasznos, de nem csak úgy bele a világba: fontos, hogy mit és miért. Szerencsére előttünk rengetegen átgondolták már ezt, és összerakták a tesztelési negyedek (testing quadrants) néven ismert modellt. Lássuk, mi a négy tesztelői negyed, és hogyan segítik iránytűként a tesztert.
Ez a szemlélet viszonylag új, 2003-ban dolgozta ki egy Brian Marick nevű amerikai programozó, agilistanácsadó. A szoftvertesztelési kvadránsok ismerete segít abban, hogy az agilis tesztelés kiterjedjen mindenre, amire kell. A tesztelési negyedek a következők: 1) a csapatot támogató technológiai tesztek, 2) a csapatot támogató üzleti tesztek, 3) a terméket támogató üzleti tesztek és 4) a terméket támogató technológiai tesztek. A számok, mint látni fogjuk, nem feltétlenül utalnak az egyes negyedek időbeli sorrendjére, de logikailag így következnek egymásból.
Mit jelent az, hogy csapatot, illetve terméket támogató? Ezt a különbséget kétféleképp is le lehet írni. Megközelíthetjük onnan, hogy míg az első két negyed tesztjei a programozó csapat munkájának hatékonnyá tételét szolgálják, a második két negyed a termék működésének hibáit küszöbölik ki. De jó jellemzés az is, hogy az első két negyed tesztjei inkább megelőző jellegűek, a második két negyedben pedig a feltáró tesztelés dominál.
Első negyed: a csapatot támogató technológiai tesztek (Q1)
A programozók itt a szoftver egyes elemeit tesztelik. A kód minőségére fókuszálnak, arra, hogy az egyes részek külön-külön teljesítik-e az elvárásokat. Ezzel azonnali visszajelzéseket is kap a fejlesztőcsapat a készülő termékről. A fejlesztés jó esetben tesztvezérelt, így az esetlegesen előforduló hibákra viszonylag korán fény derül, nem okoznak jelentős károkat. Ezt a szakadatlan ellenőrzéssel és javításokkal teli folyamatot nem érdemes a fejlesztés elején megspórolni, mert később sokkal nehezebb belenyúlni a kódba. Egyszóval ebben a szakaszban készülnek el az alapok, amelyekre építkezni kell.
Második negyed: a csapatot támogató üzleti tesztek (Q2)
Ez a kvadráns a követelmények tisztázására koncentrál, lehetséges szcenáriók és munkafolyamatok, illetve a felhasználói élmény tesztelése révén. A tesztesetek üzleti fókuszúak, a fejlesztés az üzleti szempontokat szem előtt tartva folyik. Itt az a cél, hogy sikerüljön meghatározni minél több funkcionális elvárást, hogy a fejlesztés a kívánt irányban haladhasson. Ehhez általában az ügyfél, a fejlesztők és a tesztelők intenzívebb kommunikációjára van szükség.
A gyakorlatban mindez úgy fest, hogy az ügyfél röviden, ideális esetben egyetlen bővített mondatban megfogalmazza az elérni kívánt funkcionalitást. A fejlesztőcsapat pedig e leírás alapján megírja a kódot, és egy teszten lefuttatva rögtön lehet ellenőrizni, hogy az készült-e el, amire szükség van, és úgy működik-e, ahogy elvárható. Ezek a kisebb alapegységek egymástól függetlenül fejleszthetők, amíg az egyik kódján dolgoznak a programozók, van idő pontosan meghatározni a többi funkciót. A tesztelők ebben a felállásban amolyan hídszerepet töltenek be a megrendelő üzleti oldal és a fejlesztők között, mindkettővel szót kell érteniük.
Harmadik negyed: a terméket támogató üzleti tesztek (Q3)
Ebben a negyedben voltaképpen visszajelzéseket adunk az előző két negyed során elvégzett munkára, így kialakulhat egy kép arról, hogy hogyan halad a projekt. Ekkor már lehetséges magának a terméknek az értékelése, bár ez nem feltétlenül jelenti azt, hogy a kód készen van. A lényeg az életszerű működés, a valós helyzetekre elképzelt használat tesztelése: meg kell próbálni kitalálni, milyen problémákba ütközhet egy user élesben. A feltáró, felfedező tesztelés során rejtett gyengeségek után kutatunk.
Mindebből következik, hogy ugyan az automatizált tesztelés továbbra sem maradhat el, itt nagyon fontosak az aktív, kreatív hozzáállással elvégzett manuális tesztek, adott esetben az ügyféllel párban. Ehhez érdemes készíteni egy tesztelési tervet, amelytől szükség esetén bátran el lehet térni, ha a tesztelő a tapasztalatok alapján ezt indokoltnak látja. Sokat segít a még intenzívebb kommunikáció a megrendelővel és a fejlesztőkkel, de nem szabad csak az ő felvetéseikre hagyatkozni, elvégre a tesztelő egyik erénye éppen az kell, hogy legyen, hogy képes kívülről nézni a termékre. Vagy másképp fogalmazva, tud a user fejével gondolkodni.
Negyedik negyed: a terméket támogató technológiai tesztek (Q4)
Ideális esetben itt már a teljesen kész termékkel kell foglalkozni, de jellemzően nem azoknak a tesztelőknek, akik addig csiszolgatták a működést, hanem erre specializálódott szakembereknek, esetleg a fejlesztőknek. A cél, hogy olyan alapkritériumokat teszteljünk, mint a teljesítmény, a biztonság, a stabilitás. Konkrétabban: stresszteszt, terhelhetőség, skálázhatóság, adatmigráció, adatbiztonság, betörésvédelem stb. Ezek tehát bár nem funkcionális tesztek, de nem elválaszthatók attól, hogy mire használatos a termék, hiszen ha például új funkciókat építünk be, akkor új performaciatesztekre is szükség lehet. Az ilyen jellegű tesztek nem hoznak olyan látványos eredményt, mint mondjuk, egy új dizájn, de könnyen belátható, hogy az elvégzésük elmulasztása óriási üzleti kockázattal jár.
