Algero, Szardínia, Olaszország

Fehér homok, kék tenger, és a TikTokról ismert lesétálás a Maria Pia strandra – ezek voltak a kiinduló ötletek Algherohoz.

Grotta di Nettuno

Első nap délelőtt megnéztük Neptunusz barlangját. Nem indult jól a reggel: szakadt az eső, és a hajónkra beszabadult kétszáz nyugdíjas a város mellett állomásozó Sky Princess hajóról, alig tudtunk leülni a hajó alsó (fedett) részében hat öregasszony közé. De aztán kisütött a nap, felmentünk a felső szintre, ahol már bőven volt hely és csak néztük a csodás szardínai partokat.

Szardínai partjai, egy sziklafal a hajóról nézve

Maga a barlang pont ugyanolyan, mint az aggteleki, csak kisebb, a túra talán 45 percig tartott – aki 2 órásnak írja, nem tudom, mit csinált odabent annyi ideig… Érdekes, hogy az aggteleki barlangban szigorúan el vagy választva a cseppkövektől – az olasz verzióban viszont néha olyan szűk az út, hogy muszáj a falhoz érned. Máshol meg ki van írva, hogy ne nyúlj hozzá, mégse szól rá senki a falakat végigtapogató mamira…

Érdemes tudni, hogy barlang alig a tengerszint felett van, így se bolt, se büfé, se WC nincs, mert elmosná az ár – a hajóról kilépve csak egy pultot találunk, ahol belépőt kell venni, ennyi az infrastruktúra. 654 lépcsővel feljebb, a szikla tetején valószínűleg van minden, de mi ott nem jártunk.

Stanley Tucci

Ballagunk vissza a kikötőből a szálláshoz, jön szembe egy pasi, és Noémi böködni kezd, hogy nézd már, ő az a pasi, tudod. Én is rájöttem, hogy kire gondol, úgyhogy utánaszóltam:

– Elnézést, nem maga a híres színész a filmből…
– Nem, nem én vagyok
– Nahát, pedig mennyire hasonlít!

De szerintünk csak nem volt kedve a turistákhoz, akik a nevét se tudják. Úgyhogy ha legközelebb Algheroban szembejön veled a szemüveges fazon a Pradából, tudjad a nevét: Stanley Tucci.

Maria Pia

Délután elmentünk a strandra Instagram fotókat és videókat készíteni: séta befelé, pózolás a parton bikiniben… A víz hideg volt, de én be tudtam menni úszni is. A tenger nagyon lassan mélyül és kellemes homokos az alja.

 

A bejegyzés megtekintése az Instagramon

 

Szatmáriné Tóth Noémi (@toth.noemi86) által megosztott bejegyzés

Bicikli túra

Ez az én ötletem volt: párszor megkerültük már a Velencei-tavat kölcsönzött biciklivel és mindig élveztük, miért ne járnánk be ugyanígy Szardínia közeli részeit. A konkrét célunk az volt, hogy a Neptunusz barlanghoz menjünk vissza szárazföldön is, útba ejtve a szép, fehér homokos strandokat.

E-bike vagy hagyományos: a kölcsönző a drágább elektromosra akart rábeszélni, és végül hagytuk, mert az ismeretlen tájon hátha jól jön a rásegítés. És tényleg jól jött: amikor ~30 kilométer után rettenetesen fáj a segged, plusz fáj a vállad és a csuklód, leégett a könyököd és a térded, plusz kisebb napszúrást kaptál, határozottan segít, ha legalább maga a tekerés könnyű. Volt egy hosszú, meredek emelkedő, ahol egy hagyományos biciklit használó párost fütyürészve hagytunk le, csak néztem, ahogy szenvednek szegények…

Út közben megnéztünk két kisebb strandot (Fertilia, Punta Negra), két sziklás tengerpartot (Punta gel Gall, Spiaggetta del Rossa), aztán a Bombarde strandon kajáztunk, sőt megfürödtem a tengerben ott is. Aztán nekiindultunk a barlang felé vezető országútnak, de a hegyi szerpentin egy pontján, egy pihenőnél megbeszéltük, hogy sok lesz és visszafordultunk. Ezt láttuk a pihenőből:

Noémi nézi a tájat ott, ahol visszafordultunk

Tipp, ha biciklizni akarsz Algheroban és hozzánk hasonló amatőr vagy: a Bombarde strandot célozd meg, mert nagyon szép, ki van építve (homokos a part és van étterem, mosdó) és egészen Alghero kikötőjétől kezdve kiépített, jó minőségű kerékpárút vezet odáig (a Vicinale le Bombarde utcánál kell balra fordulni a tenger felé).

Éttermek

Vannak, akik egyik vagy másik éttermet ajánlják, de szerintünk mindegyik egyformán nagyon jó. A pincérek kedvesek, a pizza elképesztően finom, mindenhol lehet kártyával fizetni, és sehol se vernek át, bár volt, ahol az 5 eurós teríték valahogy a kisbetűs részbe került… 7-15 euró egy pizza, ami kettőnknek elég, plusz üdítő, pohár bor, kávé – kb. 25 euró, tízezer forint egy olasz tengerparti ebédért vagy vacsoráért…

Egy helyen megláttam ezt az ételt az étlapon: Penne all’ arabiata – nem tudtam, honnan ismerős. Aztán rájöttem: ez volt a menü a menzán, amikor Darth Vader kajálni ment. Én is ezt ettem: sajtos, paradicsomos penne, kicsit csípős, hét euró.

Info

  • Mindenhol tudtunk kártyával fizetni, készpénz nem is volt nálunk egyáltalán. Komolyabb strandolásnál a napernyőhöz (6 euró/nap), tusoláshoz (1 euró), utcai árusokhoz (sapi, hűtőmágnes, kulcstartó, esernyő…) kellhet készpénz.
  • Mindenki elképesztően kedves, és nem is tolakodóan.
  • Az autósok vigyáznak a gyalogosokra, a zebrákat – ha már leléptél – nagyon komolyan tiszteletben tartják.
  • Angolul alig beszél valaki, turistás helyen fura.
  • Mindenhol szól a zene: a boltokban és az éttermekben, olasz slágerek és reggaeton, az utcazenész Ciao Bellát és Azzurrot énekelt… Nagyon-nagyon szomorú voltam, hogy innen haza kellett jönni…

Pálmafa a naplementében az algheroi tengerparton

Mennyi idő alatt lesz kész a tesztelés?

– 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.

Zsófi sérülése és ahogy manuál terapeuta kezelte

Még április elején Zsófi lesérült egy edzésen: akrobatika végén a padló helyett a társa lábára érkezett és onnan kiment a bokája. Az akrobatikus rock and roll veszélyes sportág, az ilyen sérüléseket sajnos nem lehet kizárni. Mire hazaért, bedagadt a bokája, úgyhogy Heim Pál, röntgen: részleges szalagszakadás, 6 hétig bokafix, ne mozgassa, jegelje, aztán majd meglátjuk. Másnap vettünk bokafixet, és hogy tudjon a lábát kímélve közlekedni, kaptunk kölcsön két mankót.

Egy mankózó kislányt mindenki megsajnál, és az egyik szomszéd nagyon kedvesen adott egy tippet, egy manuál terapeuta számát. Amint a ChatGPT elmagyarázta, a manuál terapeuta egy továbbképzett gyógytornász, aki nem csak gyakorlatokat ír elő, hanem maga is aktívan kezeli az érintett testrészt. Kaptunk időpontot, elmentünk hozzá.

Kiderült, hogy a doki néni egy fiatal lány, maga is rockyzott régebben és pont a hasonló sérülések miatt választotta ezt a szakirányt. A kezelés alapvetően nyomkodást jelentett, gyakorlatilag visszanyomkodta a sérült szalagot a helyére, meg az egész lábában átgyúrta az izmokat. Viszont tök más utasításokat adott: igenis mozgassa a lábát, álljon rá, sétáljon. A mankót, a bokafixet és a jegelést pedig felejtsük el! Pont az a cél, hogy az izmok újratanulják a korábbi működést, a keringését pedig ne akadályozza semmi…

Tény, hogy Zsófi mankóval ment be a rendelőbe és a saját lábán sétált ki onnan. De azért imádjuk, amikor a szakemberek egymást hülyézik, miközben a felelősség a miénk. Főleg, hogy másnapra tiszta kék volt Zsófi lába, a térdétől a lábujjakig tele véraláfutással…

De fájni nem fájt neki, járni tudott, iskolába is. A kék foltok pedig lassan múlni kezdtek… Visszamentünk még egy kezelésre, újabb gyúrás, újabb kék foltok, újabb előírt gyakorlatok…

Most a sérülése utáni negyedik hétben vagyunk: ha azt csináljuk, amit a Heim Pálban mondtak, még hordaná a bokafixet, még jegelnénk, még nem lenne szabad mozgatni. Ehhez képest jelenleg semmilyen panasza nincs, se folt, se fájdalom. Pénteken együtt felmásztunk az Oszoly sziklához, szombaton táncos rendezvényen volt a barátnőjével, hétfőn pedig újra edzeni kezdett (ha nem is teljes értékűen, az akrobatikával még óvatosak).

A tanulság: a Heim Pál ügyelete nagyon fontos hely, életmentő lehet, hogy a gyerekedet időben lássa orvos. De utána, ha időben és anyagilag belefér, érdemes szétnézni, ki foglalkozik még hasonló problémával, és elvinni magánrendelésre is…

A tesztelők az utolsók a sorban

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 tesztelő csak unatkozik, miközben a projekt már pörög

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.

Rossz példa az agilitásra: silók

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.

Jó példa az agilis módszertan csapatra szabására

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…

Amikor szar az egész

Ú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.

 

Miért kell részletesen megírni a teszteseteket?

„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.

Látod, hogy gáz van, de csak egy tesztelő vagy

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.

Barack Obama: I told you so - én megmondtam...

Hogyan kell hosszabb távon együtt dolgozni egy tesztelővel

Tehát megérkezett a tesztelő, és tegyük fel, hogy az előző bejegyzésben (Mit eszik egy tesztelő?) felsorolt problémákat sikerült tisztázni: időben vagyunk, sikerült a betanítás, megvannak a hozzáférési jogok, kijelöltétek a tesztelendő részterületet és hogy ki a felelős a tesztelésért. Hogyan tovább?

A tesztelendő részterület kijelölésével egyben kijelölted azt a kollégát is, aki a tesztelőért felelős lesz. Ahogy említettem, nem mindenki örül ennek egyformán. „Nekem erre nincs időm, hogy még egy tesztelő munkáját is felügyeljem!” „Egyszerűbb, ha én magam megcsinálom!” Ráadásul nem mindenki szereti megosztani a tudását másokkal, mert félti az állását, nem akarja, hogy más is értsen ahhoz, amit csinál.

Függetlenül attól, hogy ezek a kifogások mennyire reálisak, a következményeket a tesztelő fogja elszenvedni. Még a jobbik eset, ha a kifogás ki van mondva, fel van vállalva, a rosszabbik esetben az információs vákuumban dolgozó tesztelőre egy idő után ráfogják, hogy a képességei rosszak vagy a hozzáállása. Nem érdemes senkire ráerőltetni egy tesztelőt, aki ezt nem akarja.

Mitévő légy, ha fejlesztő/rendszerszervező/BA vagy és melléd adnak egy tesztelőt?

A jó tesztelő valójában olyan, mint egy ló, amelyik húzza a szekeredet, vagy a segéd, aki a kezed alá dolgozik. A te embered, aki segít neked. Annál jobb neked, minél többet tud segíteni. Mondj el neki mindent arról, hogy mit szeretnél elérni, ossz meg vele minden tudást, minden trükköt és taktikát.

Felmerül majd a kérdés: ki írja meg a teszteseteket? A te szempontodból logikusnak tűnhet saját kezűleg előírni a tesztelő számára, hogy mit kell csinálni. Valójában azonban sokkal jobb, ha a teszteseket maga a tesztelő írja meg, és te csak ellenőrzöd az eredményt. Ugyanis a megírás minőségéből meg lehet állapítani, hogy a tesztelő kolléga megértette-e a feladatot, megértette-e a szoftver működését és hogy minden fontos eset sorra fog-e kerülni.

Ezután a tesztelő érdemben tesztelni kezd: ellenőrzi, hogy az elképzeléseid beváltak-e, vagyis a szoftver a specifikációnak megfelelően működik. Lepörgeti a variációkat, ami neked csak egy púp a hátadon. Megtalálja a hibákat a specifikációban csakúgy, mint a kész szoftverben. Érvel, kommentál, ellenőriz és adminisztrál – jó esetben érezni fogod, mennyi problémát levesz a válladról.

Vezetői szempontból a közös munka eredményességének sok jele van: az együtt töltött idő, ki riportolja a bugokat, de az egyik legérdekesebb indikátor, hogy a fejlesztő/szervező/BA szabadsága alatt kijavított bugokat a tesztelő újratesztelheti és pozitív esetben önállóan lezárhatja-e – vagy mindennel meg kell várni a nagyobb tudású kollégát, aki nem bízza a tesztelőre a tesztelést, saját kezűleg is ellenőrizni akar mindent.

Eddigi pályafutásom egyik legérdekesebb időszaka volt, amikor a rendszerszervező – tesztelő együttműködésből jó és rossz példák sokaságát láttam közvetlenül egymás mellett. Az egyik végletben volt a feszültség, a hibáztatás, végül a tesztelő kolléga felmondása. A másik végletben voltak az összedugott fejek, a kivételes minőségű felkészítés, a teljes körű helyettesítés szabadság alatt – majd amikor a rendszerszervező kolléga felmondott, a tesztelőt előléptették a helyére, rendszerszervezőnek.