Döntsük meg az agilis tesztelés negyedeit

5 évvel ezelőtt Lisa Crispin és Janet Gregory egy új megközelítést hozott az agilis tesztelésbe, az egyesek szerint őrült és sokakat befolyásoló „Agile Testing” könyvvel. Most a folytatásán dolgoznak. Ez elgondolkodtat engemet is, hogy itt az idő újragondolni az egyik szent tehenünket, az agilis tesztelés negyedei. Bár néhány évvel korábban Brian Marick ismertette meg a negyedeket a nagyközönséggel, mégis az agilis szoftvertesztelés Crispin-től és Gregory-tól kapott igazán szárnyra. A negyedek volt a központi témája a könyvnek az egyetlen dolog, amire mindenki emlékszik. Itt az idő, hogy az egészet elfelejtsük!

Az XP elsősorban fejlesztők által más fejlesztők számára feltalált metodológia. Mindent ami a fejlesztésen kívül esik bedobozolták XP felhasználói szerepekbe, amely a fejlesztői zsargonban annyit tesz: „Nem az én problémám!”. Tehát egy idő után mindent ebbe próbáltak belegyömöszölni. Nagyjából 10 évvel ezelőtt a nagyvállalatok elkezdték az üzleti tanácsadókat termékfelelősöknek, a projekt menedzsereket scrum masterek-nek nevezni, megkísérelve ezekbe az agilis dobozokba passzírozni őket. A tesztelők, „a szegény unokatestvérek” nem voltak igazi célcsoportjai a drága okleveles képzéseknek, ezért teljesen elbizonytalanodtak a feladatkörükkel kapcsolatban a szép új világban. 

Például hallottam egy vállalatról, ahol miután bevezették a Scrum metodológiát, az egész tesztelő csapat 1 hét alatt kilépett. A fejlesztők – beleértve engem is – világszerte titokban abban reménykedtek, hogy ezeket a bosszantó fontoskodó embereket a pincéből fel lehet cserélni néhány sor JUnit megírására. Nagyon sokan voltunk így, de Crispin és Gregory megmentették a helyzetet. Amikor a közösség elkezdte újra megtanulni, hogy sokkal többet tehetünk a minőségért a unit teszteknél, az agilis tesztelési negyedek kaptak szerepet a zűrzavar csökkentésére. Szabály szerint alkalmaztam a modellt, hogy elmagyarázzam 5 percben, van még helye a tesztelőknek és a unit teszt eszközökkel történő gyors automatizálása csak egy része az egésznek.

Az agilis tesztelés kvadránsa segített rengeteg hasznos érvelésben hogy összeálljon a teljes kép a fejlesztők számára és természetesen a tesztelők számára is, hogy lássák, mire kell fókuszálni.

A kvadráns elképesztően hasznos modell volt a kétezres évek elején, bár borzasztóan nehézkesnek találtam ugyanezt a 2010-es évekre illeszteni. 

A rövidebb ciklusok és a folyamatos szállítás miatt nehéz meghúzni a határt, hogy mely tevékenységek támogatják a csapatot és melyek kritizálják a terméket. A performancia tesztek miért nem segítik a csapatot? A funkcionális tesztelés miért ne kritizálja a terméket? A felfedező jellegű tesztelés miért kellene, hogy csak az üzlet eszköze legyen? Az UAT miért van elszeparálva a funkcionális teszteléstől? Nem vagyok biztos benne hogy az eredeti gondolat az volt, hogy a dolgokat szeparáljuk el fejlesztés közbeni és fejlesztés utáni fázisokra, de a legtöbb ember csak a kvadráns horizontális tengelyén gondolkodik az idő függvényében (habár nincs semmi az eredeti koncepcióban ami ezt sugallná, csak Marick utal a „végleges termékre”). Ez rengeteg nem igazolható konzekvenciát hoz magával – például, hogy a felfedező tesztelés a fejlesztés befejezése után kell, hogy következzen. A tengely is létrehoz egy szétválasztást, amit én mindig nehezen igazolhatónak találtam, mert a termék kritizálása hatékonyan támogatja a csapatot, amennyiben jó időben van ütemezve. Például a Lean Startup módszert használva a létrehozni kívánt termék bírálata már akkor elkezdődik, amikor még egy sor kód sem született.

A Kvadráns nem minden jelentős változás támogatására volt alkalmas, ami az elmúlt 5 évben történt, beleértve a folyamatos teljesítés, big data, vagy a felderítő tesztelés népszerűségének a hullámait is. Ezek miatt a legtöbb csapat a Kvadráns több negyedének is megpróbált megfelelni. Minél többször próbálom ezeket a megfeleltetéseket felrajzolni, annál inkább hasonlít az ábrám a három éves lányom a nappali falára rajzolt alkotásához.

A vertikális tengelye a Kvadránsnak még mindig hasznos a számomra. Az üzlet és a technológia szerinti tesztelés szétválasztása egy nagyszerű hüvelykujj szabály, ahogy én látom, de a horizontális tengely többé nem releváns. Az iterációk rövidebbek, a szállítások sokkal sűrűbbek és a legtöbb dolog összeolvad ez alatt a szint alatt. A példákon keresztüli specifikáció abban segít a csapatnak, hogy teljesen egyesítse a funkcionális tesztet és az UAT-ot egy tömbben, amellyel folyamatosan ellenőrzünk az egész fejlesztési ciklus alatt. Sok olyan csapatban dolgoztam mostanában, ahol teljesítmény teszteket futtatnak a fejlesztési időszak alatt, nem azért, hogy a gyakori változások okozta rendellenességet kiszűrjék – sokkal inkább a csapatok támogatása miatt.

A teszteket ilyen szintű osztályozása melyek támogatják a csapatot és melyek értékelik a terméket manapság már nem igazán releváns, tehát itt az idő, hogy megdöntsük ezt a modellt.

A tartalom vezérelt tesztelés közössége hevesen vitatkozik azon, hogy az elvárt eredmény figyelése nem igazán tesztelés – ehelyett inkább ellenőrzésnek nevezik. Anélkül, hogy vitatkoznánk azon, hogy mi a tesztelés és mi nem az, ez a felosztás nagyon hasznos volt az ügyfelekkel való kommunikációm során. Jóllehet ez nagyon hasznos lenne a modell második tengelyének: a különbség az elvárt eredmények figyelése és az analitikus szempontok (melyek nem előre definiált igen/nem válaszok) között, ahol az eredmények ügyes analitikus munkát igényelnek. A legtöbb innováció napjainkban úgy látszik, hogy a második típusban történik. Az elvárt eredmény ellenőrzése mind üzleti, mind technológiai oldalról manapság nagyjából megoldott probléma.

Elgondolkodva az eredmény ellenőrzésén és az eredmény analizálásán (amely nem előre definiált) rengeteg fontos kérdésünkre választ kapunk:

• Fel tudjuk osztani az IT biztonságot behatolás/vizsgálás (nem előre definiált) és számos funkcionális tesztre, mint titkosítás, adatvédelem, autentikáció (fontos, hogy minden ellenőrzés eredménye előre definiált legyen), hogy megtorpedózzuk azt a tévhitet, miszerint a biztonság nem a funkcionalitás része.
• Feloszthatjuk a teljesítményt terheléses tesztre (hol fog megtörni a rendszer) és futó üzleti szcenáriókra, bizonyítani az SLA szerinti kapacitást és a folyamatos szállítást, hogy megcáfoljuk azt a mítoszt, hogy a performancia egy technikai kérdés.
• Van egy szép kis dobozunk a képességek ACC-mátrix vezérelt feltárására és egyúttal egy jelentőségteljes kérdés a technológia és üzlet orientált felderítő tesztelés különválasztására.
• Van egy szép kis dobozunk a alkotás-mérés-tanulás alapú terméktesztekre és egy jelentőségteljes kérdés, hogyan kell a hipotéziseinket definiálni ezekhez a tesztekhez valamint, hogy ez mennyire különbözik attól, hogy csak kidobáljuk az újabb kiadásokat és különböző riportokon keresztül figyeljük hogy mi történik.
• Van egy kitaposott ösvényünk a termék előélete alapján a folyamatos technológiai tesztelésre, amit nehézkes automatizálni a kiadás előtt, de mégis hasznos a csapat számára. És mégis meg tudjuk különböztetni ezeket a teszteket az üzleti célú termék tesztektől.
• Felkészülhetünk a parttalan vitákra a tesztek használhatóságát illetően, hogy azok a csapatot vagy a terméket támogatják.

A legfontosabb az, hogy a horizontális tengely használatával hogyan tudunk tudatosan az összes olyan kategóriára rámutatni, amelyek nem a tipikus tesztelési terv vagy riport részei, de mégis rendkívül értékesek. A kétezres évek tesztelési kvadránsai igen hasznosak voltak, mert olyan kulcspontokra hívták fel a figyelmet, amelyekre az akkori szakemberek nem igazán gondoltak volna, de ezek napjainkra magától értetődővé váltak. A 2010-es kvadránsok a mai nap kihívásaira hívhatnák fel a figyelmet.

Ezek az aktuális gondolataim. A modell hasonló, mint amit az alábbi képen látunk:

Te mit gondolsz erről?

Eredeti cikk: http://gojko.net/2013/10/21/lets-break-the-agile-testing-quadrants/

Szerző: Gojko Adzic