Mi ölheti meg a tesztelést?

• 

Habár Rómát nem 1 nap alatt építették, 64-ben 6 nap alatt mégis leégett, majd egy kicsit tűzállóbban újraépült. Amikor a chichagói Iroquous Színház leégett 602 ember halálát okozva 1903-ban, 1904-ben javították a színházak tűzvédelmi szabályzatát. A Triangle Waistcoat Factory tűzesete New Yorkban (146 halott) vezetett oda, hogy megalapítsák a New York City Tűzvédelmi Hivatalát. Az Amerikai Tűzoltó Szövetség jelenleg is több száz előírást, szabályt tart fenn – sokat különlegesen tragikus tűzesetek inspiráltak. Az emberek tanultak a katasztrófákból.

Ezért is vannak tesztelők. Szoftver-katasztrófák is történtek és az emberek tanultak belőle. Óvatosabbá váltak, energiát szenteltek a minőség biztosítására (beleértve a tesztelést is) és ezért kevesebb katasztrófa történt. De a tűzvédelmi szabályzatokkal ellentétben minőségbiztosításra egyetlen törvény sem kötelez. Ha a vállalatnak egy ideje nem volt szoftver-katasztrófája, akkor gyakorlata egyre kockázatosabbá válik részben azért, mert fiatal és ártatlanabb munkatársak kerülnek a tapasztaltabbak helyére. Ez a normál darwini körforgás.

Ezért is nem meglepő, hogy 2011-ben a STARWest konferencián James Whittaker (a Google-tól) bejelentette, hogy a tesztelés halott. Mi? A tesztelés halott? Úgy tűnt azt állítja, hogy a tesztelőkre már nincs szükség ebben az automatizált ellenőrzéseket futtató és automatikus frissítésekkel rendelkező világban. De Whittaker nem egy profi tesztelő . Képzeljünk el egy bútorgyárat ahol a cégtulajdonos, aki soha nem csinált egyetlen egy bútort sem, bejelenti, hogy a szakképzett asztalosokra nincs többé szükség. Na ez pont így hangzott nekem.

Mintha a “Sors” meghallotta és megsértődött volna, pár héttel később egy csomó Google hiba került nyilvánosságra és a CNN.com-on az alábbi cikk jelent meg: “A hét, melyet a Google valóban elrontott.” Egy pár héttel később a Google Wallet-nek egy komoly biztonsági problémáját is feltárták, ami még nagyobb nyilvánosságot kapott.

Mit jelent ez a tesztelés számára? Végtére is nincs olyan tesztelési módszer, amivel garantálhatnánk a hibamentes működést. Másrészt más folyamatok is találhatnak hibákat, vagy megakadályozhatják őket. Nem szakmabeliek is találhatnak hibát, a programozók is tesztelhetik kódjukat. Csak azért mert a Google egy kicsit megkavarodott, a rossz szoftververzió kiadása nem jelenti azt, hogy több tesztelőre lenne szüksége. Lehet csak jobb programozókat kellene foglalkoztatniuk, vagy képezni kellene őket.

Valami azért nyilvánvaló: Furcsa dolog azzal kérkedni, hogy felesleges a tesztelés és egyben elvárni a felhasználóidtól, és (egyben) számos kormányzattól, hogy bocsássanak meg neked a hibás terméked miatt.
Mi ölheti meg a tesztelést?

A tesztelés nem halott és nem is lesz az. És bárhol ahol úgy tűnik a tesztelés kihalt, újjá fog születni főnix-szerűen, nem pontosan a saját hamvaiból, hanem a halála következményeiből. Mégis jó azon elgondolkodni, mi is okozhatja a tesztelés halálát (átmeneti jelleggel). A közelmúltban Michael Bolton és jómagam leültünk és törtük egy kicsit ezen a fejünket. Íme amire jutottunk, mitől is halhat ki a tesztelés:

1. Ha a tesztelés szót az ellenőrzésre kezded használni. Michael azzal segítette a szakmát, hogy anno azt javasolta, tegyünk éles különbséget a tesztelés és a puszta kimeneti ellenőrzés között. A tesztelés azt jelenti, hogy kérdéseket teszünk fel a termékről annak érdekben, hogy értékelhessük. A tesztelés egy véget nem érő vizsgálat, amelyet nem lehet automatizálni. Az ellenőrzés ezzel szemben automatizálható, mert itt konkrét információkat gyűjtünk össze és elemzünk bizonyos módszerek szerint. Filozófiai értelemben az ellenőrzés mimeomorf, míg a tesztelés polimorf tevékenység. (Mimeo- a másolásra, míg a -morf a formára, alakra utal, vagyis olyan tevékenységre, amelyet mindig ugyanúgy végzünk, mintha csak valami gépek volnánk. A polimorf tevékenység sokoldalú, többféle alakban előforduló, változatos cselekvésre utal.) Néhányan, főleg a programozók közül, akik nem sokat tanultak a tesztelésről erősen az automatizálás felé húznak. Olyan eszközöket kerestek, amelyeket tesztelésre tudnak használni. Ezekkel a szoftverekkel azt csinlják, amire a szoftver képes, vagyis rengeteg ellenőrzést végeznek. Számukra a tesztelés kicsivel több, mint egy parancssori kapcsoló beírása a futtatásnál. Ezek az ellenőrzések képesek arra, hogy hibákat találjanak, nem olyan mély és összetett hibákat mint egy szakképzett ember. A tesztelést az ellenőrzéssel keverve tényleg megölhetjük a tesztelést. A tesztelés szerintünk (Michael és én szerintem is) továbbra is létezik, habár egy kicsit háttérbe lett szorítva.
   Ezt azt jelenti, hogy egyre kevesebb ember fogja szisztematikusan tanulni hogyan is kell tesztelni, amíg nem találunk egy jó kifejezést arra mit is jelent valójában a tesztelés. Ha rendszeresen tanulsz egy technikai témát, képes vagy róla beszélni. Ha az összes tesztelésről mondott szavad sekélyes és csak a mechanikus folyamatokra utalnak, akkor nem vagy elég szakképzett.
   
2. Ha a terméked lényegtelen. Vagyis amikor nem érdekel sem a szoftver minősége, sem a felhasználók elégedettsége. Hasonlóképpen, ha folyamatosan megbízunk a boltban vásárolt ásványvízben vagy a húsban, akkor az élelmiszer-higiéniai előírások irrelevánsak lesznek egy idő után számunkra.
   Az tényleg probléma az iparágunkban, hogy mindenki azt gondolja/hiszi, hogy mindig minden megbízhatóan fog működni. A múltkor kiléptem a házból a hidegbe és az Android telefonom semmilyen hívást sem tudott indítani a mobilhálózaton. Újraindítás után még mindig nem működött. Próbáltam WiFi hálózaton keresztül hívást indítani, de nagyon furcsa hibaüzenetet kaptam. Pár perccel előtte a házból még képes voltam WiFi-n keresztül hívni, ezért tudtam, hogy ennek működnie kellene. Végül a Skype-al sikerült hívást indítanom (de az is WiFi-t használt), akkor az előbb a telefonnal miért nem sikerült? Ez felételezhetően valamilyen op-rendszer hiba, amitől bosszús vagyok, de egyáltalán nem csodálkozom rajta.
   A Google-nél valószínűleg azt gondolják, hogy ilyen apróság miatt csak nem fogok telefont váltani. Viszont az ilyen helyzetek lehetőséget teremtenek a versenytársaknak, hogy jobb termékkel jöjjenek elő – de várjunk csak – évekkel ezelőtt dolgoztam az Apple-nek, ahol ugyanígy nem törődtek az ilyen hibákkal. Sokan azt hiszik, mindig sikeresek lesznek.
   
3. Ha a tesztelés minősége folyamatosan rossz. Sajnos a tesztelés halála önmegvalósító prófécia lehet. Azok az emberek akik ebben hisznek – pl. a Google-nál – nem valószínű, hogy tanulmányoznák magát a tesztelést. Egyszerűen nem tudják hogyan kell tesztelni, vagy szimplán nem érdekli őket. Csak idő kérdése és a menedzsment elkezd azon gondolkodni, miért is vannak egyáltalán tesztelők a cégben?
   Az ellenszer, a magas szintű személyes motiváltság és szakmai tudás. Ez az amit a kontextus-vezérelt tesztelési közösség támogat. Megteszünk mindent, hogy jó módszereket mutassunk a tesztelői világnak.
   
4. Ha a világ összes felhasználója technokrata lesz. Tegyük fel, hogy a világon az összes számítógépet/mobilt használó ember műszakilag képzett és rendkívül toleráns a hibákkal szemben. Ekkor a tesztelés szükségessége drámaian csökkene, hiszen mindenki jó minőséget akarna használni, de egyben megértenék és elfogadnák/kezelnék a hibákat. A létező hibákra türelmesen megkeresnék az átmeneti megoldásokat. Ez tökéletesen igaz azokra a béta szoftverekre amiket a Google ajánl (aztán megszűntet), de szerencsére a földön nem mindenki technokrata. Csak nagyon kis számú ember tölt le olyan szoftvert ami hasonlít pl. a Google Earth-re, és tölt el több órát azzal, hogy úgy állítsa/paraméterezze be ezt a terméket, hogy (egyáltalán fusson és) közel úgy lehessen használni mint magát a nagy testvért.
   
5. Megfulladhat. Ha a tesztelők arra kényszerülnek, hogy tudásukat csak egy szűk termék-, vagy eszközönskálán használják, akkor a termelékenységük nagyon csökkenhet. A végletekig kidolgozott tesztterv sablonokról, tesztszkript templatekről és szabályzott menedzsment eszközökről beszélek, vagy olyan automata eszközökről, amelyek megkövetelik a tesztelőktől, hogy csakis az előre meghatározott, korlátozott módon fejezzék ki magukat. Azért hal meg ilyenkor a tesztelés, mert a tesztelők eszközszakértőkké válnak, ahol a siker súlya az előállított papír, vagy kódsor mennyisége – ennek vajmi kevés köze van a teszteléshez. Az eszközök nagyban segítenek a tesztelésben, de a kiváló tesztelő ellenáll minden olyan dolognak, amely akadályozza munkája változatosságát és mélységét.
   
6. Ha a technológia nem fejlődik tovább. A tesztelés azt jelenti, hogy kérdéseket teszünk fel a termékről. Egy idő után nem sok kérdést tudsz feltenni egy olyan termékkel kapcsolatban ami nem változik, pláne nem egy olyannal kapcsolatban, ahol a futtatókörnyezet és a felhasználói bázis is változatlan. Az innovációs törekvések miatt van szükség tesztelőkre. Ha ez megszűnik, akkor kereshetünk magunknak új szakmát.
   
7. Ha kiéheztetik. Ha a vállalat csak azokat az embereket jutalmazza meg, akik egy-egy üzleti kockázatot megoldanak/csökkentenek, azokat viszont elfelejti megdícsérni akik valójában felfedezték ezeket a kockázatokat, akkor a tesztelést elhanyagolják. Egy ilyen helyen nem kap elég táptalajt a tehetséges, motivált, intelligens tesztelő, mivel itt csak unalmas, érdektelen, meg nem becsült feladatvégző egyeddé válik. Itt csak azok a tesztelők maradnak, akik vagy túlságosan meg vannak rémülve, vagy egyszerűen csak lusták váltani. A tesztelés hatékonysága pedig nagyon gyorsan romlani fog.
   Michael és én a Rapid szoftvertesztelést tanítjuk (Rapid Software Testing), ami a tesztelés harcművészete. Megmutatjuk az embereknek, hogy a munkájukban milyen lehetőségek rejtőznek. Táptalajt biztosítunk nekik, “etetjük” a tesztelőket.

Forrás: http://www.satisfice.com/blog/archives/5290