Mit is tesztelünk?

9:00
 
Megosztás
 

Manage episode 275430995 series 2708158
A sorozat szerzője: Krisztián Papp, akit a Player FM és a Player FM-közösség fedezett fel. A szerzői jogok tulajdonosa a kiadó, nem a Player FM, és a hangfájlt a kiadó osztja meg közvetlenül a saját szerveréről. A frissítések nyomonkövetéséhez koppints a Feliratkozás gombra, vagy másold be a feed URL-t egy másik podcast-appra.

Sziasztok, az én nevem Papp Krisztián és ez pedig a minicube podcast 12. epizódja.


Ma egy kicsit a manuális tesztelőkről fogunk beszélni, illetve arról, hogy mikor és mit nyomkodnak éppen és miként lehet tönkretenni a munkájukat egy tollvonással. Hogy szemléltessem, vegyük például Bélát, aki manuális tesztelőként dolgozik egy nagynevű multinál. A csapatában és az egész projekten úgynevezett SCRUM szerint dolgoznak, ami a valóságban inkább egy egy mini waterfallnak felel meg, de ebbe most ne menjünk bele. Maradjunk annyiban, hogy próbálnak kéthetente releaselni egy új verziót.

Ezeket a releaseket sikerül is tartaniuk, ami a mai világban - ahol egyesek percenként, mások meg évente releaselnek - ez még igen jónak számít. Minden ilyen iteráció hétfőn kezdődik és a következő hét péntekig tart. Béla két hete úgy néz ki, hogy eldöntik mik is férnek bele ebbe a két hétbe, a fejlesztők elkezdenek rajta dolgozni, a tesztelők is elkezdik összerakni a teszt planeket, amik leírják hogy miként lehet letesztelni az adott új featuret. Közben persze a product oldalt és fejlesztőket is folyamatosan nyaggatják, hiszen mindig lehetnek fekete foltok a feladatokban.

Az egyes featureök külön branchen kerülnek fejlesztésre, a fejlesztők pedig amit tudnak automatizáltan tesztelnek, de közel sem end-to-end. Ha valami kész van, akkor megy be master branchre, ez pedig kikerül egy tesztkörnyezetbe, lehet is nyomkodni a tervek alapján.

Ekkorra általában a két hétből már egy eltelt, így a tesztelőknek van egy hetük letesztelni ezt. Hogy biztos legyen elég idő, a második hét keddi napja az utolsó, hogy kód bekerülhet a masterbe, ekkor kezdődik az úgynevezett feature freeze.

Ez tök jó, de Béla nem ma kezdte, szóval kedden délelőtt talál valami turpisságot, amiről kiderül, hogy biza egy bug, mégpedig nem is kicsi. Ez így nem mehet ki, meg kell javítani. Meg is kapja a fejlesztő a nemes feladatot, hogy javítsa meg, de vészesen szorít az idő, ráadásul a feature freeze már életben van.

Sebaj, mert a feature freeze nem érvényes a hibajavításokra, arra ott van a code freeze, ami szerdán van. A fejlesztő megtolja az igát rendesen, be is kerül a javítás masterbe, el lehet kezdeni tesztelni. Ezúttal szerencséje volt, Béla se talál kivetnivalót a featureben, így pénteken terv szerint kimegy a release, amiben már benne van a hibajavítás is.

Aztán vasárnap csörög a telefon valakinél, ugyanis nagy baj van, mert a korábbinál még nagyobb hiba került a rendszerbe. Hát mégis hogy lehet ez? Hiszen a többi csapat tesztelői is tesztelték az alkalmazást.

Igen ám, de melyik verziónak és mely részét tesztelték éppen? Ugyanis amit a hét elején teszteltek, az nem ugyanaz volt, mint kedden, vagy a fejlesztőnk módosításai után, hiába halasztják a regressziót a végére.

Mit kellett volna tenni? Halasztani a releaset? Hát azt nem szeretik a menedzserek.

Esetleg tesztelni külön feature branchen? A feature brancheket kirakni külön teszt környezetekbe és ott le lehet tesztelni. Működhet, de mi a garancia, hogy a módosítások nem akadnak össze valaki máséval a masteren és nem okoznak valami galibát? Sőt, ha már galiba, leteszteli a feature branchen a Béla, rámondja az áment. Frankó, mergeljük be… de valaki megelőzött és most rá kell húzzam a mastert. Ha nincs conflict, az még a jobbik eset, de ha van akkor végképp más szoftvert fogunk kireleaselni, mint amire Bélánk áldását adta.

Megvan, revertáljuk a commitokat! Működhet, csak akkor megint visszajutunk oda, hogy a revert mit okozhat? Mikor fog ez kiderülni? Ugyanez a helyzet azzal, hogy cherry pickelgetünk.

Feature flagek! Ez lesz a megoldás, ugye? Már majdnem jó, de csak bizonyos esetekben működhet, mikor egy teljesen új funkcionalitást tudunk vele ki/be kapcsolni, hiszen ha valami korábbi logikában valami kapcsoló, akkor a kikapcsolt állapot is rejthet meglepetéseket.

Toljuk el a releaset pár nappal, ez még belefér, nem? Na igen, húzzák a szájukat a menedzserek, de ha nem létkérdés, talán benne vannak. Cserébe felborul a rend és ki tudja hány ember számára rövidül meg ez a két hetes periódus. A keddi feature freezeből szerdát akarnak a fejlesztők, a tesztelők pedig inkább hétfőt, hiszen nekik még az elcsúszott release után kell feltakarítani.

Ráadásul minden külső függőség újabb csúszás forrása lehet. Tegyük fel, hogy egy másik csapat, aki egy olyan szolgáltatást fejleszt, amit mi használnánk az új featureben nem készül el időre és a projektmenedzser közli, hogy ezt meg ezt ki kéne venni a releaseből. Éééés bumm, kezdődik az egész előlről.

Arról nem is beszélve, hogy ahogy hízik az alkalmazás és egyre több funkcionalitás kerül bele, a regressziós tesztelés ideje egyre csak nő és nő. Persze felvehetünk még több tesztelőt, de akkor mit fognak csinálni a hét elején? Mert amit akkor nyomkodnának már nem lesz ugyanaz, mint ami pénteken kikerül, akkor pedig mit is teszteltek?

De most komolyan nincs erre megoldás? Dehogynem, csak ahhoz bizony a manuális tesztelés kevés. A tesztelőknek is automatizálniuk kell, legalább részben, hiszen amíg a regresszió is kézzel zajlik, addig bármikor bármi történhet az ilyen-olyan csúszások miatt, hiszen emberek vagyunk.

Na de hogy és mit fognak ők automatizálni? Pontosan azt, amit eddig is csináltak, a felület nyomkodását, legyen az valami desktop alkalmazás, weboldal, vagy épp mobilapp. Ráadásul, ha a tesztesetek megfelelően voltak dokumentálva, akkor igen gyorsan össze lehet ezeket rakni, hogy aztán bármikor el lehessen indítani egy folyamatot, ami odanavigál az oldalra, végrehajtja ugyanazt, mint amit a tesztelő tett volna és megvizsgálja, hogy valóban azt látja-e, mint amit kellene.

Weben erre való a selenium, amivel a böngészőt tudjuk irányítani. Ha akarjuk futtathatjuk ezt a saját gépünkön, vagy egy úgynevezett headless böngészőben valami szerveren, az eredmény ugyanaz lesz. Ha nemigen van javascript a frontenden, akkor még lehet selenium sem kell, hanem az adott keretrendszer - amiben az oldal íródott - is biztosíthat ere eszközöket, amikkel a űrlapokat tudunk elküldeni és aztán a HTTP választ vagy éppen a HTML-t vizsgálni.

Ehhez persze fontos, hogy a UI olyan módon legyen elkészítve, hogy a gombok, mezők, lényegében bármi amit vizsgálni, kitölteni, megnyomni akarunk egyértelműen beazonosítható legyen. Ha ez megvan, akkor nincs más dolgunk, mint bekötni mindezt a saját kis CI pipelineunkba. Tehát bármikor, amikor pl a masterbe bekerül valami, kirakjuk az alkalmazást egy izolált, stabil környezetbe és utána ráengedjük ezeket a teszteket és megnézzük, hogy minden stimmel-e. Ha nem, akkor bizony jelezzen és javítsuk ki a hibát, ez legyen az elsődleges prioritás. Fontos, hogy ez a környezet ne változzon, tehát mindig ugyanbból az állapotból induljon, takarítsuk ki a db-t utána, ne legyenek fals pozitív ereményeink, ugyanis az igen hamar megrendíti a bizalmat a rendszerben és hamar visszatér a teljes manuál tesztelés.

Na és mi a szerepe a tesztelőknek itt? Nem egyik percről a másikra megy egy ilyen átállás, nyílván az opsnak is van köze hozzá, meg kell hozzá programozni is.

Viszont szép lassan el lehet kezdeni a regresszió elemeit átírni ide, azokat már nem kell a releasek előtt megcsinálni, vagy egyre kevesebbet, aztán el lehet kezdeni az új featureöket is egyre inkább automatizáltan tesztelni és utána már lehet nem is kell várni két heteket a releasere, hanem amint bemergeltük a featuret és zöld lett a build, már lehet is élesíteni azt. Miért? Mert minden buildnél mindent tesztelünk.

Ez volt a minicube podcast, találkozunk legközelebb! Sziasztok!



See acast.com/privacy for privacy and opt-out information.

14 epizódok