Az EU digitális működési ellenálló képességről szóló törvénye (DORA) alapjaiban változtatta meg a pénzügyi intézmények – és az azokat támogató technológiai partnerek – rendszerteljesítményről alkotott képét. A rendelkezésre állást már nem kizárólag az ügyfél-elégedettség vagy a működési kiválóság méri. Szabályozási elvárássá vált. Az informatikai szervezetek, szoftverszállítók és tesztelési partnerek számára ez a teljesítménytesztelést a minőségbiztosítási tevékenységből a szabályozási megfelelés kulcsfontosságú elemévé emeli.

Ismerje meg a 2026-os év legfontosabb minőségbiztosítási trendjeit, beleértve a mesterséges intelligencia által vezérelt tesztelést, a folyamatos minőségbiztosítást, a teljesítménybiztosítást, a DORA-megfelelőséget és az autonóm tesztautomatizálást. Hogyan biztosíthatják a szervezetek a szoftverminőség jövőjét?

A flaky teszt egy olyan automatizált teszt, amely néha sikeresen fut le, néha pedig meghiúsul a kód lényeges módosítása nélkül. Első pillantásra technikai kellemetlenségnek tűnhet: sikertelen build, újrafuttatás, késedelem a CI/CD-ben –  azonban a bizonytalan tesztek üzleti kockázatot jelentenek. Lassítják a kiadásokat, pazarolják a mérnöki időt, csökkentik az automatizált tesztelésbe vetett bizalmat, elrejtik a valódi hibákat, és gyengítik az üzletileg kritikus szoftverekbe vetett bizalmat. A banki, telekommunikációs, repülőipari és más szabályozott vagy nagy megbízhatóságú környezetben működő szervezetek számára a tesztek bizonytalansága nem csupán minőségbiztosítási probléma, hanem működési kockázat is, amelyet tudatosan kell kezelni.

A tesztautomatizálás már nem csupán a technológiai vezetők számára fenntartott versenyelőny. Az üzletileg kritikus szoftverek esetében alapvető követelménnyé válik a működési rugalmasság és a megfelelőségi felkészültség szempontjából. Mégis sok szervezet még mindig rossz kérdést tesz fel ezzel kapcsolatban: „Vannak automatizált tesztjeink?”. Jobb kérdés helyette: „Mennyire érett, megismételhető, mérhető és auditálható a tesztelési folyamatunk?”. A Tesztautomatizálási Érettségi Modell integráció, vagyis a TMMi gyakorlati módot kínál annak megértésére, hogy vállalata hol áll az ad hoc teszteléstől az optimalizált minőségbiztosításig vezető úton.

Egy éles szoftverhiba ritkán „csak egy hiba”. Az üzletileg kritikus rendszerekben, különösen a szabályozott iparágakban, a termelési környezetet elérő hiba működési zavarokat, megfelelési kockázatot, vészhelyzeti elhárítást és hosszú távú hírnévkárosodást okozhat. Az igazi kérdés nem az, hogy a tesztelés pénzbe kerül-e. Az igazi kérdés az, hogy mennyibe kerül az elégtelen tesztelés, amikor a hiba láthatóvá válik?

A DORA 2025. január 17. óta kötelezi az EU pénzügyi szektorát, hogy a kritikus ICT-rendszereket legalább évente, független módon teszteljék, a TLPT-re kötelezett intézményeket pedig háromévente fenyegetés-vezérelt behatolásteszttel. A követelmény nem az, hogy „teszteljünk”, hanem hogy a tesztelést dokumentáltan, megismételhetően és egy audit során bizonyíthatóan végezzük. A pénzügyi intézmények tesztautomatizálása akkor lesz megfelelő, ha minden lefutás nyomon követhető, és nem függ a szállítótól.

2020-ban zajlott le a közelmúlt legnagyobb pénzforgalmi fejlesztése, az Azonnali Fizetési Rendszer bevezetése, amely forradalmasította a magyarországi bankközi elszámolást.

Számos tesztelési módszer létezik, amelyek segítségével ellenőrizhetjük és optimalizálhatjuk alkalmazásaink teljesítményét. A leggyakrabban használt tesztelési módszerek közé tartozik a load tesztelés, a stressz tesztelés és a performancia tesztelés.

Hogyan kockáztatja az SPOF az IT rendszerek működésének biztonságát? Mivel veszélyezteti az SPOF a szoftverek magas rendelkezésre állását? Miért lenne szükséges azonosítani?

A teljesítmény jellegű tesztek és mérések sokfélék lehetnek, melyek a szoftver vagy összetett informatika rendszer különféle tulajdonságait, viselkedését vagy a teljesítménymutatók értékét vizsgálhatják.

Tudjon meg többet a teljesítménytesztelésről, amely a potenciális szűk keresztmetszetek és a fejlesztendő területek azonosításához segíti hozzá vállalkozását, és ami lehetővé teszi az informatikai rendszerek teljesítményének javítását és a kockázatok csökkentését.

Másfél évtized nagy idő egy cég életében. A ProofIT-nál is voltak éles irányváltások, szoftverfejlesztő cégből szoftvertesztelő céggé alakult a vállalat.

Bulgária vezető pénzintézete informatikai rendszer átalakítást hajtott végre a pandémia idején. Esettanulmányunk második részében bemutatjuk a bolgár DSK Banknak a KPMG-vel közösen végzett performanciatesztelési projektünk kritikus pontjait és eredményeit.

Egy pénzintézet informatikai rendszerének átalakítása sokban hasonlít a hídépítéshez. Minden pontos és részletes tervek szerint készül, végül pedig egy terheléses próbát kell végezni, aminek eredményeképpen bebizonyosodik, hogy a gyakorlat igazolja-e az előzetes kalkulációkat.

Két nagy csoportba sorolhatók a szoftverteszttípusok, megkülönböztetjük a funkcionális és a nem funkcionális szoftverteszteket. Ebben a cikkben a nem funkcionális tesztelés típusait mutatjuk be.

A teszttípusok két nagy csoportját különíti el a szakirodalom. Léteznek funkcionális és nem funkcionális szoftvertesztek. Jelen cikkünkben a funkcionális tesztelés típusait vesszük végig.