Spoiler: mert nem fogja megtalálni a hibákat.
Legalábbis nem az összeset. És éppen azokat nem, amelyek aztán az éles bevezetés után derülnek ki - a legrosszabb pillanatban, a legdrágább körülmények között.
Ezt nem a fejlesztők ellen mondom. Ellenkezőleg: a legjobb fejlesztők is pontosan tudják, hogy a saját kódjukat nem érdemes tesztelni. Mert nem lustaságból maradnak el a hibák - hanem egy teljesen természetes, pszichológiai jelenség miatt. De kezdjük az elején.
A confirmation bias, amit mindenki ismer, de kevesen neveznek meg
Van egy klasszikus kísérlet a pszichológiában. Megkérnek egy csoportot, hogy számolják meg egy kosárlabda videóban a fehér csapatnak a passzmozdulatait. A feladat annyira leköti a figyelmet, hogy a résztvevők nagy része egyszerűen nem veszi észre a videó közepén átmasírozó gorilla jelmezes embert. (Hasonló jelenség az is, hogy csak olyan szakértőket hallgatunk meg, vagy csak olyanokkal vitakozunk akik véleménye megegyezik a miénkkel. Hasolnó jelenség az is, hogy nem minden re emlékszünk, csak a számunkra pozitív dolgokra stb. stb.)
A fejlesztői tesztelés pontosan így működik.
Amikor egy fejlesztő teszteli a saját kódját, a fejében már ott van a megoldás - tudja hogyan készült, tudja mire gondolt amikor írta, és öntudatlanul azon az úton jár végig amit a rendszer kezelni tud. Az edge case-eket, a boundary condition-öket, a kivételes helyzeteket,- azokat ahol a rendszer összeomlik, - ritkán találja meg. Mert a gondolkodásmódja ugyanaz, ami a hibát létrehozta. (Magyarul, mindig ugyanoda kattint, ugyanazokat a tesztadatokat használja stb.) E mellett nincs szisztematikusság a tesztelésben, mindig az érintett részeket nézi meg...
Ez nem hiba. Ez az emberi agy természetes működése.
Három eset amiből tanultam (ami végül is négy lett)
Oracle eljárás élesítése egy számlázó rendszernél
Egy Oracle alapú megrendelő és számlázó programhoz írtunk új betöltő eljárást, még rendszerszervező "időszakomban". Egy új online csatornához kellett automatikus betöltő rendszert írnunk. Eléggé késésben voltunk, ezért péntek délután az elkészült betöltőprogramot én teszteltem, mint rendszerszerveztő, illetve megnézte még a programozó. Teljeen jól működött, végigment a folyamat. Szuper. Péntek délután 19 óra körül beélesítettük, és hazamentünk....És tényleg jól működött, DE CSAK AZ ÚJ FUNKCIÓ! SEMMI MÁS NEM MŰKÖDÖTT AZ ADATBÁZISON....16 országban, nem volt számlázás, online megrendelés feldolgozás. stb.
Más funkciót nem ellenőriztünk csak az újat! (Minden eljárás "invalid-ba" ment, a dependenciák miatt.) Egy nagyon komplex rendszer volt. Másnap hajnalra sikerült az összes eljárást újra indítani.
Biztosítói kárbejelentő rendszer
Egy biztosítónál dolgoztunk egy ügyfélszolgálati mobilalkalmazáson. A fejlesztőcsapat alapos munkát végzett, belső teszteket futtatott, minden zöld volt. Mi vittük be a független QA-t az utolsó fázisba.
Az első nap végén a tesztelő kolléga megtalálta, hogy ha az ügyfél a kárbejelentési folyamat közben megkapja a bejövő hívást, elfogadja, majd visszatér az appba , a folyamat elveszti az addig beírt adatokat, de erről semmilyen visszajelzést nem ad. Az ügyfél újrakezdheti az egészet, fogalma sincs miért.
A fejlesztők egyszerűen nem gondoltak erre a scenárióra. Nem lustaságból , hanem mert ők a kárbejelentési folyamatot tesztelték, nem a telefon interrupt-kezelést kombinálva a kárbejelentési folyamattal.
Lízingcéges workflow rendszer fejlesztés
Egy operatív lízingcégnél a workflow automatizáció fejlesztői tesztjei sikeresen lefutottak. A független QA az első napon megtalálta, hogy a rendszer a speciális karaktereket tartalmazó ügyféladatoknál (ékezetes nevek, kötőjelek) hibásan kezeli az adatbázis-kommunikációt. Magyar piacon. Magyar nevekkel. Egyébként jól működött.
A fejlesztők latin betűs(angol) tesztadatokkal dolgoztak. Természetes - ők is "latinul" gondolkodnak, amikor tesztadatot írnak be.
Telefonos IVR rendszer fejlesztés
Egy FMCG cégnél online telefonos IVR alapú megrendelő rendszert fejlesztésén dolgoztunk. (Nyomja meg az 1-es gombot, 2-es gombot stb...) Minden szuperül összeállt, jól működött a teljes folyamat az összes funkció....Majd élesítés után egy órán belül összeomlott....Mint kiderült, ha túl sok "gombnyomás" volt egyszerre, akkor a szerver nem tudta azt kezelni...és ez egyrészt nem volt tesztelve, másrészt teljesen falsak voltak az információk az egyidejű hívások számáról. Sokkal több hívás volt jellemző, mint amiről a tervezés szólt. (Nem volt terheléses teszt. Nem is gondoltunk rá.)
A pszichológia mögötte - miért strukturális ez a probléma
A független tesztelés nem azért jobb mert a QA-k tehetségesebbek a fejlesztőknél. Azért jobb, mert más a perspektívájuk. (Általában sokkal jobban tudnak a felhasználók szemével látni, illetve képesek "kívülről" nézni az alkalmazást)
Egy független tesztelő több más jellegű hibát vehet észre, mint aki a programozókkal együtt dolgozik, mivel más rálátása lehet a projektre, illetve észre vehet olyan problémákat is, amelyek a fejlesztő csapat gondolkodásmódjából erednek.
Ez a kulcsmondat. Nem a hibák mennyiségéről van szó , hanem a minőségükről. A fejlesztő megtalálja azokat a hibákat, amelyek a kód logikájából fakadnak. A független tesztelő megtalálja azokat, amelyek az üzleti logika és a kód logikájának ütközéséből fakadnak, és ezek az igazán drága hibák.
Pénzügyi szektorbeli projekteknél ez hatványozottan igaz. Egy biztosítási kalkulátor hibájánál nem az a kérdés, hogy a kód szintaktikailag helyes-e , hanem az, hogy a biztosítási díjszámítási logika megfelel-e a termékleírásnak. Ezt a fejlesztő nem tudja ellenőrizni, mert nem ismeri a termékleírást a mélységében. A jó QA viszont igen. (Vagy, ha nem, akkor tud konzultálni az üzleti elemzővel, vagy termékmenedzsmenttel...)
Az is nagyon fontos különbség egy trsztelő és egy fejlesztő között, hogy a tesztelőnek a tesztelés a feladata. Sokkal szisztematikusabban tudja megtervezni a tesztelést. Persze a módszertan is fontos a szisztematikus munkához. (Epic-ek, user story-k stb)
"De nálunk a fejlesztők unit tesztet is írnak"
Igen. Ez jó. A unit teszt megtalálja a kód szintű hibákat.
De a unit teszt nem helyettesíti a funkcionális tesztelést, az integrációs tesztelést és a felhasználói tesztelést.(user acceptance test) Mert a unit teszt azt ellenőrzi, hogy egy izolált kódrész az elvárások szerint működik-e. Nem azt, hogy az egész rendszer a valódi felhasználói viselkedésre hogyan reagál. (Sokszor felmerül, hogy a felhasználó elég ha leteszteli, de véleményünk szerint erre a legtöbb felhasználónak nincs elég tapasztalata, szisztematikussága, illetve ugyanaz a gond, mint a fejlesztőknél: Nem ez a feladata.)
Az autógyártásban van egy hasonló különbség: az alkatrészek egyenként mind megfelelnek a minőségi előírásoknak , aztán az összeszerelt autóban a légkondicionáló és a navigáció egyszerre bekapcsolva lemerítik az akkumulátort. Ezt az alkatrészszintű tesztek nem fogják megtalálni.
Mikor elegendő a fejlesztői tesztelés?
Az objektivitás kedvéért: nem minden projekthez kell dedikált független QA. Vannak esetek amikor valóban elegendő a fejlesztői tesztelés.
Ha a projekt rövid és jól körülhatárolt, a felhasználói bázis kicsi és homogén, a hibák következménye alacsony kockázatú, és van gyors visszacsatolási lehetőség az éles környezetből , akkor a fejlesztői tesztelés elfogadható kompromisszum.
De ha bármelyik teljesül az alábbiak közül, a független tesztelés nem opcionális:
- Pénzügyi adatokat kezel a rendszer- Több száz vagy ezer felhasználó fogja egyszerre használni- Compliance vagy szabályozói megfelelés érintett- A hiba következménye ügyfélkár, adatvesztés vagy reputációs kár- A rendszer meglévő core rendszerekkel integrálódik
Pénzügyi szektorbeli projekteknél ezek szinte mindig teljesülnek. Nagy kockázat, fontos a teljes precizitás, nagy mennyiségű kapcsolat más rendszerekkel, és folyamatokkal.
Amit a FrontX-nél másképp csinálunk
A FrontX QA-i nem a fejlesztés végén lépnek be. Shift-left megközelítéssel dolgozunk: a tesztelő már a specifikáció review-jánál jelen van, a fejlesztési sprint közben párhuzamosan teszteli az elkészült funkciókat, és nem egy hatalmas végső tesztelési ciklusban próbálja meg megtalálni az összes hibát. (Persze van olyan eset, amikor "csak" a fejlesztők tesztelnek a fejlesztési szakaszban.)
Ez azért működik, mert a QA nem a fejlesztőcsapat munkatársa - hanem független szemmel néz a rendszerre. Nincs szociális nyomás, hogy "ne kritizálja a kolléga munkáját." Nincs érdekeltség a hibák eltussolásában. Van viszont pénzügyi szektorbeli iparági háttér - ami azt jelenti, hogy a QA érti az üzleti logikát, amit tesztel.
Ha senior QA szakértőt keresel aki érti a pénzügyi szektor folyamatait -vagy ha QA-ként dolgozol és olyan helyen szeretnél lenni ahol a tesztelés stratégiai szerep, nem utólagos ellenőrzés , nézd meg hogyan dolgozunk: frontx.hu/allasajanlatok
Kérdés hozzád
Találkoztál már olyan hibával éles bevezetés után, amit egy független tesztelő valószínűleg megtalált volna előtte? Mi volt a legdrágább "meglepetés" amit éles rendszer hozott?
Gyakran ismételt kérdések
Miért ne tesztelje a fejlesztő a saját kódját?
Mert a fejlesztő öntudatlanul azokat az utakat járja be tesztelés közben, amelyeket a rendszer kezel - nem azokat, ahol hibázik. A confirmation bias miatt a saját kód tesztelése strukturálisan korlátozott: a fejlesztő ugyanolyan gondolkodásmóddal tesztel, amellyel a kódot írta. A független tesztelő más perspektívából közelít, és olyan hibákat talál, amelyek a fejlesztő gondolkodásmódjából fakadnak.
Mi a különbség a fejlesztői tesztelés és a független QA között?
A fejlesztői tesztelés (unit tesztek, integrációs tesztek) a kód szintű hibákat találja meg. A független QA az üzleti logika és a kód ütközéséből fakadó hibákat találja meg - azt ellenőrzi, hogy az egész rendszer a valódi felhasználói viselkedésre hogyan reagál. A kettő nem helyettesíti, hanem kiegészíti egymást. (Nyilván nincs értelme hozzákezdeni egy olyan rendszer teszteléséhez a tesztelőnek, ahol még folyamatosan "error-okat dob" a rendszer. Ez csak felesleges időpazarlás lenne...)
Mikor szükséges független tesztelés IT projekteknél?
Mindenképpen szükséges, ha a rendszer rendkívül komplex, vagy pénzügyi adatokat kezel, esetéeg több száz felhasználó fogja egyszerre használni, compliance vagy szabályozói megfelelés érintett, vagy a rendszer meglévő core rendszerekkel integrálódik. Pénzügyi szektorbeli projekteknél ezek szinte mindig teljesülnek.
Mit jelent a shift-left tesztelés a független QA kontextusában?
A shift-left tesztelés azt jelenti, hogy a független QA nem a fejlesztés végén lép be, hanem a projekt elejétől jelen van, a specifikáció review-tól a fejlesztési sprint párhuzamos teszteléséig. Ez drasztikusan csökkenti az utólagosan javítandó hibák számát.
Hogyan különbözik a FrontX QA megközelítése?
A FrontX QA-i shift-left szemlélettel dolgoznak, pénzügyi szektorbeli iparági háttérrel. Nem csak a technikai hibákat keresik, hanem azt is ellenőrzik, hogy az üzleti logika helyesen van-e implementálva, esetleg észrevesznek olyan hibákat is amikor a rendszer formálisan jól működik, de üzletileg az nem lehettséges, vag logikátlan. Nem kell elmagyarázni a biztosítási folyamatot, a lízingszerződés életciklusát vagy a banki compliance elvárásokat, ezt már hozzák.
Szerzői bio
Behán László a FrontX Kft. ügyvezetője és társalapítója. Korábban a Signal Biztosító CIO-ja, a Groupama Biztosító fejlesztési és adattárház-vezetője, valamint a LeasePlan Hungaria igazgatóságának tagja volt operációs igazgatóként. 25 év IT és üzleti vezetői tapasztalattal rendelkezik a pénzügyi szektorban.
LinkedIn: linkedin.com/in/laszlobehan | FrontX blog: frontx.hu/blog
