Ha egy folyamatban két egymástól független ellenőrzés áll ugyanazon a ponton, az ösztönösen megnyugtató. Kettő biztosan jobb, mint egy. A saját rendszerünkön lemértük, és az eredmény ennél kellemetlenebb: 104 tiltó esetből 61-nél nem tudjuk megmondani, melyik réteg dolgozik. Az ok nem a rossz felépítés. Mindkét réteg ugyanazt a választ adja, és az ellenőrzés csak a választ nézi. A különbség a döntés és a védelem között ilyenkor válik el. A döntés helyes. A védelem viszont kiszámíthatatlan, mert bármelyik réteg elromolhat úgy, hogy a folyamat végig zöld marad.
Amíg mindkét szabály ugyanazt a választ adja, a kiesésük nem látszik a kimeneten. A saját ellenőrző készletünkben 104 tiltó esetből 61-nél áll fenn ez az állapot.
Mit jelent az, hogy két réteg elfedi egymást?
Vegyünk egy hétköznapi példát a szoftveren kívülről. Egy egészségipari cégnél a termékleírás szövegét két ember nézi át, mielőtt kimegy: a szövegíró ellenőrzi a megfogalmazást, és a megfelelésért felelős kolléga ellenőrzi az állításokat. Egy tiltott mondat mindkettőnek feltűnik, tehát nem megy ki. A folyamat működik.
Most tegyük fel, hogy a szövegíró egy hónapja már nem ismeri a friss listát, és nem szól róla senki. A tiltott mondat továbbra sem megy ki, mert a másik kolléga megfogja. A folyamat továbbra is zöld, és pontosan ugyanazt a jelet adja, mint amikor még mindkét ellenőrzés élt. Az egyetlen pillanat, amikor kiderül a különbség, az az, amikor a második kolléga is kiesik, például szabadságon van. Akkor viszont már nincs mögötte semmi.
Ez a jelenség nem a figyelmen múlik, és nem lehet nagyobb gondossággal kivédeni. Szerkezeti: amíg két kontroll ugyanazt a döntést hozza, semmilyen jel nem különbözteti meg az élő védelmet a halottól.
Mit mértünk a saját rendszerünkön
A saját ellenőrző készletünkben 159 eset fut. Ebből 104 olyan, ahol a rendszernek tiltania kell valamit. A készlet magától kiírja az összegzőjében, hogy ebből a 104-ből 43 eset megmondja, melyik szabály tiltott, 61 pedig nem.
Az a 43 nem véletlenül jobb. Azoknál az eset nem csak azt rögzíti, hogy a rendszer nemet mondott, hanem azt is, hogy miért. Ha az indok is része az elvárásnak, akkor a két réteg megkülönböztethető lesz: ha az egyik kiesik, az indok megváltozik, és az eset azonnal pirosra vált.
A maradék 61-nél az elvárás annyi, hogy „ez nem mehet ki". Ezt mindkét réteg teljesíti, külön-külön is. Ott a lefedettségünk a leggyengébb, és pont ott a legmegnyugtatóbb a kép.
A 43 visszavezethető esetnél a rendszer megnevezi, melyik szabály tiltott, tehát a réteg kiesése azonnal látható. A 61-nél az elvárás csak annyi, hogy a tartalom ne mehessen ki.
Miért éppen az ellenőrző eszközünk vezet félre?
Itt jön a rész, ami miatt ezt a cikket egyáltalán megírjuk.
Van egy eszközünk, amelyik azt hivatott kimutatni, hogy egy védelem szükséges-e. Nagyon egyszerű az elve: kiveszi vagy elrontja a védelem egy darabját, aztán újra lefuttatja az ellenőrző készletet. Ha attól valamelyik eset pirosra vált, akkor a védelem dolgozott, tehát kell. Ha semmi nem változik, akkor az eszköz azt jelenti: „nem érvényes", vagyis a készlet nem érzékeny erre a kódra.
Vezessük végig ezt azon a 61 eseten. Kivesszük az egyik réteget. A másik ugyanúgy tilt. Az eset zöld marad. Az eszköz azt írja ki, hogy nem érvényes.
A kézenfekvő olvasat pedig nem az lesz, hogy a készlet nem látja a különbséget a két réteg között. Az lesz, hogy ez a védelem fölösleges.
Egy eszköz, amit a fölösleges kód kimutatására építettünk, pontosan a legvédtelenebb ponton javasolna törlést.
Ez a hamis negatív nem elméleti kockázat. Azon a 61 eseten áll fenn, amelyikről a saját mérésünkből már tudjuk, hogy ott a leggyengébb a lefedettségünk. A javítás egyetlen sor szöveg a kimenetbe: a „nem érvényes" eredmény nem bizonyítja, hogy a vizsgált kód fölösleges, jelentheti azt is, hogy az ellenőrző készlet nem különbözteti meg a két réteget. Ez a legolcsóbb tétel a listánkon, és a legnagyobb kárnak áll az útjába. Hogy egy mérőeszköz miért éppen a saját területén vak, arról az AI önellenőrzésének vakfoltja kapcsán is írtunk.
Mit lehet ezzel kezdeni, ha a cégben nincs is szoftver?
Három lépés, és egyik sem igényel fejlesztést.
1. Kérd el az indokot, ne csak az eredményt. Ha egy ellenőrzés csak annyit rögzít, hogy „rendben" vagy „nem mehet", akkor nem lehet megkülönböztetni két egymást fedő ellenőrzést. Ha azt is rögzíti, mire hivatkozva állította meg, akkor a rétegek láthatóvá válnak. Nálunk ez a különbség a 43 és a 61 eset között.
2. Vedd ki az egyik réteget szándékosan, és nézd meg, mi történik. Próbaként, nem élesben. Ha semmi nem változik, az nem megnyugtató hír. Az azt jelenti, hogy eddig sem tudtad, melyik dolgozik.
3. Halmazt vess össze, ne darabszámot. Ez a mi legdrágább leckénk az elmúlt hetekből. Egy összesített szám ugyanannyi maradhat úgy is, hogy közben az egyik eset zöldült és egy másik pirosodott. A két ellentétes változás kioltja egymást, és a jel eltűnik. Ugyanez igaz egy heti hibalistára, egy reklamáció-statisztikára vagy egy leltár-eltérésre.
A határ, amit mi sem tudunk
Ezek a számok a saját rendszerünkön mért értékek. Nem állítjuk, hogy más cégeknél is 104-ből 61 az arány, és nem is mértük meg sehol máshol. Amit a mérés megmutat, az a jelenség léte és az alakja, nem az elterjedtsége.
Három további határt érdemes kimondani, mert az eszközünk maga is ezekkel él együtt. Ha egy hiba az ellenőrző készlet egészét dönti le, az látszólag a legsikeresebb próba lesz, mert nagyon sok eset egyszerre vált pirosra. A készletünk pozitív kontrollja öt esetet billentett át a 159-ből, egy mindent letaroló hiba ennek a harmincszorosát billentené, és ugyanolyan „érvényes" jelet adna. Ha egy változtatás egy esetet pirosít és negyvenet zöldít, az eszköz átengedi. És végül a próba abból indul ki, hogy a készlet önmagától nem változik, ez viszont a készlet tulajdonsága, nem a próbáé.
Amit ebből a legfontosabbnak tartunk
Az eddigiek egyetlen félrevezető mérőeszközről szóltak. Érdemes kimondani, hogy nem az egyetlen volt: a mérésünk ugyanazon a napon még három helyen mondott magabiztosan rosszat, és mindhárom eszközt éppen a hibák felismerésére írtuk. Az egyik az idézeteket is beleszámolta abba, amit keresett. A másik rossz dolgot mért, mint amit kérdeztünk tőle. A harmadik egy mozgó sort fényképezett le, és állapotként olvastuk. Kettőt közülük más ember vette észre, a harmadikat a szerzője maga, tíz perccel a megírása után.
A közös alak mindháromban ugyanaz: a mintát számoltuk, nem a szerepét. És a hibát egyik esetben sem a mérés fogta meg. Mindháromszor egy olvasás fogta meg. Ugyanezt a mintát több oldalról is megnéztük: arról, hogy egy zöld visszajelzés mikor nem bizonyít semmit, külön írtunk a zöld lámpáról, ami nem azt méri, amit hiszel.
Ezért nem elég az, hogy „legyünk gondosabbak". A gondosság a mérő tulajdonsága, a mérő pedig ezekben az esetekben már tévedett. Ami fog, az egyetlen kérdés, feltéve azelőtt, hogy a számot leírjuk: mi az az objektum, amit ez a mérés ténylegesen megnézett?
Mind a hármat a hibák felismerésére írtuk, ugyanazon a napon. A gondosság a mérő tulajdonsága, a mérő pedig ezekben az esetekben már tévedett.
Gyakori kérdések
Ha két ellenőrzés ugyanazt a döntést hozza, az nem éppen jó jel?
A döntés szempontjából igen, a védelem szempontjából nem. Amíg a kettő egyezik, semmilyen jel nem mutatja meg, hogy mindkettő él-e. A saját mérésünkön 104 tiltó esetből 61-nél állt fenn ez az állapot. Az egyezés önmagában tehát nem bizonyítja, hogy két működő réteg van, csak azt, hogy legalább egy van.
Mit jelent az, hogy egy ellenőrzés „megnevezi az indokot"?
Azt, hogy nem csak az eredményt rögzíti (rendben vagy elutasítva), hanem azt is, melyik szabályra hivatkozva döntött így. Ez teszi megkülönböztethetővé az egymást fedő ellenőrzéseket: ha az egyik kiesik, az indok megváltozik, és a hiba azonnal láthatóvá válik. A saját készletünkben 104 tiltó esetből 43 működik így.
Honnan tudom, hogy nálunk is fennáll ez a helyzet?
A leggyorsabb próba az, hogy egy ellenőrzési lépést szándékosan kihagysz egy próbafutásban, és megnézed, változik-e a végeredmény. Ha nem változik, akkor a folyamat eddig sem mutatta meg, melyik lépés dolgozott. Ez a próba nem igényel szoftvert, jóváhagyási körökre és ellenőrző listákra ugyanúgy elvégezhető.
Miért nem elég egy összesített szám a hibákról?
Mert két ellentétes irányú változás kioltja egymást benne. Ugyanaz a darabszám állhat elő úgy is, hogy közben az egyik terület javult, egy másik pedig romlott. Ha a hibák halmazát veted össze két időpont között, és nem csak a számukat, akkor ez a mozgás láthatóvá válik.
Ez csak szoftverre igaz?
Nem. Két jóváhagyó, két ellenőrző lista, két riasztás vagy két minőségi kapu ugyanígy viselkedik. Amíg ugyanazt a döntést hozzák, nem tudod, melyik dolgozik. A mérésünk szoftveren készült, a mechanizmus viszont bármilyen folyamatban ugyanez.
