Menü

Kiemelt témánk

Feliratkozás


Eseménynaptár

32_1.jpg

Ahogy a szoftverek egyre több területen irányítják életünket és munkánkat, úgy lesz egyre fontosabb azok minősége. Ezt a minőséget azonban nem lehet pusztán a fejlesztési folyamat végére beiktatott teszteléssel biztosítani – a minőségbiztosításnak már a kezdetek kezdetétől be kell épülnie a folyamatokba.

Semmi nem mutatta meg annyira drámaian a szoftverek tesztelésének, minőségbiztosításának jelentőségét, mint két Boeing repülőgép közelmúltbeli katasztrófája. A dolog azonban többről szól, mint a nem elég alapos tesztelés – hívta fel a figyelmet a szélesebb összefüggésekre az áprilisi ITB Clubon Papp László, a Gartner Magyarország vezetője.

Papp László, Gartner Magyarország
A digitalizáció egyik mellékhatásaként általánossá vált a gondolkodás, hogy szoftverekkel minden problémát meg lehet oldani. Az átépítés miatt eltolódott a repülőgép súlypontja és ettől nehezen irányítható lett? Nem baj, a robotpilótához írunk egy új szoftvert, az majd segít kiegyensúlyozni a gépet! Hiszen a szoftverek megbízhatóan működnek és mindenre alkalmasak, nem? Hát, mint kiderült, nem – egyetlen összetett szoftverhiba több száz ember halálát okozta. Az üzleti életben talán nem emberéletekben fejezhető ki a kockázat, de a vállalatok működésében is óriási károkat tudnak okozni a nem jól megírt vagy letesztelt programok.

 

Elszáguld mellettünk a technológia

A szoftveripar és különösen azok minőségbiztosítása amúgy is óriási kihívások előtt áll, folytatta Papp László. Egyrészt a digitalizáció miatt folyamatosan nő az igény a számítógépekre, programokra – olyan feladatokra is számítógépeket vetünk be, amelyeket korábban manuálisan vagy legfeljebb elektromosan, elektromechanikusan oldottunk meg. Jó példa lehet erre az autó, amelyekben már ma is több tucat autonóm számítógép működik, az önvezető képességek terjedésével azonban még nőni is fog a számuk.

Mindeközben a technológia exponenciálisan fejlődik: a szoftverek bonyolultsága eljutott arra a szintre, hogy egyetlen ember, de akár egy teljes csoport is képtelen azokat a maguk teljességében átlátni és értékelni. Erre a bonyolultságra pedig sem egyéni, sem vállalati szinten nem vagyunk még felkészülve (hányan tudják például kihasználni okostelefonjuk minden képességét?).

Csínján a mesterséges intelligenciával

A szoftveriparban, így a szoftvertesztelésben is megjelent már a mesterséges intelligencia. A Gartner elemzése szerint a következő három évben nagymértékben elterjednek az MI alapú tesztadat- és teszteset-generátorok, 2023-ra pedig a nagy szoftvercégek 40 százaléka akarja majd alkalmazásfejlesztési célokra használni az MI-t, mondta Papp László – ám sokkal kisebb lesz azok aránya, akik valóban sikeresen is használják.

Dunai László saját tapasztalatai alapján úgy látja, hogy az MI-nek ott lehet a legnagyobb haszna a tesztelésben, ahol emberi döntést igénylő lépést tudnak vele automatizálni. Léteznek már olyan teszteszközök, amelyek olyan vizuális hibákat is kiszúrnak egy program felületén, amelynek észrevételéhez eddig manuális tesztelésre, vagyis emberre volt szükség.

Ez azonban csak az érem egyik fele. A mesterséges intelligenciát használó rendszereket már nem is annyira programozzák, mint inkább tanítják. Emiatt viszont a hagyományos tesztelési módszerekkel és eszközökkel nem is lehet igazán jól tesztelni az MI-alkalmazásokat. Pedig az rendkívül fontos lenne, hiszen máskülönben honnan lehetnénk biztosak abban, hogy a mesterséges intelligencia éles és előre nem látott helyzetekben is jól fog dönteni.

 

Kalapács és szög

A helyzet pedig a közeljövőben sem fog javulni, a szoftveripar fejlődésének sebessége nem csökken a későbbiekben sem, figyelmeztetett Papp László. Sem a szoftverek bonyolultsága, sem a rendelkezésre álló idő rövidsége nem teszi lehetővé, hogy kizárólag hagyományos módszerekkel, manuálisan teszteljék a szoftvereket. Arról nem is beszélve, hogy az emberi erőforrásokkal végrehajtott tesztelés mennyire drága és mennyire nincs hozzáértő szakember.

Gáspár László, Qualysoft
Természetesen be lehet (és be is kell) szerezni tesztautomatizációs eszközöket, de ezek önmagukban nem oldják meg a problémát. Igazi áttörést az hozhat, ha a vállalat egészén másképp áll a fejlesztési projekthez, mint korábban. Magyarországon ugyanis sok vállalat még a digitális korban is szöggel és kalapáccsal dolgozik: az informatika akkor érzi fajsúlyosnak magát, ha hosszú, óriási projekteket visz végig, ezt pedig a hagyományos vízesés-modellben teszi: az üzlet átküldi a specifikációt, az IT fejleszt és utána egyeztetnek – vázolta a jelenlegi hazai helyzetet Gáspár László, a Qualysoft vezérigazgatója.

 

Fejlesztés szünet nélkül

Az új gondolkodásmód és hozzáállás egyik jó módszere lehet a DevOps, amely eredetileg a szoftverfejlesztők és -üzemeltetők közös nevezőre hozását jelentette, de amely mára sokkal szélesebb jelentéstartalommal bír. Papp László szerint a DevOps egyik fő üzenete, hogy ne beszéljünk külön fejlesztési és tesztfázisokról. Minden egyszerre zajlik, a fejlesztés, a tesztelés, a beüzemelés és az éles használat, mert a szoftverek életciklusába szervesen beépül a folyamatos tervezés és tesztelés.

Dunai László, Qualysoft
Dunai László, a Qualysoft tesztelési vezetője is a folyamatos fejlesztésben látja a DevOps egyik lényeges elemét. Mint mondta, a szoftverek minőségét úgy lehet javítani, ha új és új alternatívákat próbálunk ki a gyakorlatban, voltaképpen kísérletezünk. Ehhez viszont a jelenleginél sokkal közelebb kell hozni egymáshoz az informatikát (a fejlesztést) és az üzleti oldalt. A jól alkalmazott DevOps módszertan ezt is megoldja: már a tervezésnél, a specifikáció elkészítésénél validálni kell az ötleteket, és csak azzal szabad elindulni, amelyik életképesnek látszik.

Utána is le kell bontani a falat az IT és az üzlet között, folyamatosnak kell lennie a kommunikációnak – a megfelelő szoftverminőség elérése ugyanis a legtöbb esetben nem technológiai, hanem kommunikációs kérdés. Ha van érdemi párbeszéd a két oldal között, már azt is tisztázni lehet a projekt elején, hogy egyáltalán mely funkciókat érdemes kifejleszteni.

 

Előtérben az üzleti érték

A DevOps segíthet tisztázni egy másik fontos, de éppen az üzlet és az informatika elkülönülése miatt sokszor figyelmen kívül hagyott kérdést: mitől lesz jó egy szoftver? Ezen a téren még ma is többnyire a műszaki szemlélet dominál. A fejlesztőknek válaszidőket és hasonló technikai paramétereket fogalmaznak meg elérendő cél gyanánt, és ők ennek megfelelően is fognak dolgozni. Ha egy alkalmazás két komponense 200 milliszekundum alatt képes kommunikálni egymással, akkor elégedettek.

Pedig ez egyre kevésbé megfelelő szemlélet, emlékeztetett Dunai László. Átmehet egy szoftver minden teszten, műszaki szempontból megfelelhet az összes specifikációnak – de ha az ügyfél nem azt akarta, akkor az a szoftver igazából nem jó. A tesztelés és annak automatizálása nem lehet öncélú dolog. „A hatékonyabb teszteléssel igazából nem önmagában az informatika teljesítményét akarjuk növelni, hanem az elkészült szoftvert akarjuk üzletileg is sikeresebbé tenni” – fogalmazta meg a végső célkitűzést a tesztelési vezető.

Ez egészen más gondolkodásmódot jelent, mint ami eddig jellemző volt a vállalatokra. Az új felfogásban az informatika – legyen belső vagy külső – nem az IT-szolgáltatások leszállításáért felel, hanem az üzleti sikerek megvalósításáért. Többé nem az lesz a lényeg, hogy egy párbeszédgomb jól működik-e, vagy két rendszerkomponens között mennyi a válaszidő, hanem az, hogy az elkészült termék képvisel-e üzleti értéket, sikeres lesz-e a piacon.

 

Tesztelés élesben

Ennek eldöntésére viszont már az informatika és az üzlet együttműködése sem feltétlenül elegendő. Az kevés, hogy a fejlesztés házon belüli megrendelője (a product owner) megállapodik a fejlesztőkkel, hogy a késztermék megfelel az igényeknek. Igazi visszajelzést egy szoftver használhatóságáról, a benne megvalósított ötlet életképességéről csak akkor lehet szerezni, ha azt élesben, a gyakorlatban is kipróbálják az ügyfelekkel. Ez lenne a DevOps kapcsán korábban emlegetett kísérletezés: kiadni egy új változatot, funkciót, ha pedig nem jön be, gyorsan visszaállni a régi verzióra és másképp próbálkozni. Ha így csinálják, tényleg mindig olyan szoftver lesz a felhasználók előtt, amilyet ők szeretnének, és nemcsak műszakilag, hanem üzleti szempontból is jó lesz a program.

Az új szemlélet meghonosításához az is fontos, hogy a fejlesztés, majd a tesztelés és tesztautomatizálás során ne csak informatikai, hanem üzleti célokat is tűzzenek ki a fejlesztők elé. Nem csak belső projektek esetében működhet ez, mert akár külső fejlesztőpartnerek számára is meg lehet határozni újfajta, üzleti jellegű mutatószámokat – egy weboldal átalakításánál például a látogatók számának növekedése legyen a siker kritériuma.

Dunai László a DevOps egy további előnyére is felhívta a figyelmet. Az új verziók, release-ek gyors kiadásával a rendszerek üzembiztonságát is nagymértékben lehet növelni. Ha valami gond adódik, szempillantás alatt vissza lehet állni a korábbi verzióra, vagy ami még jobb, azonnal küldeni a frissítés. Ahogy mondta, műszakilag annak sem lenne akadálya, hogy két kattintás között egy webáruház teljes háttérrendszerét lecseréljék.

 

Kell az ember?

Ilyen körülmények között és az egyre automatizáltabb fejlesztés és tesztelés korában vajon szükség van még az emberre? Az ITB Clubon részt vett szakértők szerint mindenképpen.

Annyi bizonyos, hogy ahogy a programozásban, úgy a tesztelésben is egyre magasabbra került az absztrakciós szint. Néhány évtizeddel ezelőtt még Assemblyben, gyakorlatilag a hardver szintjén írták a kódokat a programozók. Az objektumorientált nyelvek, a Java, a szabadon letölthető és újrafelhasználható kódok korában erre már nincs szükség – kis túlzással kész elemekből össze lehet legózni szinte bármilyen szoftvert.

Szabó Mihály, Qualysoft
A tesztelésben is számtalan olyan ismétlődő feladat van, amit kiválóan lehet automatizálni, és ezeket kell is automatizálni. Ezzel együtt a manuális tesztelés iránt is mindig megmarad az igény, csak éppen átértékelődik és más szinteken jelenik meg, mondta Szabó Mihály, a Qualysoft Holding nemzetközi működésért felelős vezetője. A gép kiválóan megmondja, hogy a kód, a válaszidő megfelelő-e, de azt, hogy a szoftvert kényelmes-e használni, ésszerűen vannak-e elrendezve a funkciók, hogyan lehetne jobban megoldani valamit, már csak egy ember tudja megítélni.

Sokszor egészen apró dolgokon múlik a siker. Szabó Mihály felidézte a német vasúttársaság egyik utastájékoztatási fejlesztését, amelyet mindenki sikeresnek vélt – amíg ki nem derült, hogy az idősebb korosztály szemüveg nélkül már nem tudja elolvasni a kijelzőkön megjelenő szöveget.

Megfelelő tesztcsoport bevonásával a hasonló malőrök könnyen elkerülhetők. Ilyen tesztcsoportot alkothatnak akár a későbbi felhasználók is, ahogy erről korábban volt szó, hiszen végső soron nekik készül a rendszer. Az ő egyedi visszajelzéseik, kommentjeik olyan értéket képviselnek, amelyet egyetlen automatizált eszköz sem képes megadni. Vagyis a jövőben olyan eszközökre lesz szükség, amelyek egyaránt támogatják az automatizált és a manuális tesztelést is.

Rovatok

Karrierszkenner

Kíváncsi, hol dolgozik egykori kollégája, üzleti partnere?
Szeretné, ha az ön karrierjéről is hírt adnánk?

Böngésszen és regisztráljon!

Jelenleg 2053 személy szerepel adatbázisunkban.
Az utolsó regisztrált:Somkutas Norbert

A legkeresettebb emberek:

Cégszkenner

Melyek az ict-iparág legfontosabb cégei?
Melyek a fontosabb felhasználók más iparágakból?

Regisztrálja cégét Ön is!

Jelenleg 4910 cég szerepel adatbázisunkban.

A legkeresettebb cégek: