A fejlesztő megírja a funkciót. Megírja hozzá a teszteket is – alaposan, lelkiismeretesen. Minden teszt zöld. A kód átmegy a pipeline-on, kimegy élesbe. Két héttel később a rendszer elhasal egy olyan eseten, amire senki nem gondolt.
A tesztek nem hazudtak. Egyszerűen nem a jó kérdést tették fel.
Ez a cikk nem arról szól, hogy a fejlesztők rosszul dolgoznak. Épp ellenkezőleg: arról, hogy egy alapvető emberi működés miatt a legjobb fejlesztő sem tudja teljes körűen ellenőrizni a saját munkáját és hogy ez miért üzleti kérdés, nem pedig bizalmi.
A vakfolt nem hozzáértés kérdése
Amikor egy fejlesztő tesztet ír a saját kódjához, egy rejtett csapdába sétál: a tesztjei ugyanabból a feltételezésből születnek, mint maga a kód.
Ha a fejlesztő félreértette a követelményt, akkor a tesztet is a félreértett követelmény alapján fogja megírni. A teszt le fog futni. Zöld lesz. És pontosan azt fogja igazolni, hogy a kód úgy működik, ahogyan a fejlesztő elgondolta, nem pedig azt, hogy úgy működik, ahogyan az üzletnek szüksége lenne rá.
Ennek a jelenségnek van neve a pszichológiában: megerősítési torzítás (confirmation bias). Hajlamosak vagyunk olyan információt keresni, amely a meglévő feltevéseinket alátámasztja, és öntudatlanul elkerülni azt, ami cáfolná őket. Aki alkotott valamit, az ösztönösen bizonyítani akarja, hogy működik, nem pedig kideríteni, hogy hol törik el.
Ez nem szakmai hiányosság. Ez emberi működés, amely alól senki nem kivétel – se a junior, se a húszéves tapasztalattal rendelkező szenior mérnök.
A szoftvertesztelés egyik alapművében, Glenford Myers 1979-es The Art of Software Testing című könyvében ez már alapelvként szerepelt: a programozó ne a saját programját tesztelje, mert a tesztelés célja nem a működés bizonyítása, hanem a hibák megtalálása – és ez a két cél gyökeresen eltérő gondolkodást igényel.
Két gondolkodásmód, amely kiegészíti egymást
A fejlesztő és a tesztelő nem ugyanazt a munkát végzi kétféleképpen. Két, alapvetően más irányú gondolkodásmódról van szó:
- A fejlesztő épít (konstruktív szemlélet). A kérdése: „Hogyan hozom létre azt a funkciót, amit a specifikáció kér?“ A sikerélménye az, amikor a rendszer működik.
- A tesztelő megkérdőjelez (analitikus, kritikus szemlélet). A kérdése: „Mi történik, ha nem így használják? Mi van, ha üres az adat, ha kétszer kattintanak, ha megszakad a kapcsolat, ha a harmadik fél lassan válaszol?“ A sikerélménye az, amikor megtalálja, hol törik el.
Fontos tisztázni: ez nem szembenállás. Egy jól működő projektben a két szerep nem egymás ellen, hanem egymást kiegészítve dolgozik. A tesztelő nem a fejlesztő munkáját minősíti, hanem a terméket vizsgálja egy másik nézőpontból, más előfeltevésekkel, más tapasztalati háttérrel.
Épp ez a lényeg: a különböző háttér különböző hibatípusokat hoz felszínre. Nem azért, mert az egyik szakember jobb a másiknál, hanem mert máshová néz.
A függetlenség nem fekete-fehér: szintjei vannak
Árnyalnám picit a cikk címét, mert a valóság ennél összetettebb – és a nemzetközi tesztelési szabvány is ezt tükrözi.
Az ISTQB (a szoftvertesztelés nemzetközi minősítő testülete) hivatalos szillabusza a tesztelői függetlenségnek négy szintjét különbözteti meg:
- A terméket a saját alkotója teszteli → nincs függetlenség.
- A terméket a csapaton belüli kolléga teszteli → részleges függetlenség.
- A terméket a szervezeten belüli, de külön tesztcsapat teszteli → magas fokú függetlenség.
- A terméket a szervezeten kívüli, független tesztelők vizsgálják → nagyon magas fokú függetlenség.
És most jön a lényeg, amit az ISTQB is kimond: a függetlenség nem helyettesíti a rendszerismeretet. A fejlesztő rendkívül hatékonyan találja meg a saját kódjában a hibák egy jelentős részét – hiszen ő ismeri a legjobban a belső működést. Az egységtesztek (unit tesztek) írása továbbra is a fejlesztő dolga, és ez így helyes.
A helyes válasz tehát nem az, hogy a fejlesztő ne teszteljen. Hanem az, hogy ne az ő tesztje legyen az utolsó szó.
A szabvány ezért többszintű függetlenséget javasol: a fejlesztő teszteli a komponenseit, a független tesztcsapat a rendszer egészét, az üzleti oldal pedig az átvételt. Mindegyik réteg más hibákat fog ki.
Mit nyer ezzel egy vezető? A független QA üzleti előnyei
Vezetői szemmel a függetlenségnek három konkrét hozadéka van:
1. Más hibák kerülnek elő. A független tesztelő eltérő szakmai háttérrel és eltérő torzításokkal érkezik, ezért jellemzően másfajta hibákat vesz észre, mint a fejlesztőcsapat. Nem többet, hanem mást. És éles környezetben pont ezek a „mások” szoktak fájni. Ezeknek az üzleti árát részletesen bemutattuk a <CIKK: A tesztelés nem költség, hanem bevételvédelem> című cikkünkben.
2. Megkérdőjelezi a feltételezéseket. A független QA nemcsak a kódot vizsgálja, hanem azokat a kimondatlan feltevéseket is, amelyek a specifikáció és a megvalósítás során beépültek a rendszerbe. Ez gyakran még a fejlesztés előtt kiszűri a félreértéseket.
3. Objektív státusz a menedzsmentnek. Ez talán a legfontosabb, és a legritkábban kimondott előny. Egy belső csapatra – emberileg teljesen érthető módon – nyomás nehezedik, hogy a projekt „zöld” legyen a státuszriporton. Egy külső, független partnernek nincs érdeke szépíteni. A vezető így a projekt valós állapotát látja, nem a kívánt állapotát és időben tud dönteni, amíg a döntésnek még van tétje. Hogy ez a kiadási döntésnél mit jelent a gyakorlatban, arról a <CIKK: Mit jelent egy sikeres release a CIO szemével?> című cikkünkben írtunk bővebben.
Egy figyelmeztetés ugyanakkor ide kívánkozik, és ezt az ISTQB is kockázatként nevesíti: a független tesztcsapat el tud szigetelődni a fejlesztőktől, ami kommunikációs problémákhoz, rosszabb esetben szembenállásához vezethet. A jó QA partner ezért nem a fejlesztőcsapat fölé, hanem mellé áll a közös célért a közös nyelven.
Összegzés
A fejlesztő ne azért ne legyen a saját kódjának egyetlen tesztelője, mert nem elég jó, hanem mert senki sem tudja objektíven vizsgálni azt, amit maga alkotott. Ez nem a bizalom hiánya, hanem módszertani alapelv, amelyet a szakma több mint négy évtizede ismer és a nemzetközi szabvány is rögzít.
A szerepek szétválasztása nem lassítja a fejlesztést. Éppen ellenkezőleg: tehermentesíti a fejlesztőket, hogy arra koncentrálhassanak, amiben a legjobbak: az értékteremtésre. Eközben a minőség ellenőrzését egy másik, kritikus szemlélettel dolgozó szem végzi.
A fejlesztő tesztelhet. Csak ne ő mondja ki az „utolsó szót”.
Források
- Glenford J. Myers: The Art of Software Testing (1979; 3. kiadás: Myers – Sandler – Badgett, Wiley) – a „ne a saját kódodat teszteld” alapelv és a tesztelés hibakereső definíciójának forrása
- ISTQB® Certified Tester Foundation Level Syllabus v4.0 – a tesztelői függetlenség szintjei, előnyei és kockázatai – istqb.org
