A tesztmenedzsment eszközök akadályozzák az agilis munkát

Ha agilis csapatban dolgozol és specializált tesztmenedzsment eszközt használsz, akkor van egy fontos üzenetem számodra: 

Állj meg. Komolyan. Hagyd abba, csak hátráltat téged. 

Ha hozzá vagy szokva a tesztmenedzsment eszközökhöz, lehet nem is látod, hogy az inkább csak teher, mint segítség az agilis életben. Bizton állíthatom, hogy az agilis csapatoknál kivétel nélkül mindig hátráltató tényező egy ilyen eszköz. 

Nem könnyen teszek ilyen kijelentéseket, és nem is várom el, hogy csak úgy elhidd nekem. Szóval engedd meg, hogy elmagyarázzam.

Agilis alternatíva a tesztmenedzsmenthez

Ezek azok a dolgok, amikre szükség van egy agilis környzetben, hogy kezelni lehessen a tesztelési erőforrásokat:

• feladatlista – backlog
• forráskód kezelő rendszer – SCM
• folyamatos integrációt nyújtó rendszer – CI
• automatikus regressziós tesztek.

Ennyi. Nincs szükség más eszközre vagy követő mechanizmusra. 

Minden más tesztspecifikus eszköz használata növelni fogja az információduplikációt, és még szükségtelen erőforrásköltség is hozzáadódik, hogy szinkronban tartsuk a sok másolatot. A plusz eszközök használata valószínűsíti, hogy létre kell hozni és karban kell tartani egy csomó metaadatot, mint például a követhetőségi mátrixok (traceability matrices), hogy összekapcsoljuk a különböző eszközökben tárolt adatokat. Ezek mind magas fenntartási költséggel járnak, és nem adnak több értéket a teszteléshez, mint amit az SCM, a CI és a feladatlista már eleve biztosít.

De, de, de …

Sok ellenvéleményt kaptam azzal kapcsolatban, hogy az agilis csapatoknak nem kell tesztmenedzsment eszköz. Ezekre most jöjjön néhány válasz:

De akkor hol tároljuk a teszteket?

A teszttel kapcsolatos dolgok két helyre kerülhetnek:

• a magas szintű elfogadási kritériumok, teszttervek, felderítő tesztelés (exploratory testing) a feladatlistához tartozik a hozzá kapcsolódó tennivalóval együtt;
• a technikai dolgok, beleértve a tesztautomatizációt és a manuális regressziós tesztszkripteket  (ha van ilyen) a Source Control System-hez tartozik a hozzá kapcsolódó kódokkal.

És hogyan rögzítjük a tesztelési becsléseket?

Az agilis fejlesztésben a lényeg az elvégzett feladat. Ami kódolva van, de még nincs tesztelve, az nincs kész. Így a tesztelési erőforrást úgy becsüljük, mint az egész feladat (Story) végrehajtásának egy részét, ha muszáj valami távoli hozzávetőleges becslést készíteni. Azaz mi nem elkülönítve becsüljük a tesztelési erőfeszítést, ez azt jelenti, hogy nem kell külön hely a tesztelési becsléseknek.

Hogyan priorizálom a tesztjeimet?

Az agilis csapatok egy priorizált feladatlistából (Backlog) dolgoznak. A tesztek helyett a végrehajtandó komplex feladatokat (Stories) teszik fontossági sorrendbe. A feladatok (Stories) vagy el vannak végezve vagy nem. Ebben a környezetben nincs semmi értelme a tesztek elkülönített fontossági sorrendjének.

Hello, én a való világban élek. Soha nincs elég idő a tesztelésre.Hogyan állítok fel fontossági sorrendet a szűkre szabott idő alatt?

Ha a feladat (Story) elég fontos, hogy programozzák, akkor elég fontos hogy teszteljék is. Pont. Ha agilis környezetben dolgozol akkor rendkívül fontos, hogy ezt a csapatban mindenki megértse.

De a tesztelés soha nincs befejezve. Hogyan döntöm el mit teszteljek?

Ez igazából nem tesztmenedzsment probléma. Ez egy követelménybeli, minőségi és tesztelési probléma, amire a tesztmenedzsment eszközök ajánlanak látszólagos megoldásokat.

Tehát ne pocsékoljunk időt arra, hogy kitaláljuk, hogyan irányítsuk a tesztelési folyamatot egy tesztmenedzsment eszközzel, vagy hogyan priorizáljuk a megírt teszteseteinket. Minden perc, amit a tesztmenedzsment eszközre fordítunk, egy perc, amit nem arra fordítottunk, hogy megértsük a fejlesztés alatt álló rendszerünk valódi állapotát. 

Fektessük inkább abba az energiánkat, hogy ténylegesen, közvetlenül előrefelé mozdítsuk a projektet. Értsük meg a megrendelő elvárásait, automatizált elfogadási teszteken keresztül ellenőrizzük ezeket a követelményeket, és felderítő teszteléssel (exploratory testing) fedjük fel a kockázatokat és sebezhetőségeket.

Mi a helyzet a riportokkal?

A hagyományos tesztmenedzsment eszközök sokféle riporttal szolgálnak. Pl: becsült és valós végrehajtási idő, tervezett és végrehajtott tesztesetek, helyes és hibás tesztfuttatások aránya, stb. A legtöbb ilyen fajta információ haszontalan az agilis környezetekben. 

A CI-rendszer biztosítja azokat az információkat, amelyek értékesek számunkra: az automatizált tesztfuttatási eredményeket. És a legtöbbször ezeknek az adatoknak 100%-ig zöldnek (megfeleltnek) kell lenniük.

Mi a helyzet a korábbi teszteredményekkel?

A legtöbb agilis csapat úgy találja, hogy a pillanatnyi CI-jelentések fontosabbak, mint a korábbi eredmények. Ha a CI-build pirosra vált bármilyen okból, akkor a csapat megáll és kijavítja azt. Így az agilis csapatokra nem vonatkozik a helyes/hibás tesztesetek arányának javulása úgy, mint a hagyományos csapatokra a fejlesztési fázisban. Ez azt jelenti, hogy a korábbi eredmények, trendek általában egyáltalán nem olyan érdekesek az agilis csapatok számára. 

Azonban ha a csapat tényleg nyomon akarja követni a korábbi tesztfuttatások eredményeit (vagy rá vannak kényszerítve a belső szabályok miatt), akkor a teszteredmények elraktározhatóak az SCM-ben.

A szabályozási kényszerről jut eszembe, hogyan juthatunk egyetértésre tesztmenedzsment rendszer nélkül?

Ha a környezetedben FDA, SOX, ISO vagy csak egy belső ellenőrzési szabályzat van, akkor valószínűleg egy olyan világban élsz, ahol:

• ha nincs valami dokumentálva, akkor az meg sem történt
• megmondjuk mit csinálunk, és azt csináljuk, amit mondunk
• a tesztek megismételhetősége nagyon fontos

Ebben a környezetben a specializált tesztmenedzsment eszközök megoldásai ténylegesen mértékadóak, de nem a legjobb megoldások. Ha egy olyan rendszeren dolgozunk, amiben a követelmények, tesztesetek és futási eredmények jól körülhatároltak, konkrétak, akkor válasszuk inkább az átvételi teszt által irányított fejlesztést (Acceptance Test Driven Development). Az ATTD módszer értékes adaléka, hogy végrehajtható követelményeket biztosít. Azzal szemben, hogy a tesztesetek és a követelmények csak megmondják, hogy az alkalmazásnak hogyan kellene működnie, a végrehajtható követelményeket le is lehet futtatni, hogy megmutassuk, tényleg azt csinálják. 

Természetesen az ATTD sok erőfeszítést igényel, de egy különálló tesztmenedzsment eszköz adminisztrálása, az összes követhetőségi mátrix és a szükséges plusz dokumentációk fenntartása is.

A vezetés előírta a tesztmenedzsment eszköz használatát. Most mi legyen?

Ajánld nekik ezt a cikket, és kérd meg őket, olvassák el. Aztán kérdezd meg őket, hogy milyen plusz előnyőket kapnak a tesztmenedzsment eszköztől, amit ne kapnának meg, ha kihasználnák az SCM-et, a CI-t, a feladatlistát és az automatizált regressziós tesztet.

Szóval meggyőztelek?

Forrás:http://testobsessed.com/2009/10/specialized-test-management-systems-are-an-agile-impediment/
Szerző: Elisabeth Hendrickson