A szervezetek a fejlesztés közben felmerült hibákat alapvetően megfelelő folyamatokkal és eszközökkel igyekeznek kijavítani. Sokszor a háttérben azonban láthatatlan bizalmi problémák húzódnak meg, amiket csak ideig-óráig lehet folyamatokkal vagy eszközökkel orvosolni.
Amikor a fejlesztő programozik, a tesztelő pedig tesztel
➔ A banki szférában gyakran alkalmazott „négy szem” elv szerint egy adott tevékenységet két személynek, egymást ellenőrizve, kell elvégeznie. Teljesen érthető, hogy miért: a bank a nagy számok és a nagy pénzmozgások világa, könnyű hibázni, ami bizony hatalmas károkat okozhat. Gyakran láttam, hogy a banki szoftverfejlesztési projektekben (de nem csak ott) külön cég fejleszt, míg egy másik cég végzi a lefejlesztett szoftver tesztelését. Ebben a felállásban ha hiba marad a rendszerben, a tesztelő céget kérik azért számon, így nem kérdés, hogy az abban érdekelt, hogy minél több hibára hívja fel a figyelmet, és így ne maradjon fel nem ismert hiba a rendszerben.
A tapasztalat azt igazolja, hogy a fejlesztő és a tesztelő munkájának egymástól függetlenítése versenyhelyzetet teremt és bizalmatlanságot szül a szervezetben, emiatt rosszabb minőségű lesz a végeredmény, valamint a folyamat is hosszabb és ezáltal drágább is lesz.
Ebben a modellben a tesztelők felelnek a „hibamentességért”, így a fejlesztők nincsenek rákényszerítve a nagyobb felelősségvállalásra, ami jobb minőséget eredményezne. Hiába vállalnának ugyanis nagyobb felelősséget, és mondjuk írnának maguk test-driven development módon automatizált acceptance-, integrációs és unitteszteket, nem fognak így tenni, mivel folyamatos nyomás alatt tartják őket, hogy gyorsan szállítsanak. A felelősség pedig amúgy is a tesztelőké, ugyanis ők így is, úgy is végigtesztelik a rendszert annak érdekében, hogy megtalálják a hibákat és/vagy hiányosságokat. De nem csak erről van szó. Ebben a felállásban valójában nem is bíznak igazán a fejlesztőkben: a „te csak fejlessz, én meg majd szólok, ha valami nem jó” hozzáállás a projektben alárendelt szerepbe kényszeríti a fejlesztőt, egyúttal aláássa a motivációját, és egymás ellen hangolja a feleket. Ez egy negatív spirált eredményez, amiből nagyon nehéz kitörni.
Amikor a fejlesztő magára vállalja a sztori megvalósításának teljes felelősségét
➔ Ha fejlesztőként dolgozom, mindig nagyon zavar, ha úgy kell lefejlesztenem valamit, hogy nem értem annak a hátterét, a miértjeit. Ezért tartom nagyon fontosnak, hogy a fejlesztő vegye kézbe a sztori megvalósításának irányítását: Ki kell faggatnia a megrendelőt (vagy az ő képviselőjét), és minden hasznos információt ki kell sajtolnia belőle.
Ezután a fejlesztőcsapat bevonásával kell megtervezni a rendszert, mivel az nem lehet egyetlen, valamilyen üzleti oldalt képviselő személy kizárólagos felelőssége. Csakis a kód ismeretében tervezhető meg jól a rendszer.
Meglévő kód ismeretében tervezünk? Dehát először nincs is kód! Ez „a tyúk vagy a tojás volt előbb” problematikáját veti fel, de valójában erről szó sincs. Erről szól a folyamatos refaktorálás és a TDD, ami – ha megfelelően alkalmazzák – adaptív és fenntartható fejlesztést eredményez. Csak a fejlesztők aktív bevonásával hozható létre fenntartható kód, és csak ezáltal biztosítható a fenntartható termékfejlesztés.
Ha a fejlesztők nem vehetnek részt a rendszer tervezésében, de nekik kell implementálniuk a rendszert bizonyos tervek, konkrét elképzelések alapján, akkor nem lesznek kellőképpen motiváltak abban, hogy jól dolgozzanak, egyszerű végrehajtókká degradálódnak. A motiváltság azonban rendkívül fontos, mert a motiválatlanság a nem fenntartható fejlesztés következményévé és egyidejűleg okává is válik, és könnyen ismét egy negatív spirálban találjuk magunkat.
Az üzleti oldal képviselőjével (pl. üzleti elemző vagy PO) történő együttműködésbe be kell vonni a tesztelőt is, aki ideális esetben a csapat tagja (pl. a „három amigo” módszerrel), hogy ő is pontosan értsen mindent, és ő is a lehető legtöbb értéket tudja szállítani. Nagyon sokat segíthet egy jó tesztelő a sztori tervezésében, és sokat segíthet abban is, hogy a teszteseteket mint specifikációt segítsen kidolgozni, amit utána a fejlesztő meg tud valósítani tesztkód és produkciós kód formájában (BDD/TDD/ATDD). Az ilyen típusú együttműködés a közös munkán és az ennek következtében kialakuló kölcsönös megértésen keresztül növeli a bizalmat a szervezeten belül, ami által a termék minősége is jelentősen javulni fog.
A tesztelőnek és a fejlesztőnek az együttműködés során meg kell vitatnia, hogyan tudna segíteni a tesztelő a termék minőségének javításában. A tesztelő egyedül nem tudja kitalálni az optimális tesztelési stratégiát, ugyanis nem lát bele a kódba, nem tudja felmérni, hogy a fejlesztők által ott megvalósított unit-, integrációs és egyéb tesztek milyen hibák ellen biztosítanak védelmet.
Sajnos elég gyakran az a forgatókönyv játszódik le, hogy a tesztelő magára vállalja a szoftver minőségellenőrzésének (QA) teljes felelősségét, mivel nem érti, hogy milyen teszteket fejlesztett le a fejlesztő, valamint mert a régi beidegződések alapján tőle várják a QA biztosítását. Ez nemcsak óriási erőforrás-pazarlást és a szállítási sebesség nagy mértékű csökkenését eredményezi, de további bizalmatlanságot szül a felek között, és ugyanabba a negatív spirálba kényszeríti őket, mint a korábbi példában, ahol a fejlesztő és a tesztelő két külön céget képviseltek, és versenyhelyzetben dolgoztak egymás mellett.
A bizalom fenntartása ezért a fejlesztő és a tesztelő között különösen fontos, már csak azért is, mert nincs olyan erő a szervezetben, ami képes lenne ezt a két felet rábírni a megfelelő együttműködésre. A tesztelőnek mindig igaza van abban, ha azt mondja, hogy ő nem fejlesztő, nem érti, milyen értéket jelentenek a fejlesztői tesztek, ezért neki is le kell tesztelnie az egész rendszert; ekkor nagyon könnyen az a helyzet állhat elő, hogy dupla munkát fognak végezni, vagy ami még rosszabb, a fejlesztő elhagyja a tesztjeit a külső nyomás és a bizalomvesztés miatti motiválatlansága miatt, amivel a stabilitás, az adaptivitás és a sebesség csökken majd jelentősen, ami pedig drasztikusan még tovább apasztja a bizalmat.
Konklúzió
➔ Óriási kihívás, hogy a három fő szereplő – az üzleti oldal, a fejlesztő és a tesztelő – megfelelően együtt tudjon dolgozni, ami nem lehetséges a bizalom megteremtése és annak folyamatos fenntartása nélkül.
A fejlesztő ismeri teljes mértékben a kódot, és az ő birtokában van a kód megírásának képessége is, ezért elengedhetetlen, hogy a kódoláson túl ne vállaljon nagyobb felelősséget. Az, hogy hogyan nevezem el a változóimat, osztályaimat, hogyan strukturálom a kódomat, és végül ezek kapcsán hogyan tudok kommunikálni a többi fejlesztővel és a többi résztvevővel, mind-mind azt a célt szolgálja, hogy kialakulhasson a közös megértés (shared understanding). De nemcsak a kódról kell tudni beszélgetni a többi szereplővel, hanem a fejlesztés teljes folyamatáról is.
Csakis a bizalom megléte esetén lehetséges a hatékony, minőségi és kellően motivált munkavégzés, ami pedig a fenntarthatóság feltétele. A fejlesztők számára meg kell előlegezni a bizalmat, és nekik pedig küldetésként kell tekinteniük a közös megértés kialakítására.
Folyamatokkal nem pótolható a bizalom.
A bizalom kulcsa pedig, fejlesztőként, Te vagy!
