Merre tovább?

Időnként meg kell kérdeznünk magunktól egy projekt vagy munkahely lezárultával, vajon jó-e még, amit eddig csináltam. Tesztelőként rohanva a stresszes, időnyomásban dolgozó programozó csapat után, teszt koordinátorként, rosszabb esetben útvonalválasztó szerepkörben adogatni, számonkérni a feladatokat, jobb esetben valamilyen tesztelői sztenderd átlal előírt folymat be nem tartásán keseregni? A kérdés persze költői. Pont olyan szakmánk van, ahol igenis mondhatjuk, kötelező a továbblépés, kötelező megtámadni a status quo-t és ellopván akárcsak fél órákat a munkahétből és jobbá tenni a világot körölöttünk.

Véleményem szerint a közelmúlt “nyomogasd csak át, ha megvagyunk vele” jellegű tesztelői feladatkiosztása fájdalmasan lassan, de változik. Furcsa mód, nem egy helyen a teszt automatizálási eszköz beruházás az első, amely a menedzsment radarjára felkerül. Teszt szakmai szempontból ez egy histórikus hiba, képtelenek voltunk szakmánk belső folyamatait olyan szinten marketing-olni, hogy kicsit jobban köztudott legyen, a tesztet tervezni kell, amihez információ (a dokumentációt félve írom le) kell, majd a tervek alapján, jön az implementáció, majd a stabilnak gondolt, fontos területekre írunk automata teszteket. Karbantartható megközelítésben. Valahogy a teszt analízist végző, a problémákat, rendszereket felülről áttekinteni képes ember értéke elveszett menet közben.

“Nyomogasd át, ha megkapod” tesztelőként találjátok meg, a lehetőségeket, apró réseket a pajzson, amelyeket kihasználva, kicsit hamarabb kaptok információt az érkezőben lévő feladatról – és ha lehetőséget kaptok, éljetek vele, készüljetek fel a teszt futtatásra. Ja, és nem elég, hogy a build előtt kaptok release notes-ot, a lehetőséget addig kell szélesíteni, amíg majd a tervezési megbeszélésekre hívnak el.

A vízesés jellegű, de inkább nagyobb (3-5 hónapos) hosszúságú iterációs jellegű fejlesztés tesztelői szempontból sosem működött igazán. A tesztmenedzser a projekt elején úgy gondolja, hogy, nnna, itt az idő, majd én megmutatom. Felüti kedvenc szabálygyűjteményét, kinézi a teszt stratégia alatti pontokat, és nekiáll írni. Jellemzőleg egyedül, majd (ha meghívják) a projekt indító beszélgetésen ezt a széles fórum elé tárja, és nem veszi észre, hogy vagy nem érdeklődnek, vagy igazából nem értik meg, amit mondani akar, vagy olyannyira távol van a hétköznapoktól, hogy igazából már ott nyilvánvaló, hogy lehetetlen az ott leírtakat teljesíteni. Nem mondják meg neki. Elmegy, az embereinek elmondja, s az elején még rózsás a világ. Sötétebbre vált a szín, mikor a programozók az első nagyobb határidővel késnek. Sokat. És ismét. A tesztelés végül visszaáll az alapszituációba, nyomogatja, ami van. Pesszimista megközelítésben elkésve, rossz minőségben kerülnek ki a termékek az ügyfelekhez.

Hamarabbi átadás átvétel nem lesz. Kevesebb ujjal mutogatás a másikra ugyancsak nem lesz, teszt stratégiában “mindenki” által elfogadott lépések betartásáról meg ne is álmodjunk. Mit lehet tenni? A korai tesztelés elvének cseppről cseppre alkalmazása talán segíthet. Ellopni az időt arra, hogy egy-egy senior tesztelőt beültessünk tervezői megbeszélésekre, és a tapasztalatait megosztva, talán jobb lesz a tesztelői hétköznap, mikor a “nyomogatásra” kerül a sor.

A programigazgató hallott erről az agilis dologról. Egy ideje ott legyeskedik egy drága tanácsadó, aki minden második mondatában megemlíti. Vágjunk hát bele. Szinte biztos, hogy az eddigi fejlesztési csoportvezetőből lesz a Scrum master, az eddigi elemzőből a product owner. Ha a tesztelő nem vigyáz, akkor megkapja ugyanazt kicsiben. Csak úgy, sebtiben levezényelt agilis átállás eredményeképp, a programozók a product owner nyomására terv nélkül (nem kell dokumentáció, agilisek vagyunk) kisebb mértékű, de ugyanúgy betarthatatlan ígérteket adnak. Majd az iteráció első felében kitalálják (értsd: megtervezik végre, mit is akarnak csinálni), ja, addig a tesztelő ne is zavarjon; majd az iteráció második felének elején egyszerre megkapjuk a javarészét tesztelni – amivel persze, mivel nekünk is kell néha aludni, elkésünk. Nem tudunk résztvenni a következő iteráció feladatainak áttekintésében, megtervezésében, bevállalásában. Ja, és ha valóban kimegy az iteráció eredménye éles környezetbe, akkor ennek nyomaképpen (is) rossz minőségben. Sokan, sokfelé mondják, hogy az agilis szoftverfejlesztés rossz minőségű terméket produkál.

Szoktam volt visszakérdezni: próbáltad-e már jól csinálni? Hát persze: első iterációban a tesztelők nem érnek oda, tehát az első eredményeit a másodikban tesztelik, majd a talált hibákat a harmadikban javítják… Aha, ezt akkor légyszíves ne hívjuk Scrumnak.

Az agilis szoftverfejlesztés nem a gyorsaságról kellene hogy szóljon. Igazából a cél a fenntarthatóság, a fejlesztési folyamat minden elemében. Üzleti tervezés időben rögzítette a fejlesztési feladatok ütemezését – tisztában van a késői változtatás valódi költségével; fejlesztésben nincs külön programozó és tesztelő, nincs “átadás, átvétel” – együttmükődés van, a minőség felelősei nem csak a tesztelők, hanem az összes csoporttag, a scrum master (ex fejlesztési csoportvezető) a tesztelők érdekeit is megérti és képviseli. A rendszertámogatás emberei jelen vannak az iteráció tervezésekor, tapasztalataikat, igényeiket el tudják mondani, azokat meghallgatják és beépítik az iterációs tervbe.

A teszt menedzser coach szerepkörben találja magát. A megfelelő, konstruktív gondolkásmód sokkalta fontosabb, mint a nagykönyvben leírtak követése. A teszt menedzser, nevezzük inkább agilis minőség coach-nak, fókuszában csökken a tesztelő, jelentősen megnövekszik a programozó és a scrum master. A tesztelő szkriptelni, unit tesztelni tanul, adatbázissal, hálózattal ismerkedik, és legfőképpen partner, nem az átadás átvétel folyamán a túloldalon ülő valaki.

Hosszú még az út és nem is mindenhol sikeres; befagyott mini vízesések, az iteráció második felében széteső tesztelők és ismételten rossz minőségű végtermék.

Új szelek fújnak. Az agilis transzformáció óta eltelt két év, a tanácsadó nevét is elfelejtették. Az “agilis” szoftverfejlesztésben erőteljesen lépett előre az üzleti/megrendelői oldal, minden kell és azonnal, gyakoriak az utolsó pillanatos változások egy iteráció előtt, mivelhát “we welcome change late in the development”. A végtermék minősége ingadozó. DevOps az új hívószó és (rosszabb esetben) szinte azonnal halljuk azt, hogy legfontosabb az éles környezetben talált hibák azonnali kijavítása. Kimondva, kimondatlanul az üzenet arról szól, hogy amennyiben nekünk nem sikerült megtalálni a hibát, akkor legalább legyünk képesek gyorsan kijavítani, a minőségbiztosítás reaktívvá válik. Menet közben a programozók a tesztelési piramis alsó részén észrevetetik magukat, unit, komponens tesztautomaták készülnek nagyszámban, a tesztelési piramis felsőbb szintjei, a szakértői, rendszert vizsgáló tesztek elmaradnak. Nehéz őket automatizálni, manuális változat megtervezésére, futtatására nincs idő. A felhasználó tesztel.

Tesztmenedzsert már valószínűleg nem találunk a környéken.

A tesztelő pedig tanul, mit is jelent a teszt automata szkriptek gyorsítása, hogyan lehet pár perces, minden build-nél lefutó csomagot készíteni, hogyan lehet biztonságosan éles környezetben tesztelni. Közelebb kerül a rendszerüzemeltetéshez, a tesztelés adatszerző, elemző, értékelő folyamatai az éles környezet adataira épülnek – monitorozó, nyomonkövető rendszerek ismeretére lesz szükség.

A szoftverfejlesztési folyamat konstans átalakuláson megy keresztül. A tesztelés, szolgáltató iparágként a folyamat minden formájában meg kell hogy találja a módját, hogy valódi hatással legyen az együttműködő felekre a magasabb minőség elérésének érdekében. Folyamatos továbbfejlődéssel tudjuk elérni, fenntartani szakmai elismertségünket, amelyet megfelelő kontextusba helyezvén tudunk valódi hatást elérni.

Minden helyzetre alkalmazható megoldás természetesen nincs – de a tesztelési munkára jellemző professzionális örök kételkedés, kérdésfelétel érvényes a folyamatainkra is. Javítandó pontokat minden esetben találhatunk, ennek több formája ismert, legyen akár a klasszikus tesztelési projekt végén a tanultak összefoglalása, az iteratív projektben a retrospektív, illetve projektfüggetlenül a több helyen leírt folyamatos fejlesztés elvhez kapcsolható események. Merre tovább – függ a kontextustól, de nem függhet a szemléletmódtól, a status quo-t megkérdőjelező, a terméket és az azt felépítő folyamatokat örökké vizsgáló, azt jobbá tenni akaró tesztelőtől.