BKK, T-Systems vs. informatika

A BKK, valamint beszállítója, botrányos szereplésének hullámverése, amely az informatikai rendszerét ért kritika kapcsán alakult ki, csak nem akar alábbhagyni. A legfrissebb események egyike az, hogy kiderültek a T-Systems hazai névviselője által szállított rendszer tesztelési körülményei. A HVG-hez eljutott információk alapján. Amelyekből, a jelek szerint, töredékek is elégnek bizonyultak ahhoz, hogy a szakemberek felhördüljenek. Okkal.

A HVG különben egy céges mail-re hivatkozik, amelynek teljes tartalmát az írásukból nem áll módunkban megismerni. Noha a szerkesztőség láthatóan nem az adatokat féltette az olvasóktól, mert több, különben meg nem nevezett „informatikai szakembert” megkérdezett. Az idézőjel különben pont a névtelenség miatt került ide. Ha akarom informatikai szakember az is, aki frissen kapott a tárgyból diplomát, és az is, aki évek óta számítógépeket szerel össze. Ugyanakkor a szoftverek tesztelése egy szakma. Hazánkban is letehető belőle nemzetközileg értékelt szakmai vizsga. Így csak használt volna a közlemény hitelének, ha a górcső alá vont levelet, és annak technikai fejlécét is közlik. Illetve megnevezik a szerkesztőségnek segítő szakértőket. Mindezen adatok hiányában egyfajta gondolatkísérletként, mintegy feltételes módba téve, de mégis érdemes áttekinteni a töredékeket.

Ezek alapján könnyen lehet, hogy a hozzá-nemértés párosult a kommunikációs szorgalommal az érintett cégek esetében. A HVG közlése szerint „komolyabb terhelési tesztként a saját munkatársait kérte e-jegy és -bérlet vásárlására a T-Systems vezetése”. Ezt tézisként elfogadva azt állapíthatjuk meg, hogy igen komoly fogalmi zavarok uralkodtak el valahol. A felhasználói, és így elsősorban funkcionális jellegű teszteket összekeverve a terhelési tesztekkel. Ami nem kicsit, hanem nagyon más. Ráadásul az utóbbi, mármint a valódi terhelési tesztek végzésére nem egy esetben célprogramokat használnak. Érthetően. Mert egy internetes, illetve böngészős, rendszernek el kell tudni viselnie azt, ha több ezer, de inkább több tíz, ha nem százezer kérés érkezik egyszerre a kiszolgálóhoz. Márpedig nem túl életszerű elképzelés egy sportcsarnoknyi embert vezényelve elérni, hogy mindenki egyszerre kattintson.

Ha ezen a fogalmi katyvaszon túltettük magunkat, akkor jön a következő furcsaság. A HVG, a szakértőkre hivatkozva, azt mondja, hogy három hónap alatt nem lehet egy ilyen rendszert összehozni. Ami kétségtelenül igaz, ha egy ember dolgozik a projekten. De jóval árnyaltabb, ha a közreműködői létszámot elkezdjük növelni. Ez akkor is igaz, ha nulláról építenék fel a rendszert. Csak akkor több, és jobban képzett szakember kell. A specifikációk elkészítéséhez, illetve a fejlesztéshez egyaránt. Amellett létezik olyan fejlesztési módszertan, amelyik a tesztelések java részét a fejlesztésekkel párhuzamosan képes megoldani. A szűk keresztmetszet tehát valószínűleg nem a fejlesztésre szánt rövid idő, hanem az azon belül tesztelésre szánt időintervallum lehetett. Ami egyébként sajnos nem is olyan ritka. Mert a határidőben való élesítésben érdekelt cégvezetés, valamint az elbizakodott fejlesztési vezetők egyaránt hajlamosak arra, hogy a tesztelésre szánt idő rovására növeljék a fejlesztésre szánt erőforrás-keretet. Időt és pénzt próbálva megtakarítani a tesztelésen.

Az, hogy a jelen esetben ez történt-e, azt nem tudhatjuk pontosan. De a lehetősége felértékelné a válaszokat a korábban feltett, és válasz nélkül maradt kérdésekre. Amelyeket a T-Systems hazai Facebook-oldalán sem kívánt senki, ezideig, megválaszolni. Ugyanakkor, ha elfogadjuk a Kaszás Zoltán közelményében vázolt helyzetből azt, hogy „vitathatatlan, hogy a rendszer bizonyos komponenseinél már léteznek fejlettebb, korszerűbb megoldások”, akkor abból egy igen szomorú kép rajzolódik ki. Az, hogy a fejlesztő csapatnak fogalma nincs a rendelkezésre álló lehetőségekről. Ha pedig ez nem igaz, akkor a fejlesztésért felelős vezető tudtával és beleegyezésével kerültek felhasználásra az elavult komponensek. A két lehetőség bármelyike azt jelentheti, hogy igen komoly architektúrális problémák lehetnek a fejlesztést végzők háza táján.

Ezt csak erősíti az, hogy a mostani hír szerint létrehoztak néhány kis értékű terméket, a belső tesztek végrehajtásának érdekében. Majd ezek „lehívása” mintegy „benne felejtődött” a rendszerben. Jelezve, hogy a verziókezeléssel, az élesítés menedzselésével, valamint az egyes verziók dokumentáltságával egyaránt komoly bajok lehettek. Márpedig ezek egyike sem olyan, ami egy tranzakció-, illetve adat-kritikus rendszerben megspórolható. Még akkor sem, ha minden egyéb, ami a szoftverfejlesztések „háza táján” tökéletes.

Azt is tudomásul kell vennünk, hogy a gyakorlat azt erősíti: tökéletes rendszer nincs, csak olyan, amit nem teszteltek eleget. Azonban a jó szakmai megközelítést pont az mutatja, ha igyekeznek az „elég” szintjét minél jobban „belőni”. A tesztelői szakma ehhez megannyi teszt-módszert, és igen sok mérőszámot, ismer. Köztük a rendszer tesztekkel való lefedettségének mértékét is. Ami a BKK-nak szállított rendszer esetében nem lehetett túl magas a sorra kiderülő problémák alapján.

Andrew_s