A tesztautomatizálástól a high-tech államig

Lehet úgy definiálni az automatikus teszteseteket, hogy még semmilyen forráskód nincs megí­rva, viszont az ügyfél üzleti nyelvén vannak megfogalmazva. így még a fejlesztés előtt validálni lehet az ügyféllel, hogy az adott üzleti folyamatra megfelelő-e a teszteset. Ha nem, akkor még szinte minimális költségen, forráskód megí­rása nélkül lehet változtatni, és í­gy lekövetni az ügyfél igényeit. Erről is beszélgettünk Both Andrással, az Idomsoft Zrt. termékfejlesztési vezérigazgató-helyettesével. Aki beszélgetésünk idején még nem tudhatta, amit mi is csak a lapzárta pillanatában tudtunk meg: hogy elnyerte a Magyar Vállalkozók Informatikai Szövetségének 2020-as Braun Péter dí­ját.

– Sok helyen mondják, hogy figyelnek az ügyfélre, de aztán ez mégsem igazán érezhető. Ez másképpen van az Idomsoftnál?

– Ahhoz, hogy valójában reagálni tudjunk az ügyfelek kérésére, hosszú távon nem elegendő csupán annyi, hogy leülünk az ügyféllel beszélgetni – amit természetesen mi is megteszünk, ráadásul egyre gyakrabban és egyre több szinten. Az is szükséges, hogy maga az informatikai rendszer olyan állapotban legyen, hogy az ügyfél igényeit ne csupán beépí­teni tudjuk, hanem gazdaságosan tudjuk beépí­teni. Aki szoftverfejlesztéssel foglalkozik tudja, hogy a forráskód minősége nagyon is számí­t, amikor egy rendszerhez 5-10-15 év elteltével is folyamatosan jönnek új igények. Egy vezetőnek fel kell ismernie, hogy nemcsak a gyors reakció számí­t, hanem az is, hogy közben ne halmozzunk fel technikai adósságot forráskód szinten. Ebben az évben több olyan csapatnál is elkezdtünk olyan, folyamatos képzéseket, amelyek a forráskód minőségét javí­tják. Ilyenek például a Clean Code képzések vagy a coding dojo-k (ahol egyszerre egy egész csapat old meg egy feladatot és feladatvégzés közben gyakorolják be az újdonságokat).

– Ezek szerint a jó forráskód elegendő?

– Közel sem. Ahhoz, hogy gyorsan tudjunk reagálni, gyorsan kell tesztelni is a szoftvereinket. Arra törekszünk, hogy egyre jobban automatizáljuk a tesztjeinket. Kí­sérleti jelleggel sikerült pár lelkes kollégával BDD- (behaviour driven development) fejlesztési koncepciót is kidolgozni.  Ehhez nagy segí­tség volt, hogy vannak olyan product ownereink, akik jól értik az üzleti folyamatokat, és partnerek voltak abban, hogy az üzleti folyamatokat magas és átfogó szinten megfogalmazzák és tesztesetekké formázzák a tesztmérnökök segí­tségével. Mindannyian tudjuk, hogy nehéz elsőre pontosan megérteni, mit is szeretne az ügyfél, de közel sem mindegy, hogy ez fejlesztés első 10 százalékánál derül ki, vagy csak azután, hogy átadtuk a szoftvert az ügyfélnek kipróbálásra.

– Tehát a jó forráskód és a sokrétű automatikus tesztek megoldották a problémákat?

– Sokat segí­tettek, de fontos megérteni, hogy egy szoftverfejlesztés nem ilyen egyszerű. Ha egy részt javí­tgatunk, attól nem biztos, hogy a termék is jobb minőségű lesz.

– Min kellett változtatni?

– Megérteni azt, hogy milyen problémát okoz, ha hagyományos projektszervezéssel dolgozunk és í­gy az átadási fázis előtt van egy nagy teszt és elfogadási fázis, és ezen nagyon sok ember dolgozik. Röviden: sok idő és költség. Azt kellett megérteni, hogy az iteratí­v fejlesztés esetén az élesí­tési költséget kell csökkenteni. Ehhez az üzleti folyamatainkat és a szoftveres élesí­tési folyamatainkat is újra kellett gondolni. Folyamatosan alakí­tjuk ki a continuous delivery folyamatainkat.  Ezen a ponton kapcsolódik össze mind a forráskód minősége, mind az automatikus tesztelés. Egyszer csak elérjük azt a pontot, amikor nagyon könnyen lehet a forráskódban új funkciót hozzáadni, amelyen az automatikus integrációs folyamatok segí­tségével lefutnak az automatikus tesztjeink, és ha minden zöld, akkor mehet is az ügyfélhez az új verzió.

– Ez logikusan hangzik, ilyen egyszerű volna?

– Nyilván nem, sokkal bonyolultabb ennél. Igénybe veszünk külső segí­tséget is, hogy minden a helyére kerüljön a csapatoknál – és a felső- és középvezetésnek is nagyon sok a dolga, hiszen nincs ingyen ebéd. Az, hogy a csapattagok tanulni járjanak heti rendszerességgel, hogy kódolás helyett teszteket, infrastruktúrát vagy éppen már működő funkciókat í­rjanak újra, sok szervezést igényel. Biztosí­tani kell az oktatókat, a mentorokat, az időt, és át kell ütemezni határidőket és projekteket is. Ez voltaképpen beruházás a jövőbe: most többe kerül és lassabb például a funkciók mennyiségi bővülése azért, hogy később sokkal gyorsabb lehessen, mint eddig. Elkerüljük azt a helyzetet is, amikor egyes elöregedett rendszerekhez, programnyelvekhez nem lehet hozzáértő embert találni, miközben folyamatosan ki kell szolgálni a felhasználókat.

– Milyen változásokat hozott ez a vezetők életében?

– Meg kellett értenünk, hogy nemcsak a csapatoknak kell többet tudni a szakmájukról, hanem nekünk, vezetőknek is folyamatosan kell tanulnunk. Ahhoz, hogy másképpen tudjunk szoftvert fejleszteni, folyamatos szervezeti változásokra is szükség van. Ezért az utóbbi időben elsősorban szervezetfejlesztés és változásmenedzsment témájú könyveket olvastam. Emellett szoftverfejlesztési koncepciókat és alapokat tanulok.

– Mert néha szoftver is fejleszt?

– Korábban fejlesztő voltam, és még most is szoktam időnként programozni. Jó edzés az agynak, és segí­t követni az új trendeket, technikákat, eszközöket. Emellett kiemelten fontosnak tartom, hogy a műszaki vezetés tisztában legyen azzal – ha még csak koncepció szinten is – hogyan épül fel egy modernebb szoftverfejlesztési folyamat. Sokat foglalkoztam a digitális termékfejlesztés menedzselésének keretrendszereivel, valamint a lean szemlélettel, de most egy kicsit szorosabban véve az alap szoftver fejlesztéssel foglalkozom.

– Mi foglalkoztatja vezetési oldalról?

Főként az, hogyan tudom saját magamat felskálázni. Hogyan kell együttműködnöm vezetőtársaimmal, kollégáimmal, annak érdekében, hogy csapatként egyre nagyobb hatást tudjunk elérni. Már régóta az államigazgatásban dolgozom, és nagyon határozott ví­zióm van azzal kapcsolatosan, hogy high-tech államot kell épí­tenünk. Azt értem ezalatt, hogy a közigazgatásnak és a közszolgáltatásoknak nagyon magas szintű digitalizációját kell elérnünk. Enélkül ugyanis szerintem nincsen, és nem lesz versenyképes gazdaságunk. Például a magas szintű adatvédelem, adatbiztonság, az állampolgári és céges ügyintézések sebessége és költsége, a közszolgáltatásokkal összekapcsolódó piaci megoldások (például ügyfél-azonosí­tás) néhány olyan versenyképességi tényező, ezekre érdemes gondolnunk. A háttérben egy olyan szervezetre van szükség, amely képes ezeket a rendszereket folyamatosan megújí­tani, önmaga megújulni, tanulni és a munkaerőpiacról kiemelkedő képességű szakembereket bevonzani. Engem az hajt, hogy mindezt érdemes és lehet is fejleszteni, ezzel a küldetéssel megyek be az irodába minden reggel.