Szatmári Péter

– hangzik el a kérdés a projektvezetőtől. A tesztelő vagy a tesztelési vezető ilyenkor kalkulálni kezd: a teszteseteket addigra megírjuk, egy teszteset végrehajtása egy óra, száz teszteset van, ketten csinálják, legyen egy hét.

Az időkeretet a legtöbbször az tolja el, ha a tesztelést nem lehet időben elkezdeni, mert a fejlesztés nem készült el. Egyszer egy ismerős csapatban már elrendelték a túlórákat a tesztelőknek, hogy a nagyon fontos, nagyon sürgős projekt tesztelése időben elkészüljön – csak a fejlesztés nem készült el. Ezért a tesztelők este hétig bent unatkoztak az irodában – a túlóra már el volt rendelve és nem merték hazaengedni őket… Ez persze szélsőséges hiba volt, a főnökök többsége meg tud hozni egy ilyen döntést önállóan (hogy hazaengedje, aki nem csinál semmit).

Ami hibát viszont tényleg sokan elkövetnek: nem hagynak buffert a megtalált hibák javítására, és a javítások újbóli ellenőrzésére. Ez kommunikációs feladat is, ugyanis nem lehet előre tudni, mennyi idő kell majd rá. Előfordulhat, hogy

• minden rendben, és a tesztelés tényleg csak addig tart, amíg minden teszteset lefut,
• találtok néhány hibát, ilyenkor a fejlesztőknek is kell két nap a javításra, és még egy nap nektek a bug re-checkre,
• olyan hibákat találtok, amiket a fejlesztők belátható időn belül egyáltalán nem tudnak kijavítani.

A középső lehetőséget kell leírni a tervbe, az utolsót pedig világosan kommunikálni a projektvezető felé. Olyankor eszkaláció kell, túlóra kell, hétvégézés kell – legyen egy terv erre az esetre is, mert sem a hitetlenkedés, sem a pánikolás, sem a baszogatás nem fog segíteni.

Ha pedig az üzleti oldallal dolgozol, és rászánsz X napot az UAT-ra, egészen biztosan lesznek, akik az X-1. napon kezdik el a tesztelést. Nyilván nekik lesz a legtöbb problémájuk és ők találják meg  legtöbb hibát, amit az utolsó napon kell kapkodva javítani és újratesztelni. Ezért két terv fog kelleni: egy nyilvános és egy valódi. Ha X nap alatt akarsz letudni egy UAT-ot,

• X-3 napot írj a nyilvános tervbe és ezt is kommunikáld az üzlet felé, így lesz esélyed
• hibajavítással, újrateszteléssel, dokumentálással együtt X nap alatt tényleg befejezni.

Minden szervezetben adott, milyen sorrendben foglalkoznak a problémákkal a szakemberek. A döntéshozó eldönti, hogy belevágunk a projektbe. Az architekt tervez, a designer rajzol, a rendszerszervezők specifikálnak és felveszik a kapcsolatot a társterületekkel, a vezető fejlesztő megtervezi a fejlesztés menetét, a fejlesztők elkezdenek kódot írni, mindenki pörög ezerrel.

– A tesztelőkkel nem kéne beszélni valakinek? – kérdezi valaki.

– Hol van még a tesztelés… – érkezik a válasz.

A helyes megoldás persze az lenne, ha a tesztelők a teljes folyamatot végig kísérnék: bent ülnének a meetingeken, minden anyagot megkapnának, és elvárás lenne, hogy mindenről érdemben adjanak visszajelzést. Én tíz év alatt eddig egyszer tudtam elérni, hogy a specifikációt is tesztelhessük, ott Confluence-en, kommentekben jeleztük a hibákat, még mielőtt a fejlesztőknek elküldték volna – de ez egyedi eset maradt.

Tény, hogy a tesztelők csak azzal dolgoznak, ami valamilyen szinten már elkészült, de a tesztelők felelősek azért, hogy addigra viszont már felkészüljenek a témából. Ehhez szükséges:

• a kezdetektől figyelemmel kísérni, ami történik: beülni a meetingekre, figyelni, kérdezni,
• azonnal, érdemben megnézni mindent, ami elkészült: terveket, specifikációt, félig sem működő buildeket,
• megírni a test scripteket előre.

Tesztelőnek lenni relatíve kényelmes pozíció, hiszen nem vagyunk felelősek azért, hogy a dolog elkészüljön, sőt ami elkészült, azt is csak kritizálni kell, majd a mások által elkészített javítást is újra kritizálni. Az ehhez szükséges felkészültség és alaposság az, ami mégis a tesztelők felelőssége – a kritizálásnak is van saját minősége.

Az egyik cégnél, ahol dolgoztam, a helyi agilis módszertan előírta, hogy az agilis csapatokban mindennek lennie kell: üzlet, rendszerszervezők, tesztelők. Ez azért szükséges, hogy az adott szakmai részterület teljes egészében le legyen fedve az üzleti és technikai specifikációtól kezdve egészen a tesztelésig. Ahhoz, hogy egy nagy projektet véghez lehessen vinni, minden területre kell egy ilyen kis csapat, és akkor horizontálisan és vertikálisan is mindent lefedtünk (magát a fejlesztést külsős beszállító cég végezte).

Az elképzelés jó volt, de mint mindig, a hétköznapok szintjén nem ártott volna némi rugalmasság és odafigyelés. Például észre kellett volna venni, ha az elvileg egymás mellett működő csapatok silószerűen elkülönülnek, nem beszélnek egymással, sőt azzal töltik az időt, hogy a másik működését kritizálják. A tesztelőknél ez úgy csapódott le, hogy nálunk voltak a szakmailag magas szintű tesztelők, volt a két hülye, aki a másik csapatban tesztelt, a harmadik csapat meg kompletten nem csinált semmit.

A helyzetet bonyolította, hogy a fejlesztések üteme sem volt egyenletes: valamelyik területre több fejlesztés érkezett, a másikra kevesebb, így a tesztelési feladatok eloszlása is egyenetlen volt. Csináltam egy statisztikát arról, hogy egy negyedév alatt a három csapatban mennyi teszteset volt végrehajtva: nyolcszáz, kilenc és nulla.

A jó megoldás nyilván az lett volna, ha a tesztelőket nem silókban, hanem poolban képzeljük el, ahonnan egy QA Lead rugalmasan kiosztja őket a tesztelési feladatoknak megfelelően. Javasoltam is, hogy a tesztelő kollégát, aki három hónap alatt semennyit sem tesztelt, ideiglenesen helyezzük át oda, ahol másik két kolléga éppen beleszakadt a munkába.

De, amint felhívták a figyelmem

• az agilis módszertan előírja, hogy mindenhol kell legyen tesztelő
• a harmadik csapatból hogy adhatnák át az egyetlen tesztelőjüket, ha például fél év múlva elkezdenek megérkezni nekik is a fejlesztések?!
• én ott nem voltam QA Lead, az agilis módszertan szerint ilyen nincs is, törődjek a magam dolgával,
• a nyolcszáz és a kilenc teszteset közötti különbség pedig tökéletesen magyarázható (főleg egy olyan PO-nak, aki nem ért a teszteléshez).

Hat hónappal később…

• mégis rájöttek, hogy szükséges lenne az unatkozó kolléga ideiglenes átirányítása a másik csapatba,
• eddigre én már elhagytam a projektet
• a nyolcszáz tesztesetet végrehajtó két kollégából
  • egy felmondott,
  • a másik vidékre költözött, és hogy ne mondjon fel, egyedi felmentést kapott a céges home office szabályok alól. Onnantól kb. sose kellett bemennie az irodába – és sose kellett találkoznia azzal, aki korábban lehülyézte…

Annak a kollégának volt igaza, aki ebbe a projektbe már eleve be se szállt, mert tudta, hogy mire számítson – de az ilyesmit nem mindig lehet előre látni.

Amikor egy cég átáll az agilis módszertan szerinti működésre, mindig a komplett cégre vonatkozóan találnak ki szabályokat, amelyeket mindenkinek be kell tartania. Ritkán van rá lehetőség, hogy azokat adott projektre, csapatra lehessen igazítani. Az egyik ilyen általános agilis szabály, hogy az elkészült fejlesztéseket még az adott sprintben le is kell tesztelni – így lesz az elkészült fejlesztés teljes értékű a végfelhasználók számára.

Történt mégis, hogy amikor tesztelőként csatlakoztunk egy szoftverfejlesztőkből álló csapathoz, ők már régen beálltak a kéthetes sprintekre. Több éves tapasztalatuk volt arról, mennyi fejlesztés fér bele két hétbe – a tesztelők meg dolgozzanak, amikor akarnak, a végfelhasználók felé úgyis csak félévente, évente adtunk ki új verziókat (nesze neked agilitás).

Semmi gond, mi tesztelők rugalmasan beálltunk egy követő stratégiára, amikor az adott sprintben mindig azt teszteltük le, amit a fejlesztők az előző sprintben alkottak. Tegyük hozzá: részletesen dokumentált és rendszeresen demózott fejlesztésekről beszélünk – könnyen le tudtuk követni, hogy mi történik.

Módszertanilag nyilván vitatható, de a valóságban ez a követő stratégia nagyon jól működött. Ugyanis, ha a tesztelést mindenáron be akarjuk nyomorítani az azonos sprintekbe:

• az addigi tapasztalatok (mennyi fejlesztés fér bele egy sprintbe) elvesznek, de legalábbis lényegesen módosítani kell a tervezésen
• a fejlesztési vezetőnek a tesztelőket is felügyelnie kell („befejeztétek már?!”), és ez egyikünknek se hiányzott.

Úgyhogy a cégben kötelező agilitást a végfelhasználók érdekeit nem csorbítva, rugalmasan a csapat igényeire szabtuk. Igaz, ezt főleg azért tehettük meg, mert a fejlesztő csapat már régóta dolgozott az egyik külföldi központnak, és amíg jó munkát végeztek, addig se innen, se onnan nem szóltak bele olyan profán kérdésekbe, mint a munkaidő, a home office vagy az agilis módszertan precíz alkalmazása…

Új build, új fejlesztés érkezik. Telepíted, használni kezded, de már az elején furcsán viselkedik. Aztán újabb és újabb hibákat fedezel fel. Szeretnél eljutni legalább egy alap funkció leteszteléséig, de annyi a hiba, a kavarás, akkora szar az egész, hogy legszívesebben hagynád a fenébe. Az ösztönös reakció, hogy ezt most vigyék vissza, javítsák ki, és majd szóljanak, ha lesz belőle használható verzió.

Az érzés valid. Nagyon rossz minőségben kiadott verziók voltak és lesznek is, természetes, hogy semmi kedved időt tölteni egy ilyennel.

A fenti ösztönös reakció (hogy vigyék vissza, javítsák ki, aztán majd szóljanak) azonban rossz, mert se vezetői szinten, se a fejlesztők nem tudnak mit kezdeni azzal, hogy „szar az egész”. Főleg, ha az a dolgod, hogy a minőségi problémákat higgadtan, tényekkel és részletekkel alátámasztva prezentáld.

Ezért a megoldás, hogy engedd el, mi mindent akartál letesztelni aznap. Helyette válassz ki 1 darab problémát, és csak arra koncentrálj. Riportold le úgy, mintha az az egy probléma lenne a builddel összesen. Higgadtan vizsgáld meg, reprodukáld többször, dokumentáld, küldd el. Aztán válassz egy következőt, azt is dolgozd ki a szokásos alapossággal, majd ebéd után egy harmadikat is.

Ha egy buildről egy nap alatt három súlyos hibát be tudsz írni, akkor már vezetői szinten is megszólal majd a csengő, hogy valami baj van. Másrészt a fejlesztők sem tudják az egész programot kijavítani, hanem csak konkrét problémákat, egyesével. Segíts nekik, hogy lássák, pontosan hány darab hiba van, van-e köztük esetleg összefüggés, milyen sorrendben kellene javítani őket.

„A tesztesetek írása teljesen felesleges. Aki dolgozik vele, úgyis érti, miről van szó. Az egész dokumentáció csak azért van, hogy mutassuk magunkat és bevédjük a seggünket. Könnyedén le tudnám tesztelni úgy is, ha egy szót se írnék le az egészből.”

Az egyik válasz, hogy bár te, itt és most talán érted, hogy miről van szó, egyáltalán nem biztos, hogy még akkor is itt leszel, amikor legközelebb ugyanezt tesztelni akarjuk.

De van egy ennél mélyebb oka is annak, hogy miért kell a teszteseteket, és általában mindenféle dokumentációt részletesen megírni. Ehhez magát a megírás folyamatát kell megérteni. Ahhoz, hogy írjál valamiről, alaposan ismerned kell az adott témát. Áttekinteni a nagy egészet, és érteni minden egyes lépést külön-külön is. Várhatóan a tesztesetek megírása közben jössz majd rá, mi nem világos még. Vezetői oldalról pedig a megírt tesztesetekből nagyon jól lehet látni, mennyire érted ezt a témát valójában.

Éppen ezért a QA leadek, és általában a menedzserek egyik legfontosabb feladata elérni, hogy a kollégák megfelelő minőségben dokumentálják a munkájukat. Esetünkben, hogy a tesztesetek részletesek, érthetőek, végrehajthatóak, újra felhasználhatóak legyenek. Nem azért kérik ezt, mert nemsokára ki akarnak rúgni, hanem hogy biztosak legyenek benne: te magad elég jó vagy már abban, amit tesztelni fogsz.

Nekünk egy időben úgy kellett megírni a test scripteket, hogy az évekkel később odaérkező, külföldi, angolul gyengén beszélő kollégák is azonnal végre tudják azokat hajtani. Ehhez minden egyes kattintást és billentyűleütést pontosan rögzíteni kellett – na azok voltak a jól megírt teszt scriptek. Rengeteget segített, amikor elsőként azok alapján jártam végig a szoftvert, mert a logika előzetes ismerete nélkül, önállóan tudtam dolgozni velük.

A koncepcionális hibákkal kapcsolatban tesztelőként sokszor tehetetlennek érzi magát az ember. Látod, hogy rossz már az elképzelés is, de nincs elég hatalmad, tekintélyed ahhoz, hogy megállítsd a rossz ötletek megvalósítását. Ilyenkor kár elkezdeni hisztizni. Tesztelőként az a dolgod, hogy

1. megtaláld a hibákat a szoftverben,
2. bug riportok formájában jelezd őket
3. ha döntés születik a javításról, nyújts hozzá segítséget.

A bug riport Description része az a hely, ahol elmondhatod a véleményed, ahol érvelhetsz, javaslatokat tehetsz és meggyőzheted a kollégáidat – persze ott is csak az adott hibával kapcsolatban. A QA Lead az, aki utána ezeket meetingeken képviseli, és szükség esetén a koncepcionális problémákat is felveti.

Két személyes sztori: az első alkalommal kisebb, de koncepcionális, az alapműködést érintő hiba volt a szoftverben, amit májusban riportoltam. Félretolták, ennek a javítása most nem aktuális. Októberben viszont a végfelhasználók is megtalálták ugyanezt a hibát… Részemről volt a káröröm, amikor rámutattam, hogy én ezt már fél éve beírtam…

A másik esetben egy egész projekt volt rosszul volt kitalálva, ugyanis nem volt specifikáció, eldöntötték, hogy nem lesz rá szükség. Elkezdődött a fejlesztés – botrányosan rossz buildekkel. Mi a QA-n felgyűrtük az ingujjat és elkezdtük beírni a hibákat. Három hónap alatt beírtunk százat. Nyilván botrány lett belőle, de a bugok helytálltak, a projektet pedig lefújták. Szerinted ez jó eredménynek számít tesztelőktől?

Az biztos, hogy ha jó szakember vagy, akkor az idő neked dolgozik. Ahogy megismered a szoftvert, egyre jobban tudsz érvelni már a bug riportokban is. Idővel a kollégáid is felismerik a jelzéseid jogosságát. Egy idő után behívnak majd a meetingekre és megkérdezik a véleményed közvetlenül. A döntéseket még akkor sem te hozod meg, de már jóval nagyobb befolyásod lesz rájuk.