Fény az alagút végén a regressziós tesztelésben

Mire gondolsz, amikor valaki a regressziós tesztre utal? Az attól függ, hogy Te a tapasztalataid alapján mit nevezel annak. Ha például egy új izgalmas projekten dolgozol ahol folyamatos szállítással (Continuous Delivery) működtök, amelyre jellemző a rendszeres automatikus ellenőrzésekkel támogatott kiadás, valószínűleg azt gondolod, hogy a regressziós tesztelés kényelmes időtöltés. Másrészt ha – mint én – egy olyan szoftveren dolgozol amely kb. egy évtizede folyamatosan fejlődik, a hidegrázás kerülget, ha a sok manuális regressziós tesztkészlet az eszedbe jut.

Jóllehet a fejlesztési módszerek változnak, néhány tesztelési folyamat megmarad. Rengeteg projektben dolgoztam már. Olyanban is, ahol a vízesésből az agile-ra váltottak, de még mindig voltak „regressziós sprintek”, vagy „stabilizáló körök” a release-ek előtt. Ezek természetesen nem oldják meg a problémát, csak szőnyeg alá söprik azt.

A vállalatok egy része azt gondolja, hogy a regressziós teszt fázis elhagyható. Másrészt minket tesztelőket azzal vádolnak, hogy bomlasztjuk és lassítjuk az új release kiadását. Biztos, hogy a regressziós fázis kihagyása jó ötlet? A regresszió általában a kód megváltozásához, vagy a komponensek megváltozásához kapcsolódik a fejekben.

Amennyiben a tesztelés feladata az, hogy megmondjuk az üzletnek, hol tart a fejlesztés, akkor biztos, hogy értékes munkát végzünk a regressziós tesztekkel? A tapasztalataim szerint a regressziós találatok ilyen esetekben igen ritkák, és a regressziós teszt gyakorlatilag alkalmatlan az ilyenfajta feladatvégzésre. Ilyen esetekben, az új funkciók fejlesztését figyelembe véve inkább azon kéne gondolkodni, hogy milyen tevékenységet végezzünk az értékes munka érdekében a regressziós tesztek futtatása helyett.

Egy regressziós teszteléssel foglalkozó előadás vezérgondolata az volt, hogy milyen eredményekkel járhat egy regressziós teszt. Például annak a megválaszolása, hogy az új release megtartotta-e a minőségét az előző release-hez képest, vagy – csak ugyanolyan, mint egy felfedező teszt, – megnézzük az alkalmazást, hogy van-e változás ott, ahol nem kellene. Láthatjuk, hogy a fókusz egészen máshol van, mint önmagában a tesztelésnél.

A változások nehezek is lehetnek. Mint ahogy Grace Hopper híres mondata: „Az ember allergiás a változásokra, imádja azt mondani, hogy mi mindig így szoktuk csinálni”. Relatív könnyű felismerni, hogy jobb és értékesebb regressziós tesztelés is létezik, mint egy tesztrendszer ezernyi manuális regressziós tesztesettel. Végeláthatatlan folyamat! Mégis hogy kezdjünk a megváltoztatáshoz?

Lássuk, miből élünk! Nem kell egyből minden könyvet elégetni!

Mint ahogy nagyon sok projektnél láttam, a tesztkészlet általában olyan, mint egy mini termék Biblia, míg a dokumentációkon gyakorlatilag áll a por és a wikik már rég idejét múltak. Így a tesztelők a szoftvert nézik és ez alapján állítják elő a tesztkészletet, amely valós és pontos képet ad a rendszerről. Ugye?

Sajnos nem. A legjobb tesztkészlet is csak egy pillanatkép a termékről a tesztelők akkori legjobb tudása szerint. A legelső implementációhoz képest a rendszer nagyot változhatott és a felhasználók, valamint az üzlet elképzelései is egész mások lehetnek most, mint az első verzióban voltak. Például egy projektben a konfigurációs beállítások hat sorát teszteltem, amikor kis nyomozás után kiderült, hogy a dokumentációban csak két sor szerepel és a regressziós tesztek is csak ezt a két sort fedik le. Vagyis az esetek 1/3-át teszteltük, míg a maradék 2/3-ra esély sem volt, hogy valaha egyáltalán vizsgáltuk volna.

Kritikus szemmel nézve a folyamatot a tesztkészletek a „túlélésre játszanak”. Ha egy tesztelő kolléga egyszer megírta a teszteseteket, aztán munkahelyet váltott, akkor a munka nagy része az lesz, hogy azon törjük a fejünket, mit akarhatott az aktuális tesztesettel. Ez egyrészt időt rabló, másrészt a minőség rovására is megy.

Sokszor nagy a kísértés, hogy dobjunk ki mindent és kezdjük elölről az egészet. Lehetnek olyan esetek, amikor ez működhet (például, amikor nagyon kevés tesztesetről van szó, vagy ha az áttekintés alapján azt látjuk, hogy a tesztkészlet nagyon gyenge lefedettséget eredményez), de legtöbbször ezek az utak tele vannak csapdákkal.

Először is a meglévő tesztek tartalmazhatnak hasznos metaadatokat, mint az előző futtatások eredményei, hibaszámok, vagy hibajegyek referenciái (megmutatva, hogy mely hibák ismertek a felhasználók számára, vagy mely hibák a többszörösen visszaesők). Ahol lehet, ott ragaszkodjunk a meglévő metaadatokhoz, mert befolyásolhatják a jövőbeni teszteket.

Másodszor pedig, valamit újra elölről elkezdeni, nagyon nem lesz népszerű a menedzsment számára. Ha egy release közepén arra kérsz időt, hogy alaposan átvizsgálhasd a teszteket, a vezetők nehezen fogják elfogadni a hosszú távú előnyöket a rövid távú fejfájásokkal ellentétben. „Ha eddig jó volt így, akkor jó lesz ezután is! Miért nem jók azok? Mibe fog kerülni ez nekünk?” A kevésbé drasztikus megközelítés elkerüli ezeket a kellemetlenségeket.

Fokozatosan javítsd a folyamatot a jobb eredmény elérése érdekében

Értem már el sikereket a fokozatos átszervezéssel, és a tesztesetek számának csökkentésével. Amely funkciókon a fejlesztők dolgoztak – és ahol úgy találtuk, hogy nagyon szükséges – a teszteket újraírtuk az új funkcionalitásra alapozva. Ez fenntartható ütemű, fokozatos javulást eredményezett.

Eredményes lehet a tesztek természetének a megváltoztatása is. Lehetőség van a több ezer tesztesetet kisszámú end-to-end tesztté transzformálni, amelyek a termék nagyobb darabjait vizsgálják. Megkönnyítheti továbbá a dolgot a folyamatvezérelt gondolkodás, ami jobb tesztriportokhoz vezet.

Ha újra átnézed a teszteket, valószínűleg fel fogod ismerni, melyek azok az esetek, amelyek automatizálhatók, ezzel is megmutatva, hogy a fekete-fehér látásmód helyett az elvárt legjobb eredményre koncentrálsz. Ha látszik, hogy a jövőben ezeket az eseteket futtatni kell, akkor érdemes elgondolkodni az automatizált keretrendszeren. A tesztelők pedig az értékesebb képességeiket használják inkább a jövőben!

Az automatizálás csökkenti a manuális tesztelés hibalehetőségeit. Az automatizálás túlzott használata viszont eltereli a figyelmet az alkalmazásról, ami potenciális veszélyeket hordoz magában. Ahogy Richard Bradshaw is megerősít ebben: ne essünk bele abba a tévhitbe, hogy az automatizált tesztelés rengeteg időt szabadít fel és kevesebb tesztelőre lesz szükségünk!

Legyen a minőség a csapatunk felelőssége

Az automatizálás egy igen értékes eredmény, de nem jár kevesebb költséggel, vagy karbantartással. Az ilyen ellenőrzések csak egy részét jelentik a tesztelési feladatoknak – és ha regresszióról beszélünk – jelentős erőfeszítésbe kerül a regressziós hibákat elkapni nem is szólva a megoldás költségességéről. Sokkal inkább eredményre vezet, ha a regressziós hibák okait próbáljuk megtalálni.

Az aktuális pozíciómban a Towers Watson-nál a csapatunknak nagy erőfeszítésébe került amíg „tesztelőkből” „test specialistákká” promotáltuk magunkat. Ez egy felismerés, miszerint mi a minőségbiztosítás részei vagyunk, és a tesztelési feladat nem csak a mi dolgunk. A tesztelésre fókuszálunk, de emellett a projekt első pillanatától kezdve, különböző módon segítünk a fejlesztőknek minőséget építeni a termékbe:

• Folyamatot hozunk létre, amivel megbizonyosodunk arról, hogy a kódellenőrzés minden esetben megtörténik a tesztelés előtt.
• Átnézzük a unit teszteket a fejlesztőkkel és javaslatot teszünk újabb tesztekre.
• Felhívjuk a figyelmet az alkalmazásban lévő beállítások jelentőségére, ami legtöbbször elkerüli a fejlesztők figyelmét az új funkciók kialakításánál.
• Együtt vizsgáljuk meg a felhasználók által bejelentett hibákat, hogy megértsük, hogyan használják a rendszert, mi az amire mi nem gondoltunk a tesztjeink során.

A fejlesztői kódvizsgálat célja, hogy segítse a tesztelési folyamatot. A hibakezelő rendszerünkben van egy kötelezően megadandó „Tippek a teszteléshez” szekció, olyan adatokkal feltöltve, mint a változás hatóköre, és várható hatása. Pl: “Ez a dolog a tárolt eljárásokat is érintheti, amelyek erről és erről a helyről is meghívhatóak, és ez a speciális mód csak akkor elérhető, ha az első paraméter NULL”. Ez segít a regressziós teszteknél a változások esetében. Természetesen kell, hogy a megjegyzéseknél tovább tudjunk gondolkodni – mint ahogy a fejlesztők is azt mondják el, amit tudnak – és a regressziót oda is kiterjesszük, ahol az esetleges hiányosságokat érezzük.

Mindent elértünk azzal, hogy csapatként működtünk és a közös munkát támogattuk. Nyíltan és elfogadóan álltunk egymáshoz, mint fejlesztő és tesztelő. Ha ez nem látszik most az aktuális csapatodban, akkor kezdjetek el gondolkodni ebben az irányban a siker érdekében. Ha azt látod, hogy nem tudtok kilépni a „tesztelés a tesztelő problémája” mantrából, itt az ideje, hogy lépéseket tegyetek a változásért!

Mindig van lehetőség a fejlődésre

Ezeket az útmutatásokat követve, amiket itt megemlítettem, nagyon sok szervezetnek segítettem a regressziós teszteknél az idő és energia hatékonyabb felhasználásában akár a végső, release előtti stádiumban is. A legtöbb alkalmazás release-ben a csapatom számos regressziós tesztet azonosított, de ezek azokban a hónapokban készültek, amikor a fejlesztés folyt, és nem pedig az utolsó pillanatban, a kiadás előtti pánikhangulatban. A regressziós tesztek kialakításával a fejlesztés alatt azt értük el, hogy sokkal több időnk volt azokra a dolgokra koncentrálni, ami az üzlet számára igazán fontos és értékes.

Még mindig van hová fejlődni – nem könnyű mindent megoldani egy éjszaka alatt – de ha elfogadod a regressziós tesztelést, mint a projekt fontos alkotóelemét, meg fogsz döbbenni, hogy mennyire könnyű és egyszerű lesz használni. A tesztelőknek pedig lesz ideje a minőségre koncentrálni.

Forrás: http://www.ministryoftesting.com/2014/10/light-end-regression-testing-tunnel/
Szerző: Neil Studd