Az az érzésem: Érzelmek a tesztelésben

Egyesek szerint az érzelmeknek nincs helye a szoftvertesztelésben, azonban valójában az ellenkezője igaz. A minőségről való döntések hátterében mindig érzelem áll. Ha jobb tesztelő akarsz lenni, figyelj oda az érzéseidre! 

Néhány évvel ezelőtt előadást tartottam egy konferencián az érzések és érzelmek szerepéről a szoftvertesztelésben. Egy évvel később találkoztam valakivel a hallgatóság közül – aki ma már kollégám. Elmesélte, hogy a beszélgetés után visszament dolgozni s megvitatta a konferencián elhangzottakat a főnökével.

„Hallottam egy érdekes előadást az érzelmek szerepéről a szoftvertesztelésben“ – mondta.
„Az érzelmeknek nincs szerepe a szoftvertesztelésben“ – válaszolta főnöke nyersen.
„Tényleg? – „Tetszettek az előadó érvei, s számomra volt értelme annak amit mondott.“
A főnöke elképedten nézett rá, s a dühtől vörös lett. „Az érzelmeknek nincs szerepe a szoftvertesztelésben“ – üvöltötte.
„Elképesztő volt“ – mesélte a barátom később. „Felvetettem, hogy van helye az érzelmeknek a szoftvertesztelésben, és ő teljesen emocionálisan reagált erre a felvetésre.“

Ez így van, és érdekes lenne megtudni, vajon miért. A Quality Software Management első számában (Quality Software Management, Volume 1: Systems Thinking), Jerry Weinberg rámutat, hogy a minőséggel kapcsolatos döntések mindig politikai és érzelmi indíttatásúak. Egy termékkel s projekttel kapcsolatos döntések politikai döntéssel indulnak – kinek az értékei érvényesülnek másokéval szemben -, s ezáltal máris érzelmek kerülnek a játékba. Még akkor is, amikor racionális elemek mentén történik egy esetnek vagy helyzetnek az értékelése, a vágyak érvényesülnek a döntésekben – mit szeret s nem szeret, mit akar vagy mit nem akar az ember. A döntéshozók mondhatják, hogy pusztán „számokon alapuló“ racionális döntéseket hoznak, valójában azonban aszerint döntenek, hogy miként éreznek a számokról. Amit mi racionalitásnak nevezünk, az valójában belső politikai döntés arról, hogy melyik érzésünk kerekedik felül egy másikon. A vágy arra, hogy racionálisak legyünk maga is egy érzelem.

A hiba is egyfajta problémát jelent – egy szoftver értékét fenyegeti azáltal, hogy potenciálisan fenyegeti valaki vágyának beteljesülését. A szoftverfejlesztésben van egy másfajta probléma is – ezt mi a gyors szoftvertesztelésben issue-nak, témának hívjuk. A téma lehet bármi, ami veszélybe sodorhatja a tesztelés, a projekt vagy akár az egész üzlet erőfeszítésének eredményét.

A probléma kimutatásához a tesztelők jóslást alkalmaznak. A jóslás egy módja annak, hogy felismerjük a problémát. Eredetileg a tesztelők kétféleképpen tekintettek a jóslásra: elvek mentén (úgy mint következetesség a felhasználói követelményekkel, néhány céllal, vagy egy hasonló termékkel kapcsolatban) vagy szerkezetileg (pl. egy tesztprogram, ami összehasonlítható eredményt, vagy véges állapotú modellt vagy specifikációt nyújt. A probléma felismerésének egy módja lehet, ha szenvtelenül átfutjuk a specifikációt vagy a követelményekről szóló dokumentumot, és a termék működését összehasonlítjuk a leírásával, amely részletezi, hogyan is kellene viselkednie. Mégis az embereknek egy termékkel kapcsolatos szándékuk vagy vágyuk íratlan vagy kimondatlan lehet. A specifikációban lehetnek hibák, vagy a piac változhat olyan nagyot, hogy a követelményekről szóló dokumentum már nem azt a fogyasztói szándékot tükrözi, mint ami a dokumentum megírásakor volt.

Ráadásul a dokumentumban egy személy vágyai vagy szándékai szerepelnek egy olyan termék megalkotására, ami egy másik személy vágyait teljesíti be. A dokumentum és a termék közötti ellentmondás meglepő, megdöbbentő vagy csalódás lehet az adott személynek, de ami fontos itt az az ellentmondás a termék és a vágy között. Tehát anélkül hogy konkrétumra utalnák, megerősíthetjük, hogy problémát jelent, ha egy személyt közvetlenül megkérdezünk.

Az a fajta párbeszéd a lehetséges probléma felismerésének egy még inkább közvetlenebb módjával kezdődik. Saját tapasztalatom alapján még azokon a ritka alkalmakon is egy érzelemmel (meglepetés, megdöbbenés, csalódottság, gyanakvás, türelmetlenség vagy bosszúság) kezdődött egy hiba kezdeti felismerése, amikor már eleve volt róla egy viszonylag világos, szilárd és friss információm. Néha azért veszek észre egy hibát, mert szó szerint viccesen néz ki. Lehet, hogy használok egy dokumentumot, vagy megbeszélem a terméktulajdonossal, hogy jogosan tartom-e hibának, mindenesetre mindig éberen figyelek, ha egy ilyenféle érzelem szakítja félbe a munkámat.

Az érzelmek az issue-k felismerésében is segíthetnek. Például, ha egy projekt során nem tudom a programozókat vagy a terméktulajdonosokat azonnal elérni, esetleg ideges vagy türelmetlen leszek, mert a hosszúra nyúló válaszidő több időt és lehetőséget ad a hiba rejtőzésére. Ha unatkozom, az annak lehet a jele, hogy a tesztelés amit éppen végzek, jelentéktelen, felesleges vagy mechanikus – ebben az esetben jobb inkább gépiesíteni. Amikor egy kétértelmű elvárás megzavar, a programozókat és más tesztelőket is összezavarhatja. A bizonytalanság és a kétértelműség a hibák melegágya.

Tesztelőként más emberek szemszögéből figyelem az alkalmazást. Néha a termék felhasználójának szerepében vizsgálom. Máskor mint a programozók és termék tulajdonosok extra szeme, füle és keze vagyok. Mindkét esetben fontos, hogy szem előtt tartsam saját érzelmeimet. Így jobban rá tudok hangolódni egyrészt azokra a dolgokra, amik problémát jelenthetnek a tesztelő ügyfeleimnek, másrészt azokra az eshetőségekre, melyekben az érzelmeim befolyásolhatják vagy elferdíthetik a termék értékével kapcsolatos észrevételeimet.

Amikor egy problémát jelentek, az általában rossz hír más számára. A programozó csalódott lehet, mert eddig úgy gondolta, hogy ügyesen végzett a fejlesztéssel. Az üzletelemző zavarba eshet, mivel elfelejtett egy bizonyos eshetőséget számba venni. A programmenedzser aggódhat, hogy a hiba kijavítása a határidő csúszásával járhat. Más emberek érzéseinek számbavétele az együttérzés alapja. Amikor együttérző vagyok, akkor sokkal kevésbé valószínű, hogy ítélkezni vagy vádolni fogok a jelentésemben, s ez egy sokkal hatékonyabb kapcsolatot eredményez a kollégáimmal.

Az együttérzés lehet egy eszköz is mások reakcióinak megértéséhez. Például amikor egy fejlesztési projektben felismerem az érzelmek választékát, változatosságát és intenzitását, máris látom, hogy miért érzi magát néhány ember lesújtva vagy megrémülve amikor beismeri azokat. Ha együttérző vagyok, akkor rájövök, a félelem juttat valakit – tévesen – oda, hogy azt állítsa, a szoftvertesztelésben nincs helye az érzelmeknek.

Forrás: http://www.developsense.com/presentations/2013-05-STAREast-EmotionsInSoftwareTesting.pdf
Szerző: Michael Bolton