TESZTELÉS A GYAKORLATBAN – A SZAKÉRTŐ TESZTELŐK LAPJA TESZT MANAGEMENT á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 DevOpsra 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 DevOps4) 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 DevOpsban 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, hogymindenki 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 nemmű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égeaz automata regressziós tesztek 7 . oldal „Tedd, amit tudsz, ott, ahol vagy, azzal, amid van, és a többivel ne törődj!” - Theodore Roosevelt „Az ember akkor ember, ha az összes választási lehetőség közül a legnehezebbet választja.” – Bolyai János „Két módon lehet feljutni egy tölgyfa csúcsára. Az egyik, hogy felmászol rá. A másik, hogy ráülsz egy makkra és vársz.” - Kemmons Wilson „Erőt, bátorságot és önbizalmat nyersz minden olyan alkalommal, amikor valóban megállsz, hogy a félelem arcába nézz - ehhez azonban olyat kell tenned, amit úgy vélsz, nem vagy képes megtenni.” - Franklin Delano Roosevelt „Figyelj oda az ellenségeidre, mert ők veszik észre először a hibáidat!” - Antiszthenész
RkJQdWJsaXNoZXIy MTEyMzcyNw==