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.