Manuálisból automata tesztelő: egyszerűen, Pythonnal

A folyamatos és jól megtervezett automatizált tesztelés elengedhetetlen része a szoftverfejlesztésnek – ahhoz ugyanakkor, hogy valaki automatizált tesztelővé váljon, nem szükséges korábbi fejlesztői tapasztalat. A vizsgált szoftverek architektúrájának megfelelő ismeretével, illetve egy jól megtervezett tesztelési keretrendszerrel a manuális tesztelők gyorsan beletanulhatnak az automata tesztelésbe is, ezzel stabil hátteret adva a CICD pipeline-oknak.

Ahogy arra a HWSW free! CI/CD online meetupján tartott előadásában Trenyik Ádám, a Magyar Telekom tesztmérnöke is rávilágított, a tesztelés alfája és omegája a tesztelési piramis - utóbbi lépcsőit alulról felfelé haladva a unit tesztek, komponenstesztek, alrendszertesztek, rendszertesztek, illetve az end-to-end tesztek alkotják. A tesztelési rétegek lehető legkiterjedtebb automatizálása az agilis működéshez is elengedhetetlen: addig lehet hatékony CICD folyamatokban gondolkozni, amíg az automata tesztek érnek . Ha egy projektnél a csapat csak a unit vagy komponensteszteket automatizálta, valójában az agilitás is csak ezen rétegekig tart, utána a rendszer vízesés modellé "simul".

Kézi vezérlésből robotpilótára

A Magyar Telekomnál Ádám az utóbbi két és fél évben az agilis spektrum kiszélesítésén dolgozott, hogy azzal a teljes piramis lefedhető legyen, beleértve a rendszertesztek és az end-to-end tesztek automatizálását is. Ez ugyanakkor nem ment egyik pillanatról a másikra, hiszen olyan kollégákkal kellett bevezetni a tesztautomatizációt, akik korábban manuális tesztelőként dolgoztak, nem volt programozói tapasztalatuk. Az átállást így hosszas ötletelés előzte meg, hogy milyen technológiával lehet érdemes abba belevágni, amely közel állhat a manuális tesztelőköz, mégis támogatja az automatizálást és a CICD folyamatokat. A cél az volt, hogy amikor a fejlesztő megnyomja a "nagy piros commit gombot" és elindulnak a CICD folyamatok, a generált tesztriportokból világosan látható legyen az adott szoftververzió minősége, és hogy az mehet-e tovább az éles rendszer felé, vagy sem.

Ehhez az Ádám által  bevezetett BDD módszertan éppen kapóra jött: a BDD, azaz Behavior-driven development egy agilis fejlesztési módszertan, amely a korábbi TDD-t, azaz Test Driven Development módszert hivatott kiterjeszteni a piramis felső szintjeire, annak számos alapelvét megtartva, komoly hangsúlyt helyezve viszont a csapaton belüli konkrét, egyértelmű példákra építő párbeszédre. Ezt shift-left tesztelési megközelítéssel, azaz a szoftver életciklusának már egészen korai szakaszában elkezdett tesztekkel kiegészítve terelte Ádám és csapata a folyamatokat az agilis működés felé.

Mindehhez ugyanakkor egy jól használható, BDD tesztelési frameworkre is szükség volt, illetve jól körülhatárolható fázisokat is meg kellett határozni a transzformációhoz, amely 10-15   csapat munkájára is hatással lehet. Ádám a manuális tesztelőkkel közösen  az átalakulásnak egy vertikális, illetve egy horizontális irányvonalat is meghatározott.

Csapat- és egyéni szintű fejlődés

Előbbi esetben a folyamat több fázison halad végig: elsőként el kell határozni, hogy a UI fejlesztést végző csapatok igénybe fogják venni egy 5-6 fős automata tesztelőbrigád munkáját. Második fázisban azoknak csapattagoknak, akik a későbbiekben automatizált teszteket futtatnának, meg kell tanulniuk értelmezni a CICD pipeline-on kapott adatokat, illetve elemezni a teszteredményeket. A harmadik lépcsőt a teszttervezés jelenti: a UI fejlesztőcsapat a manuális és automata tesztelőkkel közösen kell, hogy kidolgozza a különböző teszteseteket - végül pedig a negyedik lépésben az automata tesztelőknek kell eljutniuk arra a szintre, hogy a csapatokban képesek legyenek már önállóan elkészíteni egy köztes kódot (azaz glue code-ot).

Míg a vertikális szakasz a csapatok szintjén történő átalakulást öleli fel, a horizontális transzformáció a tesztelők egyéni szintű fejlődését takarja. Ennek első lépéseként, a korábbi fejlesztési tapasztalattal nem rendelkező, manuális tesztelők a BDD menetrendjéhez igazodva a mindenki számára egyszerűen érthető, olvasható, végrehajtható tesztforgatókönyveket építenek, minél inkább univerzális, újra felhasználható mondatokkal - az ebben leírt kvázi szabad szavas (megfelelően annotált) mondatok végrehajtásáról Python kód gondoskodik, utóbbi és a forgatókönyv összekötését szolgálja az említett glue code. Utóbbi elkészítése jelenti a második lépcsőt: a köztes réteg nyelvének elsajátításával már az addig manuális tesztelők maguk is el tudnak mélyülni az automatizációban.

A dobogó tetejére azután érhet fel a tesztelő, hogy megértette a kapcsolódó nyelvezetet, szintaktikát, szemantikát - és persze nyitott a további fejlődésre. Ezen a szinten már az egyes tesztjegyzőkönyv mondatok mögötti Python osztályokkal, függvényekkel is elkezd ismerkedni - illetve ezek megtervezésében, felépítésében is részt vesz. Itt még nem konkrét utasítások elkészítéséről van szó, amelyek a UI-on végeznek interakciót, ugyanakkor a kolléga ezen a ponton már elő tudja készíteni az egyes osztályok struktúráját, örökléseken, függvényeken, paramétereken keresztül. Utolsó lépésben pedig már az egyes a webes fejlesztéseknél (amelyek a Magyar Telekomnál jelenleg a UI fejlesztések oroszlánrészét képezik) használt page object elemek felvitelét és manipulációját is elsajátítják.

Pythonra felhúzott alapok

Maga a tesztelési keretrendszer a már említett Pythonban készült. A nyelv mellett több érv is szólt, annak könnyű elsajátíthatóságától és népszerűségétől, az egyszerű Elastic Stack és Jira integrációig - utóbbi platformon zajlik ugyanis a tesztadatok statikus dokumentációja. Ugyancsak nyomott a latban, hogy a Pythonnal a nagyon jól használható, Behave névre hallgató BDD library is bevethető.

Ádám igyekezett a frameworknél a lehető legegyszerűbb felépítésre törekedni - annak kódja jelenleg alig háromezer sor. A kompakt megoldás ugyanakkor mindent tud amire szükség van, azzal meghívhatók a mögötti tesztjegyzőkönyv mondatok, paraméterezett tesztek futtathatók vele, illetve a valós idejű státuszok biztosításáért felelős Elastic Stack  integráció és az offline, release-hez kötődő Jira riportálás is ott van az arzenálban.

A megoldással a tapasztalatok szerint gyorsan felépíthető az automatizált tesztelői kompetencia. Ádám csapatában a fejlesztői tapasztalatok nélkül érkező kollégák fél éven belül eljutottak odáig, hogy önállóan tudnak vinni tesztautomatizációs projekteket. A 6-7 fős brigád pedig mára 15 párhuzamos pipeline karbantartásáért és futtatásáért felel, a munkájuk gyümölcseként megszülető Jira reportok alapján pedig a release managerek a megfelelő kockázatelemzést  követően, a manuális és automata tesztek eredményét egységként kezelve döntenek arról, hogy egy adott szoftververzió készen áll-e az éles használatra.

Ha részt vennél a Telekom IT megújulásában, akkor nézz szét nyitott pozíciók között!

[A Magyar Telekom megbízásából készített, fizetett anyag.]