Valószínűleg az informatika saját fejlődési útja miatt tartunk itt, vagyis ott, hogy a fejlesztési folyamatoknak, a stratégiai tervezésnek nem integráns része sem a tesztelés, sem pedig az informatikai biztonság szempontjainak folyamatos érvényesítése. A minél gyorsabb piacra vitel, használatba vétel élvez prioritást, másodlagos vagy harmadlagos elvárás, hogy a létrejövő termék, megoldás, rendszer megfelelő minőségére módszeresen vigyázzanak.
Ha kedves olvasóim vennék a fáradságot, hogy belemerüljenek mindkét terület szakirodalmába, azt találnák, hogy a legnagyobb megbecsülésnek örvendő szaktekintélyek ilyeneket mondanak: külön tesztelési stratégia szükséges, külön tesztelési projektterv szükséges és így tovább. Az IT-biztonság terén ugyancsak az tapasztalható, hogy még a mértékadó szakértők is azt hirdetik: a vállalati architektúra mellett meg kell alkotni külön az IT-biztonsági architektúrát, a vállalati stratégia mellett el kell készíteni külön az IT-biztonsági stratégiát.
Nem egyszer volt alkalmam részt venni fejlesztési projektekben (többnyire az online médiában), és magától értetődő volt azokban a munkaközösségekben, hogy a tesztelést az éles induláshoz közel időzítettük, mintegy ez volt a mondat végére tett pont, amely lezár egy alaposan végiggondolt, nyilvánvalóan értelmes és értékes gondolatot. Eszünkbe sem jutott annak szükségessége, hogy a fejlesztés egészébe, az igények felmérésétől az éles indulásig minden mozzanatba legyen beleszőve a tesztelés szála.
És amikor egyszer megjelent valaki, és az általunk készített specifikáció szinte minden egyes szavára rákérdezett, azt gondoltuk, mit hepciáskodik itt ez az ember, csupán lassítja a folyamatot, és nem mellesleg megkeseríti az életünket. Csak magamban mertem elismerni, hogy ha ő nincs, akkor lényegében minden ellenőrzés és korrekció nélkül jutott volna el dokumentumunk a programozókhoz. Ő az a valaki volt, aki mindent meg akart érteni, ki akart javítani minden hibát még a specifikációban, mert neki jutott az a nem egyszerű feladat, hogy válaszoljon a fejlesztés megvalósítóinak kérdéseire.
Töredelmesen bevallom, hogy olyan közreműködővel eddig sohasem találkoztam projektekben, aki már a kezdetekkor az IT-biztonság szempontjából segítette volna a megoldás kigondolóit és megalkotóit. És azt is bevallom, hogy láttam ugyan már nem egy vállalati IT-stratégiát, és ha volt is bennük szó az IT-biztonságról, akkor azt külön fejezetben tárgyalták, nem pedig beágyazva az egyes fejezetekbe, mondjuk, a meglévő infrastruktúra áttekintésében, a megcélzott architektúra leírásában, a képzési tervekben vagy a sikerkritériumok meghatározásának részében.
Azt mondom, hogy a minőségbiztosítás mindennapi értelmezését kiterjeszteni szükséges. Nem a webes enciklopédiákban (azokban sem ártana), hanem a szakmánk gyakorlatában. És végül azt mondom, hogy a minőség fogalmát is újra kell értelmezni digitalizálódó világunk IT-szegmensében.
Nem tekinthető minőséginek, jónak egy olyan termék, megoldás, rendszer, amely olyan hibákat produkál, amelyeket módszeres minőségbiztosítással még a piacra kerülés, használatba vétel előtt ki lehetett volna javítani.
Nem tekinthető minőséginek, jónak egy olyan termék, megoldás, rendszer, amely a rosszfiúk könnyű prédája.
Újra kellene gondolni, és ezt a gyakorlatot időről időre meg kell ismételni, hogy a gyakorlatban milyen kritériumoknak megfelelés esetén minősíthetünk minőséginek, jónak egy szoftvert, egy eszközt, egy hálózatot vagy egy szolgáltatást.