Szatmári Péter

Érdemes egyáltalán megtanulni angolul? Igen: én például pont kétszer annyit kerestem az első multis munkahelyemen, ahol már tudni kellett angolul, mint azelőtt.

De mégis, mennyire kell tudnia egy tesztelőnek angolul?

Az első kérdés, hogy kell-e napi szinten külföldi kollégákkal beszélned. Ha igen, akkor értened kell a beszélt nyelvet és meg is kell szólalni, sőt: tudnod kell érvelni angolul. A nyelvtani hibák viszont nem nagyon számítanak, amíg érthető maradsz. Én az évek alatt még sohasem hallottam, hogy bárki kínos helyzetbe került volna nyelvtani hiba miatt, vagy hogy kibeszélték volna a háta mögött. Kevesen beszélnek annyira jól angolul, hogy ne ejtsenek nyelvtani hibákat menet közben.

Éppen ezért, ha van lehetőséged nyelvtanfolyamra járni, nem az a jó választás, ahol akkurátusan végighaladtok a tankönyvek egyre magasabb szintjein, és ahol a tanár hosszasan magyarázza a nyelvtani szerkezetek jelentését. Az a jó nyelvtanfolyam, ahol megszólalsz, ahol egy idő után beszélgetni tudsz.

Ha viszont a hétköznapi kommunikációs nyelv a magyar, mihez kellhet az angol egyáltalán? Ott van például az írásos anyag, a dokumentáció, ha van egyáltalán. De jó esetben személyesen fog egy magyar kolléga betanítani a szoftver használatára…

Vagy ott vannak a tesztesetek és a bugok, amiket esetleg angolul kell megírni. Ezekhez egy nagyon szűk szókincs elegendő, az viszont elengedhetetlen. Click the button – the window opened. The software crashed. Ami eggyel nehezebb, az a bugok indoklás része – miért gondolod ezt egyáltalán hibának, ehhez már eggyel nagyobb szókincs szükséges. Viszont amíg csak írásban kell megnyilvánulni, számíthatsz a barátaidra: Google Translate, ChatGPT, CoPilot.

Végül a meetingek: egy bizonyos szint alatt megúszhatod, hogy külföldi kollégákkal kelljen beszélned. Megfordítva viszont: egy bizonyos szint fölé nem fogsz eljutni, ha nem tudsz külföldi kollégákkal beszélni.

Egy időben hetente tartottunk bug scrub nevű rendezvényeket, ahol összeültek a projekt vezetői és elolvasták, majd priorizálták az adott időszakban riportolt bugokat. A probléma az volt, hogy aki vezette a meetinget és felolvasta a bugokat, az

1. nem értett a termékhez,
2. diszlexiás volt, nehezen értette meg a leírt szöveget.

Ott tanultam meg jól bugokat írni. Az a bug volt jól megírva, amit a terméket nem ismerő, diszlexiás igazgató is azonnal megértett. Ennek két titka volt:

1. A description rész elején elhelyezett rövid, nagyon jól érthető indoklás
2. Screenshot, amin a hibát nagy, piros ellipszissel jelöltem meg. Ha van pozitív ellenpélda, azt egy másik screenshoton nagy, zöld ellipszissel jelöltem meg.

A jó screenshot hasznosságát talán nem kell magyarázni, ahogy mondani szokták: egy kép többet mond ezer szónál. Ebben az esetben gyorsan és hatékonyan megmutatja, hogy pontosan hol és mivel van probléma.

Az indoklás rész már bonyolultabb. A Description kitöltése amúgy is mindenkinek gondot okoz, mert szabad szöveges mező, nincs a többi mezőre jellemző fogódzó, választási lehetőség. Mit kell oda írni egyáltalán? Steps to reproduce, Expected results, Actual result – ez a szentháromság, és a többség ezzel meg is elégszik.

A személyes felfedezésem az volt, hogy a bug életciklusában résztvevő minden kollégának (projektvezető, fejlesztők) segít, ha megindoklod, miért hiszed a riportolt jelenséget problémának. Leginkább az „impact” faktort érdemes körülírni:

• a jelenség kinek okoz problémát (végfelhasználónak > belsős adminisztrátornak > tesztelőknek)
• mekkora problémát okoz (anyagi vagy reputációs kár a cégnek > nehezíti az életet, de nem állítja meg > nem okoz gondot, de javíthatná a terméket)
• mekkora eséllyel, milyen gyakran fordul elő (élesben is jó eséllyel bekövetkezik > kicsi az előfordulás esélye > speciális esetben fordul elő)

Mert mindenki azt hiszi, hogy ha a mezőket alapszinten kitöltötte, az már elég, abból már mindenki másnak is értenie kell, hogy milyen súlyos problémát fedeztünk itt fel. A valóságban viszont mindenki más ellenérdekelt abban, hogy hibákat fedezzünk fel a termékben és azok javításával időt, energiát töltsünk. Éppen ezért, ha mégis el rá akarjuk venni a csapatot a hiba javítására,  érdemes alaposan megindokolni, miért jelent ez a dolog problémát, miért lenne fontos mégiscsak kijavítani.

Az egyik leggyakoribb buzzword vezetői oldalról: automatizáljuk a tesztelést! Mindig, mindenhol hallani ezt, teljesen függetlenül attól, hogy a tesztelési kultúra milyen érettségi szinten van a szervezetben, és hogy technikailag mit lehetne egyáltalán automatizálni.

Kezdjük az alapokkal: mit várunk el a teszteléstől? Még az élesítés előtt vizsgáljuk meg a terméket, találjuk meg a hibákat, csökkentsük az élesítéssel járó kockázatokat. Mit lehet ezen automatizálni?

A tesztelés automatizálásának két szituációban van értelme. Az első a regressziós tesztelés: a rendszeresen, ugyanúgy megismételt tesztelési feladatok. Ezeket manuálisan végrehajtani unalmas, nagyobb a hibalehetőség, illetve a manuális tesztelés lassú, automatizálva gyorsabban, több tesztet lehet lefuttatni.

A probléma, hogy a változásokat és a fejlesztéseket az automata eszköznek egyesével be kell programozni – ez viszont csak lassan megy, tehát adott funkció leteszteléséhez az automata tesztelőnek sokkal több idő kell, mint a manuális tesztelő kollégáknak. Az agilis módszertani elképzeléseknek általában része, hogy az adott sprintben az új fejlesztésekhez tartozó automata tesztek is készüljenek el, de én még soha, sehol nem láttam, hogy ez ténylegesen megtörtént volna, az automata tesztelés általában hónapokkal lemaradva követi csak a fejlesztéseket.

Tisztában kell lenni továbbá a Pesticide paradoxon nevű alapelvvel: ha ugyanazokat a teszteket ismételjük újra és újra, végül ezek a tesztek már nem fognak új hibákat találni. Ezért a teszteseteket rendszeresen felül kell vizsgálni, karbantartani, új teszteket kell hozzáadni, hogy az automata hibákat találjon. A regressziós tesztelést hosszútávon érdemes automatizálni.

A másik szituáció, ahol az automatizálás hasznos lehet a load test, a terhelés szimulálása. Például ha manuális tesztelőből nem tudunk annyit felsorakoztatni, amennyien a végfelhasználók lesznek – a számítógép viszont szimulálni tudja ezt a helyzetet, ahogy a hosszan tartó, folyamatos terhelést és sok más nehezítést is.

Kik azok a tesztautomatizálók? Az automata eszközök programozásához programozói tudás kell. Az automata tesztelők ezért a fejlesztők/tesztelők tengelyén a fejlesztőkhöz állnak közelebb, gyakran fejlesztők specializálódnak automata tesztelésre. Mivel a fejlesztők többet keresnek a tesztelőknél, a „tesztelés automatizálása” viszonylag drága mutatvány, mármint ha a cél simán csak a manuális tesztelők kiváltása.

Hogyan mérhető, hogy megéri-e? Minden automata tesztelő előszeretettel hivatkozik a lefuttatott tesztesetek számára. Száz, ezer, tízezer API hívást indítottunk, jó alaposan leteszteltük tehát a rendszert. Valóban?

Szerintem mindenféle tesztelés értelmét és eredményességét végső soron a riportolt, majd kijavított hibák száma mutatja meg – ennyivel fejlődött ugyanis a szoftver a tesztelő tevékenysége nyomán. Ha egy automata tesztelő évek óta dolgozik a csapattal, de soha, egyetlen hibát sem riportolt (megtörtént), ott el kellene gondolkozni, hogy valóban megérte-e a tesztelés automatizálása…

Az a helyzet, hogy mindenki gondol erről valamit – de mindenki valami mást.

Minden teszt adminisztrációs rendszerben van a bugokhoz legalább két mező, általában Priority és Severity néven, amelyekkel elméletileg a hiba súlyosságát, a javítás sürgősségét, valamint az okozott kár nagyságát lehet jelölni. Minden cégnél, minden csapatban van valamilyen definíció arra, hogy ezeknek az értékei, és az értékek kombinációi mit jelentenek: azonnal kell a javítás, sürgősen javítani kell, nagyon fontos, kevésbé sürgős stb.

Ezek a definíciók azonban kissé homályosak, egy idő után összefolyik, hogy a Major és a Critical között mi a különbség. Pontosabban, tapasztalatom szerint mindenki pontosan tudja, hogy mi jelentenek – de mindenki másképp…

A hibát ott követjük el, hogy a definíciókat a saját szempontunkból írjuk meg. Ehelyett arra kellene gondolni, ami a fejlesztők oldalán történik:

1. Dobjanak el mindent azonnal, javítsák ki a hibát és küldjenek hotfixet
2. Vegyék előre a hiba javítását, és már a következő sprintben, következő buildben szállítsák is le
3. Később is ráér a hiba javítása, de az élesítésig legyen készen
4. A hibával az éles működés során is együtt tudunk élni

A fenti besorolásokat nevezzük el például úgy, hogy Blocking, Critical, Major, Minor, és a szerződésbe írjuk le a vonatkozó határidőket (pl. két munkanap / következő sprint / élesítés dátuma) és kész is vagyunk. Minden más (pl. a Severity mező használata) csak felesleges bonyolítása a csapat életének.

Röviden: a bugok miatt.

Hosszabban: a tesztesetek megírására és az eredmények (Passed/Failed) rögzítésére bőven elegendő az Excel. Sőt, az Excel tűnik az ideális megoldásnak: kell néhány oszlop (Chapter, Steps to reproduce, Expected result, Actual result, Notes), és lehet is írni a teszteseteket egymás alá. Az Excel erre tökéletes, volt, ahol még akkor is Excelben írtuk meg a teszteket, ha volt erre bevezetett, specializált eszköz – megírtuk Excelben, aztán betöltöttük őket a rendszerbe.

A probléma a hibáknál kezdődik, amiket riportolni akarunk. Eleve túl sok mező kell egy hibajegy leírásához: ID, title, description, environment, reported by, assigned to, priority, status, comments – és ez csak egy elméleti minimum. Nem fér el szépen se vízszintesen, se függőlegesen. És további problémák is felmerülnek majd, ha mégis Excelt akarsz használni:

• description: nehéz szép, formázott folyószöveget írni Excelben. El kell férjen a probléma alapvető bemutatása, az indoklás, hogy ez miért probléma, elvárt és aktuális eredmény, workaround – nem egy tipikus Excel cella tartalma
• attachments: ezt nem is tudod Excelben megoldani (vagy csak nagyon rondán)
• értesítések: minden teszt admin toolban beállítható, hogy a kiválasztott bugok körében minden változtatásról e-mail értesítést kapj. Bárki bármit matat: tudni fogsz róla. Excelben ez nincs, így észre sem veszed, ha valaki pl. az egyetértésed nélkül megváltoztatja a bugod prioritását (megtörtént) vagy lezárja a hibádat (megtörtént)
• kommentek: sok hasznos információt, kontextust nyújtanak a kollégák által beírt kommentek. Például: nálam is reprodukálható a hiba, másnál viszont nem, kell-e javítani egyáltalán és hogyan, lezártam ilyen és ilyen okból… Számtalan téma felmerülhet egy bug kapcsán, amit egy kommentfolyamban kényelmesen meg lehet beszélni – Excelben ez szintén lehetséges, de ronda lenne
• history: amiből látszik, hogy hogy milyen változtatások történtek a bugban, tipikusan: ki és miért módosította a prioritását és a státuszát. Excelben ez az információ elvész (vagy csak bonyolultan elérhető a SharePoint history-n keresztül)

A professzionális teszt adminisztrációs eszközök sok más hasznos funkciót is nyújtanak még: kapcsolatot a specifikációval, Jirával, automatizáló eszközzel, kényelmesen lekérhető riportokat, szabályozható felhasználói jogokat… De ezek nélkül még elkezdhető a tesztelés akár Excelben is – a hibajegyek kulturált kezelése viszont már nem.

A tesztelés hét alapelvéből az első: kimerítő tesztelés nem lehetséges. Ennek ellenére jaj, hányszor hallottam: ezt most nagyon alaposan teszteljétek le, és ha bármilyen hiba van benne, azt találjátok meg!

Nagyon vicces volt, hányféle szinonimát találtak a kollégák a „kimerítő” szóra:

• kívülről-belülről teszteljétek le
• teszteljétek szét
• tüzetesen fésüljétek át
• teszteljétek szénné

Elméletben persze érdekes eljátszani a gondolattal, hogy például egy adott szoftver modul kimerítő tesztelése mit jelentene:

• minden lehetséges input adatot (minden lehetséges ekvivalens input adatot),
• minden lehetséges futtatási opciót (összes gomb, összes menüpont, összes opció kipróbálása)
• minden lehetséges futás közbeni beavatkozási módot (gombok nyomogatása, egér kattintás, környezet módosítása)
• ezeket az összes lehetséges sorrendben
  • leírni
  • lefuttatni

Végtelen ideig tartana vagy végtelen erőforrást igénybe véve lehetne megvalósítani. Hétfőre kell? Nem probléma!

A valóságban pedig nyilván adott már az ún. regressziós teszt set, amit adott idő alatt le lehet futtatni. Hibákat találni pedig a kollégák tapasztalata, és az új fejlesztésekről megismert információk függvényében lehet. Szerintem a fejlesztő kollégák se örülnének, ha belátható időn belül minden hibát megtalálnánk…