Gondolkodó tesztelő vagy?

Minden feladatot kétféleképpen lehet megcsinálni. Az ember vagy belead mindent és szívvel-lélekkel áll hozzá, vagy „csak letudja”. Az első esetnél általában nyitott, befogadó személyiséggel találkozunk aki érdeklődik a feladat iránt és gondolkodik a megoldásokon. Lelkes és motivált a szakmája iránt. Számomra ők a „gondolkodó” tesztelők.

Mit értek gondolkodó tesztelő alatt?

A gondolkodó tesztelő olyasvalaki, aki aktívan fejleszti képességeit, kritikusan áll a fennálló helyzethez és folyamatosan képezi magát szakmailag. Minden, az összefüggéseket figyelembe vevő tesztelő gondolko-dó tesztelő. Azonban gondolkodó tesztelők dolgoznak a hagyományos, „legjobb gyakorlatokat” követő folyamatok alapján zajló tesztelési projektekben. Ezek a tesztelők tisztában vannak azzal, hogy az IEEE 829 szerinti tesztterveik szinte verzióról verzióra azonnal elavulnak a kibocsátás után. Hallottak már a felderítő tesztelésről, de nem biztosak abban, hogy ez használható lesz-e az ő saját projektjükben.

Hadd jöjjek néhány tippel, ami segít felismerni ezeket a gondolkodó tesztelőket! Egy kis bátorítással tudnának csatlakozni az online globális tesztelői közösséghez, hozzájárulva a tesztelési metódusok folyama-tos javításához. Ideális esetben a Gondolkodó Tesztelő, a Kompetens Tesztelő és a Bölcs Tesztelő kifeje-zés elavulttá és feleslegessé válik.

Nem-Gondolkodó Tesztelők

Ha tesztelési megközelítéséről kérdezik, egy nem-gondolkodó tesztelő az ISTQB által előírt szoftverfej-lesztési életciklus fázisairól kezd beszélni. Meg van róla győződve, hogy a tesztautomatizálás valaki más dolga, és hogy őt ne kényszerítsék arra, hogy megtanulja egy új eszköz használatát. Amikor ezeknek a tesztelőknek új készségekre, új tudásra lesz szüksége, elvárják, hogy őket cégük munkaidőben képezze ki. Ennek hátterében a hagyományos tesztelési megközelítés azon feltételezése áll, hogy bárki az utcáról bejőve, minimális képzés után képes teszteseteket végrehajtani, és ezt nevezzük “tesztelésnek”.

Mivel most épp egy tesztelési magazint olvasol, ezért téged jó eséllyel besorolhatlak Gondolkodó Teszte-lőnek.

A gondolkodó tesztelő felismerése

Általában szenvedélyesen beszélek a szoftvertesztelésről, mint szakmáról, és sokféle érdekes választ kapok tesztelőktől.

A Nem-Gondolkodó tesztelők válaszai alig változnak:

• „Nem, én még nem hallottam James Bachról.”
• „Te munka után még tesztelői összejövetelekre jársz?!”
• „Oh, rendben, oké …”

Másrészt vannak olyan válaszok, mint ezek, melyek reményt adnak:

• „Honnan fogom tudni, hogy mit teszteljek tesztesetek nélkül?”
• „Honnan tudod, hogy befejezted a tesztelést?”
• „Hogyan tudnánk bemutatni a tesztelés állását?”
• „Hogyan találtál rá a tesztelői összejövetelekre?”

Mindezek a válaszok azt mutatják, hogy a tesztelő elkötelezett a szakmája iránt, és szeretne több tudásra szert tenni. Gyakran a hangjuk ellenségesnek hangozhat, mert össze vannak zavarodva, vagy félnek a változástól. Ez egy természetes reakció, figyelembe véve az időt és energiát, amit a már meglévő teszt-eseteikre és azok dokumentálására fordítottak. Ezt a védekező álláspontot alapvetően pozitívnak tartom. A tesztelő fontolgatja a véleményemet és lehetséges, hogy egy olyan új megközelítést fogad majd el, mely hatással van a szerepére és a termék minőségére.

Gondolkodó Tesztelő vagy?

Tegyük fel, hogy ebben a pillanatban nem követed az összfüggés-vezérelt megközelítést a tesztelésben! Használjuk példaként a teszteseteket:

• A tesztesetek nehézkesen használhatóak.
• A részletes tesztesetek – melyek precízek és pontosak – karbantartása időigényes, ha nem lehe-tetlen.
• A tesztek száma egyre nő minden termék release-zel, akárcsak az azok végrehajtásához szüksé-ges idő.

Ezekkel a tényekkel szembenézve, a Gondolkodó Tesztelők egy része más utakat keres a tesztelési fo-lyamatok javításához. Hívjuk ezeket „kompromisszumoknak”. A kompromisszumok annak útjai, hogy to-vábbra is a hagyományos tesztelési módszereket használjuk, ellenben lehetővé teszik, hogy ugyanezen módszerek fokozatosan gyorsítsák a tesztelést.

A tesztelés során rendszeresen kötünk kompromisszumokat, ami nem egy rossz dolog. Míg el nem felejt-jük, hogy kompromisszumokat kötöttünk, és el nem kezdjük a jelenlegi módszert a legjobb megoldásként kezelni…

Egy példa a kompromisszumra az „egysoros” tesztesetek írása, szemben a lépésről-lépésre haladó teszte-setekkel, ahol minden lépésnél megadjuk az elvárt eredményt is. Ez szükségtelenné teszi azt leírni, hogy „1. lépés: Lépj be egy érvényes felhasználóval!”, az elvárt eredménnyel „A felhasználó bejelentkezett”.

Ismerős?

Az „egysoros” tesztesetek felszabadítják a tesztelő idejét hatalmas mennyiségű információ másolása és beillesztése alól. Megjegyzem, a „felszabadítja a tesztelő idejét” egy eufemizmus. Ez valójában azt jelenti, hogy „megállítja a cég pénzének pazarolását”.

Egy másik kompromisszum lehet az is, ha a végrehajtás során a tesztesetek környezetét is bejárjuk, ahe-lyett, hogy megpróbálnánk minden egyes tesztesetet írásban rögzíteni a különböző tesztkörnyezeteken. Ha ezt összekötjük egy képernyőmentő vagy egy munkamenet riportáló eszközzel, akkor máris a rend-szerezett felderítő tesztelési megközelítés felé tettünk egy lépést.

Azt vettem észre, hogy egy bizonyos ponton – általában akkor, ha a tesztcsapat nyomás alatt van –, haj-lamosak vagyunk elfelejteni, hogy ezek a kompromisszumok egy ok miatt vannak a helyükön: lehetetlen, hogy minden releváns információt rögzítsünk a tesztesetekben. A csapatban csak az marad meg, hogy a tesztesetek teljes mértékben rögzítenek mindent, amit le kell tesztelni egy termék release előtt. A legin-kább figyelemmel követendő mérőszám az elvégzett tesztek mértéke lesz, mely a napi és heti helyzetje-lentésekben található meg. Egy Nem-Gondolkodó Tesztelőnek ez a mérőszám azt mutatja, hogy mennyi tesztet kell még elvégezni, eddig pontosan mennyi lett elvégezve; és hogy a tesztelés akkor fejeződik be, amint a zöld sáv eléri a 100 %-ot.

A Gondolkodó Tesztelő számára ez a mérőszám bosszantó és zavaró. Legjobb esetben ez egy nagyjábóli adat a menedzsmentnek arra, hogy még körülbelül mennyi tesztelési ráfordításra van szüksége a pro-jektnek. Rosszabb esetben ezt a tesztelési folyamat egyedüli mércéjeként és a termék minőségének indikátoraként használják. Ez a pillanatnyi helyzettel kapcsolatos frusztráció segíthet a Gondolkodó Tesz-telő felismerésében. Ez nem tévesztendő össze az állandóan panaszkodással, ami a Nem-Gondolkodó Tesztelő sajátja! A különbség felismerése bizony gyakorlatot kíván.

Összefüggés-vezérelt tesztelés (Context-Driven Testing, CDT)

Az összefüggés-vezérelt tesztelők egy része – magamat is beleértve – korábban a hagyományos tesztelé-si módszereket követte. Gondolkodó Tesztelőként viszont egyre inkább frusztráltak lettünk, miközben dokumentáció-igényes folyamatokat használtunk. Tesztelők vagyunk, akik folyamatosan kérdéseket tesznek fel és tanulnak, és valóban elkötelezettek vagyunk termékeink és a saját munkánk minősége iránt.

A frusztráció leküzdéséhez a Gondolkodó Tesztelőnek olvasnia, kutatnia kell minél szélesebb körben a szakmájában. Ahhoz, hogy kitűnjünk bármely szakmában, az elkötelezettségünkre van szükség, amely túlmutat a napi munkán. Minden tesztelő találhat olvasni-, tanulnivalót különböző tesztelési megközelíté-sekről és gyakorolhatja e módszerek használatát, akár otthon is PC-n, táblagépen vagy okostelefonon.

A CDT fordulópontja

Azonosítottam néhány módszert, hogyan tudja egy Gondolkodó Tesztelő elérni a CDT-hez vezető fordu-lópontot, azaz mikor van az a pillanat, amikor a tesztelő felismeri, hogy alapvető tévedések vannak a ha-gyományos, “egy kaptafára” megközelítést alkalmazó tesztelésben, és fogékonnyá válik a CDT-módszerek megfontolására, alkalmazására.

A leghatékonyabb együttdolgozni egy trénerrel vagy mentorral. A tréner végig tudja vezetni a tesztelőt a szakmai fejlődés időszakán, ahhoz segédanyagokat és támogatást nyújtva. A Szoftvertesztelési Egyesület (Association for Software Testing, AST) számos tesztvezető adataival rendelkezik, akik hajlandóak tréneri szolgáltatásokat biztosítani az érdeklődőknek. Ennél is több AST-tag hajlandó online segítséget nyújtani, ha e-mailben keresik őt meg.

Az összefüggés-alapú és felderítő tesztelésről szóló irodalom olvasása segít a Gondolkodó Tesztelőnek, hogy a maga idejében elérje a fordulópontot. Kiindulásként javaslom olvasásra Elisabeth Hendrickson könyvét: Leckék a szoftvertesztelésből a Caner, Bach és Pettichordnál (Lessons Learned in Software Test-ing by Caner, Bach & Pettichord and Explore It!).

Végezetül, a professzionális tesztelési megközelítések, a szakirodalom rendszeres és mélyreható tanul-mányozása kiváló útja, hogy lelkesek és motiváltak legyünk szakmánk iránt. Gondolok például az aktív konferencia-részvételekre, a korábbi konferencia-előadások megtekintésére a YouTube-on, a tesztelési magazinok olvasására és szakmai blogokra való előfizetésre, mint pl. a Software Testing Club.

Forrás: https://www.testingcircus.com/Are-You-A-Thinking-Tester/
Szerző: Kim Engel