Hogyan légy sikeres tesztelő, ha a csapatod DevOps-ra áll át

Szerencsésnek mondhatom magam, hogy a hosszú karrierem alatt mindig olyan cégeknél dolgoztam, ahol szabadon kommunikálhattam és működhettem együtt bármely más pozícióban lévő emberekkel, még akkor is, ha más csapatokban voltak.

Az első programozási feladatomnál összebarátkoztam a gépszobában lévő operátorokkal. Ők voltak azok, akik futtatták a mi kódjainkat és karbantartották a gyártósorokat. JCL és JES2  parancsokat írtunk és elmondtuk nekik, hogy mit kell tenniük.

Jelölőnyelvet használtunk a nyomtatványaink formátumának kialakításához a Xerox Star nyomtatónál. De egy barátságos operátor lehet, hogy az én munkámat kiemelten fogja kezelni! És segítettek a tudásom bővítésében is a különböző szkripteléseknél és a jelölőnyelv használatát illetően is. Könnyebbé tettük egymás életét azzal, hogy együtt dolgoztunk.

Ugyanígy, bár a rendszerünk adminisztrátorai messze lent voltak a pincében a kezelőkkel együtt, barátságosak és mindig segítőkészek voltak a folyamataink kisimításában.

Talán mert egy ilyen jól összedolgozó közegben kezdtem (az ügyfeleinkkel is egymás mellett dolgoztunk!), de ezt a megközelítést a későbbiekben is használtam olyan csapatok esetén is, amelyek vízesés modellben dolgoztak.

Aztán jött az agilis módszertan, amely nekem egy természetes közeg volt, bár szükség volt a mindset-em alakítására (erről később bővebben!). Most pedig a DevOps kinőtt az olyan agilis cégekből, melyek valahogy lemaradtak arról, hogy a kezelő személyzetnek is az agilis delivery csapat részének kellene lenniük.

Tesztelőként hogyan birkózunk meg a folyamatos szállítással, folyamatos teszteléssel, gyártás közbeni teszteléssel?

Változtasd meg a mindset-ed

Mint az agilis esetén is, a DevOps is bevált gyakorlatok összessége, de emellett kultúra is, ahol a minőség van a középpontban.

Azzal, hogy folyamatosan kisebb változtatásokat engedünk be a gyártásba, alacsonyan tartjuk a kockázatot és elkerüljük azt, hogy az ügyfélnek esetlegesen kárt okozzunk. Azzal, hogy monitorozzuk, megfigyeljük, és analitikus technológiát használunk, hogy „gyártás közben tesztelünk”, egy plusz biztonsági hálót képezünk, hogy megakadályozzuk a rendszer esetlegesen váratlan működését.

Emellett ott van még az a dilemma is, hogy hogyan is végezzünk el olyan manuális tesztelési tevékenységeket, mint pl. a felderítő tesztelés, ha hetente, naponta vagy még gyakrabban kerül ki a kód a gyártásba. Tesztelőként egy nagy „mindset” átállítást kell végeznünk. Nincs idő bug-okat keresni azután, hogy a kód kiment a gyártásba. Addig kell a hibákat megelőzni, míg a fejlesztés nem végez a kód megírásával.

Ez azt jelenti, hogy a tesztelést akkor kell kezdenünk, amikor az új feature ötlete először megbeszélésre kerül egészen a lefejlesztésen keresztül. Ez azt is jelenti, hogy a tesztelési tudásunkat át kell adnunk olyan csapattagoknak is, akik még nem rendelkeznek vele. A saját csapataim csak úgy tudták sikerre vinni a folyamatos szállítást, hogy mindenki tesztelt minden lehetséges időben.

Például elősegítettem felderítő tesztelési workshop-ok létrejöttét a fejlesztők számára, majd én is csatlakoztam hozzájuk, hogy új technikákat tanulhassak. Ezután már tudták felderítő tesztelni az egyes felhasználói eseteket, ahogy leprogramozták őket.

Nem kizárólag a tesztelők sajátossága a minőségért felelni – az egész csapat felelősséggel tartozik érte.

A kapcsolatok felépítése – kérj segítséget

A tesztelőknek rengeteg új képességet kell elsajátítania abban a csapatban, mely DevOps-ra vált.

Bár az ötlet, hogy a kódot úgy alakítsuk át, hogy logolja a gyártás során történő változtatásokat, nem új, de a technológia, mely ezt lehetővé teszi igen sokat fejlődött. Rendelkezésünkre állnak eszközök, melyek segítségével mindent logolhatunk, és aztán felhasználhatjuk ezeket az adatokat, hogy megtudjuk, a felhasználók hogyan használják a termékünket és úgy működik-e a program, ahogy szeretnénk.

Meg kell tanulnunk ezeket az eszközöket használni. Őszintén, számomra ez igen csak félelemkeltő. Gondoljunk viszont arra, hogy egy csapat vagyunk, ugyanaz a célunk – egy nagyszerű terméket szállítunk, mely az ügyfél igényeinek megfelelő. Úgyhogy ne félj segítséget kérni.

Katrina Clokie is hangsúlyozza a könyvében (A Practical Guide to Testing in DevOps) annak a fontosságát, hogy hidakat építsünk más emberek és csapatok felé. Szükségünk van kapcsolatokra a műveleti, az adatbázisok, a gyártási és a design területek szakértőivel, ügyfélszolgálattal és így tovább.

Nagyszerű módja a barátságok megkötésének és egyúttal a tudásod növelésének is, ha más területek tapasztalataival rendelkező emberek segítségét kéred abban, hogy megtudd, hogyan végzik a feladataikat. Invitáld a konfigurációs szakértőt, hogy jöjjön és magyarázza el a kitelepítési pipeline-ok működését a csapatodnak vagy a kvázi tesztelői csapatnak. Kérj meg egy fejlesztőt, hogy odaülhess hozzá és mutassa meg, hogyan logolnak kódolásnál. Hívj meg mindenkit egy workshop-ra, ahol tanulhattok a felfedező tesztelésről és hozz sütiket vagy különleges sajtokat!

Sok bátorság kell a segítség kéréshez, különösen, ha olyan emberekkel kell együtt dolgoznod, akiket nem ismersz korábbról. De a teszteléshez is sok bátorság kell, úgyhogy megvan benned minden, ami ehhez kell!

Osztozz a fájdalmon, tedd a tesztelési problémákat a csapat problémájává

Íme egy helyzet, amit túl gyakran szoktam látni: A menedzserek azt mondják: „OK, mostantól DevOps-ban fogunk dolgozni”, mindenkit beosztanak multifunkcionális csapatokba, aztán várják, hogy a csoda megtörténjen.

Ha tesztelő vagy, aki manuális regressziós tesztelésben ragadt és lehetetlennek találod, hogy elég gyorsan haladj a teszteléssel még azelőtt, hogy az új fejlesztések kikerülnének az éles környezetbe, kérlek, ne szenvedj csendesen.

Bármilyen problémád is van, tedd azt a csapat problémájává.

Remélem, hogy a csapatod gyakran tart retrospektív megbeszéléseket, és használja is ezeket kisebb fejlődések elérésére. Ez egy nagyszerű lehetőség arra, hogy mindenki együtt legyen és feltedd a kérdést, hogy a minőség milyen szintjét szeretné a csapat szállítani.

Mindenki jó minőséget szeretne, nemde? Akkor hozd fel nekik, hogy mi áll az útjában annak, hogy a csapat magabiztosan engedje be az apró újításokat a gyártásba.

Kérd meg őket, hogy segítsenek beazonosítani a legnagyobb problémát és némi brainstorming is segíthet a megoldás megtalálásában. Formálj egy feltevést, találjátok ki, hogy hogyan mérjétek a haladásotokat. „Úgy gondoljuk, hogy ha egy tesztelő egy fejlesztővel párba áll ás 30 percnyi időt felfedező tesztelésre szentelnek, akkor minden user story esetében, nagyjából 20%-nyi esés várható a hibák számában, amiket azután találnánk meg, hogy a user story le lett fejlesztve és kikerült az éles környezetbe.”

Ha a kísérlet nem működött, próbáljatok ki valami mást – ez mind tanulságként szolgál és ez mind haladás.

Kérj meg mindenkit, hogy ossza meg a manuális regressziós tesztelés nehézségét – ez nagy motivációként szolgálhat a fejlesztőknek, hogy még tesztelhetőbb kódokat írjanak a jövőben. Ha a fejlesztők felelőssége az automata regressziós tesztek megírása és karbantartása, miközben a tesztelők segítenek nekik az egyes tesztesetek specifikálásával, a csapat nagy valószínűséggel jobban fog teljesíteni egy folytatólagos környezetben. És figyeljetek oda a lecsökkenő számú pontokra, ahonnan már nincs visszaút.

A legutóbbi csapatomnak több ezer automata regressziós tesztje volt, de emellett továbbra is volt egy ellenőrző lista azokról a tesztekről, amelyeket nem lehetett automatizálni. Hogy átnézzük őket heti 2 alkalmas bemásolások mellett nem hagyott elég időt a felderítő tesztelésre – és komoly hibák kerültek ki emiatt a gyártásba.

Ezért egyszerűen abbahagytuk ennek a kis számú manuális tesztnek a megnézését és azon dolgoztunk, hogy gyorsan be tudjunk azonosítani és ki tudjunk javítani problémákat, amelyek kikerülnek a gyártásba.

Legyen a minőség és a tesztelés átlátható

A minőség láthatóvá tétele egy nagy kihívás. Hogyan is mérjük?

A delivery csapatod segíthet minőségi célok felállításában és olyan metrikák megtalálásában, melyek mutatják hogyan haladtok ezen célok felé.

Kérj az ügyfél supportjától és a sales területtől ügyfél elégedettségi mutatókat. Tedd ezeket a metrikákat láthatóvá.

Itt egy példa. A csapat hibás automata teszt készletekkel küzd, és az egyik probléma, hogy néhány teszt „pihés”, szórványosan megbuknak úgy is, hogy nincs hiba a kódban. Rengeteg időd elmegy azzal, hogy megvizsgálod a bukásokat, hogy lásd, hogy tényleg regresszióról van szó, vagy csak a teszttel magával van valami gond.

Tedd a bukások gyakoriságát láthatóvá egy nagy monitoron. Határozz meg egy célt és idő büdzsét arra, hogy kijavítsátok vagy kitöröljetek néhány „pihés” tesztet heti rendszerességgel. Ha a bukások gyakorisága nem megy lejjebb, gondolj egy új kísérletre, ami működhetne még.

Az előző csapatomnak volt egy két-hetente megtartott „oszd meg és meséld el” meetingje, ahol minden kisebb csapat vagy csoport kapott egy pár percet, hogy megmutassa min dolgoztak. Ez egy nagyszerű lehetőség arra, hogy mindenki láthassa, ha van egy új technikájuk, amivel dolgoznak, például egy keretrendszerük, amiben vezetik a megbeszélt dolgokat az egyes user story-kon való munka megkezdése előtt.

Bármilyen nagy probléma is fenyegeti a sikeres folyamatos szállítást, tedd azt láthatóvá egy nagy fali monitorral vagy táblázattal, vagy ezek virtuális megfelelőivel. Néhány csapatom rászokott, hogy villogó rendőrségi lámpát használ, hogy lássuk, ha egy buildelés sikertelen vagy gyártási problémákba ütközünk, így téve ezeket látványossá és mentek biztosra azzal, hogy a hibát észrevegyék és kijavításra kerüljön.

Brainstorming-oljatok együtt, hogy kitaláljátok, hogyan tehetnétek a problémákat és a sikereket láthatóvá! Ünnepeljétek meg az összes sikert, amit arattok, nem számít mennyire is legyen az kicsi.

Használd az online anyagokat, találj kollégákat a tanuláshoz

Nagyon szerencsések vagyunk manapság, hogy sok különböző lehetőségünk van tanulásra: online kurzusok és szemináriumok, amik gyakran ingyenesek, cikkek és blog posztok, találkozók és konferenciák, online közösségek, mint pl. a Slack munkafelületein találhatóak.

Valóságos információs vagyon létezik a DevOps-ról, folyamatos szállításról és kitelepítésről, tesztautomatizálásról, loggolásról, monitorozásról, megfigyelésekről és így tovább.

Ha menedzser vagy, biztosíts elég időt a csapatod tagjainak a tanulásra. Napi egy óra tanulási idő sokat emelhet a csapat értékén a jövőben. Ez egy befektetés.

Ha a lehetőségeid megengedik, hogy tanulhass munkaidőn kívül, az sokféleképpen segíthet a jövőben.

Erősíts rá a tanulásodra azáltal, hogy szerzel egy-két barátot, akik veled tanulnak. Ilyen módon, ha elakadsz, a tanuló partnered lehet, hogy segíthet, hogy tovább haladhass. És egyébként is jobb móka együtt tanulni.

A technológia rohamtempóval fog fejlődni tovább. Nem tudunk lépést tartani vele, de találhatunk olyan területeket, amiket szeretünk vagy örömmel végzünk és ez segít a tanulásban. Ez téged is sikeressé fog tenni, dönts bárhogyan is a továbbiakról!

Forrás: https://qablog.practitest.com/succeed-as-tester-devops-team/