Ugrás a tartalomhoz

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.

Both András, Idomsoft

– 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.