Szakmai anyagok

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.

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.

Volt egy UPC reklám a tévében, amiben a betárcsázós internetet használó férfit úgy mutogatták turistáknak, mint egy ritka állatot. Egyik turista megkérdezi: – És mit eszik? – Ugyanazt, mint mi.

A tesztelők, amikor először bekerülnek egy csapatba, néha ugyanilyen furcsa szerzetek a már ott dolgozók számára. Azt hiszed, eltúlzom, pedig nem.

Történt, hogy a már másfél éve haladó projektbe megérkeztünk mi, tesztelők. Beültettek minket egy másik szobába, mint ahol a projekt dolgozott, és hetekig nem szólt hozzánk senki. A projektvezető egyszer bejött, bemutatkozott, és megkérdezte, minden rendben? Hát… persze. Aztán ő se szólt hozzánk hetekig. Halvány lila gőze nem volt senkinek, mit kéne velünk kezdeni, és nekünk se, hogy mihez kezdjünk.

Másik projekt, szintén előrehaladott fázisban, eljött az idő: be kéne vonni a tesztelőket. Behívtak minket egy meetingre, ismeretlen emberek, akik hadarva, érthetetlenül beszéltek valamiről, amiből egy szót se értettünk. Aztán kinyögték: hétfőtől kell elkezdeni a tesztelést. Minek a tesztelését?! Hol van ez a valami? Az nem baj, hogy hétfőn még egyébként tök mást fogok csinálni?

Egyébként nem ciki, ha fogalmad sincs, mi fán terem a tesztelés, csak legyél bátor bevallani. A következőket kell tenned:

1. Minél korábban vond be a csapatba a tesztelőt. Ne akkor mutatkozz be neki, amikor a fejlesztés már előállt és le kellene tesztelni. Hanem lehetőleg akkor, amikor a tervezés elkezdődik.
2. Eligazítás a projektben. Mi a projekt célja, melyek a fejlesztés főbb szempontjai, kik a résztvevők.
3. Domain oktatás: az e-mailben átdobott dokumentáció nem elég. A három napos beszállítói tanfolyam fontos, de szintén nem elegendő. Valaki üljön le vele személyesen és mutasson meg mindent, válaszoljon a kérdésekre. Pro tipp: minden régi munkatárs töltsön el egy napot az új kollégával, így rengeteg tudást, ötletet és ismeretséget szerezhet rövid idő alatt.
4. Hozzáférési jogok – egyáltalán nem nyilvánvaló, mennyi joga legyen egy tesztelőnek. Általában a rendszerszervezői, adminisztrátori szint alá szokták belőni, nehogy ezek a furcsa szerzetek valami komoly bajt okozzanak. Valójában azt kellene végiggondolni, hogy a tesztelő is felnőtt ember, van jogosítványa, gyereke, szavazójoga, felelős azért, amit csinál, és néha még az is kiderülhet, hogy kompetens a munkájában. Amennyivel kevesebb jogot adsz neki, annyival kevesebb témában számíthatsz a segítségére.
5. A tesztelendő részterület kijelölése. Erről szoktak megfeledkezni leginkább. A tesztelő nem fog mindent, az egész rendszert letesztelni. Ehhez a szoftver túl nagy, túl bonyolult, és egyébként is túl sokáig tartana. Meg kell találni azt a részterületet, ahol a tesztelő bevonása a leghasznosabb lehet. Ahol a legtöbb a tesztelendő kombináció, ahol a legtöbb a hiba, ahol a leginkább kell a segítség. Igaz, ezzel rögtön a nyakába is sóztad valakinek a tesztelőt: aki az adott részterületért addig felelős volt. Nem mindenki örül ennek egyformán… Úgyhogy időben fel kell tenni a kérdést:
6. Ki a felelős a tesztelésért? Egyáltalán nem egyértelmű, hogy a tesztelő, főleg, ha éppen beesett az utcáról az évek óta tartó projektbe, ahol a szakértők már régen benne vannak a mélyében. Ilyenkor sokat segít, ha valaki eldönti helyette: mikor van az adott terület letesztelve, mely tesztek lefutása lesz elegendő, vagy legalábbis kellően megnyugtató a szoftver minősége szempontjából.

És ez még csak a kezdet – hogyan kell jól együtt dolgozni egy tesztelővel hosszabb távon? Folytatása következik…

Egyébként ugyanazt esszük, mint ti… Tényleg!

Tegyük fel, adott egy tesztelőkből álló csapat, akiknek a munkáját értékelned kell. Nyilván van egy benyomásod arról, hogy valaki szorgalmas vagy lusta, okos vagy buta, együttműködő vagy problémás. Lehet dokumentálni, hogy ki hányszor késett el, hányszor szólalt meg meetingeken, hány alkalommal dolgozott késő estig stb. De mivel lehet számszerűen lemérni egy tesztelő munkáját?

Az első ötlet a lefuttatott tesztesetek száma. Ez az adat valóban nagyjából megmutatja, hogy ki mennyit dolgozott, de az összehasonlítás sokszor félrevezető, mert sok múlik azon, ki és hogyan írta meg a teszt scriptet. Egy adott problémakör vizsgálatát ugyanis le lehet bontani sok kis tesztesetre, vagy össze lehet foglalni néhány nagyobb lélegzetű tesztesetben is. A tesztesetek felől nézve: egy darab végrehajtása néha egyszerű, néhány kattintás (pl. login), máskor viszont előkészítéssel, futási idővel, értékeléssel járó bonyolult tevékenység (pl. tesztadat végigfuttatása a rendszeren). A végrehajtott tesztesetek darabszámát ettől függetlenül mindenképpen nézni kell, de az eredményeket félrevezető lehet közvetlenül összehasonlítani egymással.

Tapasztalatom szerint a megfelelő mérce a riportolt bugok száma. Mert bármilyen furcsa, egy darab bug megtalálásához szinte minden projektben, minden területen nagyjából ugyanannyi befektetett munka, figyelem és megértés szükséges. Aki több hibát talált, az többet dolgozott, figyelmesebb és jobban érti a szoftvert, mint aki kevesebbet.

Elméleti szempontból ez persze vitatható. Egy tesztelő bármikor kifoghatja a szoftver olyan területét, ahol csak úgy rajzanak a bugok, egy másik pedig olyat, ami stabilan, hibamentesen működik. A gyakorlat viszont azt mutatja, hogy nem a fejlesztők, hanem a fejlesztő csapatok között szokott minőségi különbség lenni – ezért egy adott csapaton belül mindenkinek kb. ugyanannyi esélye van hibát bugot találni.

Felmerül az a probléma is, hogy ha a tesztelők már tudják, hogy a riportolt bugok alapján fogod értékelni őket, elkezdenek feleslegesen sok, kamu hibát riportolni. Több bugot írnak be ugyanarról a jelenségről, vagy belekötnek az élő fába is, csak hogy több legyen a beírt hibajegy. Ilyenkor súlyozni kell a hibákat

• prioritás szerint (a vezetők által már felülvizsgált prioritást alapul véve)
• milyen arányban lettek ténylegesen kijavítva (Fixed vagy Not fixed státusszal zártuk le).

Volt már olyan értékelésem, ahol a vezetőm egy kollégámmal baráti viszonyban volt, engem viszont kevésbé kedvelt, és úgy gondolta, hogy a kolléga jobban is dolgozik nálam. Úgyhogy rámutattam, hogy az adott időszakban kétszer annyi bugot riportoltam, mint ő. De azok biztos kevésbé fontosak voltak! Hát, ahhoz képest pontosan ugyanolyan arányban javították ki őket, tehát nekem kétszer annyi kijavított bugom volt, mint neki… Becsületére legyen mondva: nem kaptam rosszabb értékelést, mint a kolléga (mondjuk jobbat se).

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