Tesztelés a Gyakorlatban

xxxxxxxx xxxxxx A SZAKÉRTŐ TESZTELŐK LAPJA TESZTELÉS A GYAKORLATBAN 2020/ I I . szám A „kevesebb” néha több!

© Copyright 2006-2008, Inflectra Corporation SpiraTest and Inflectra are registered trademarks of Inflectra Corporation A SpiraTest® használatával egyszerűen, költséghatékonyan, egyedülálló módon javíthatod tesztelési folyamatodat. Bővebb információért keresd a SpiraTest® hivatalos magyarországi forgalmazóját. Minden cég arra törekszik, hogy a szoftvertesztelésben maximalizálja a minőségi és mennyiségi eredményeit. A piacon számtalan lehetőségből választhatsz. Azonban, ha a legjobb eredményt szeretnéd elérni, csak egy megoldás létezik. Passed Informatikai Kft. www.passed.hu +36/1/789-2525

xxxxxxxx xxxxxx 3 . oldal TESZTELÉS A GYAKORLATBAN – A SZAKÉRTŐ TESZTELŐK LAPJA .oldal Kedves Olvasó! IMPRESSZUM Szerzői jogok Azzal, hogy belép a www.tesztelesagyakorlatban.hu oldalára, elfogadja az alábbi feltételeket, még abban az esetben is, ha nem regisztrált felhasználója, előfizetője a rendszer egyik szolgáltatásának sem: A www.tesztelesagyakorlatban.hu webszájton („lap”) található tartalom a SZERZŐ(K) és a („kiadó”) szellemi tulajdona. Az Passed Informatikai Kft. fenntart minden, a lap bármely részének bármilyen módszerrel, technikával történő másolásával és terjesztésével kapcsolatos jogot. A laphoz tartozó oldalak tartalmát és kialakítását nemzetközi és magyar törvények védik. A kiadó előzetes írásos hozzájárulása nélkül tilos a lap egészének vagy részeinek (szöveg, grafika, fotó, audio- vagy videoanyag, adatszerkezet, struktúra, eljárás, program stb.) feldolgozása és értékesítése. A lap tartalmának egyes részeit - kizárólag saját felhasználás céljából - merevlemezére mentheti vagy kinyomtathatja, de ebben az esetben sem jogosult a lap így többszörözött részének további felhasználására, terjesztésére, adatbázisban történő tárolására, letölthetővé tételére, kereskedelmi forgalomba hozatalára. ATesztelés a Gyakorlatban Magazin oldalai teljes egészében, a reklámokkal, hirdetésekkel együtt szerzői jogvédelem alatt állnak, azokból bármely részt kivágni, a megcsonkított részt pedig nyilvánossághoz bármely módon újraközvetíteni tilos. Tilos továbbá a kiadó előzetes írásbeli engedélye nélkül a lap tartalmát tükrözni, azaz technikai művelet segítségével nyilvánossághoz újraközvetíteni, még változatlan formában is. A jogosulatlan felhasználás büntető- és polgári jogi következményeket von maga után. Az Tesztelés a Gyakorlatban Magazin követelheti a jogsértés abbahagyását és kárának megtérítését. A laptól értesüléseket átvenni csak a lapra való hivatkozással lehet, azzal a feltétellel, hogy az átvevő a) nem módosítja az eredeti információt, b) a lapra utaló egyértelmű hivatkozást minden közlésnél feltünteti. Az Passed Informatikai Kft pontos és hiteles információk közlésére törekszik, de a tájékoztatásból fakadó esetleges károkért felelősséget nem vállal. Kiadja: Passed Informatikai Kft. Szerkesztőség: Főszerkesztő Szrnkáné Balogh Edina info@tesztelesagyakorlatban.hu Kiadványszerkesztés, grafikai munkák: Mogyoró Győző Graphic Designer gyozo.mogyoro@gmail.com Internet: www.tesztelesagyakorlatban.hu Twitter: @tesztAgy Kapcsolat: 1095 Budapest, Tinódi utca 1-3. C 1/9. info@tesztelesagyakorlatban.hu feladatok hatékony végrehajtása érdekében nem hagyhatják figyelmen kívül a teszt automatizálást sem, mivel ez a DevOps folyamat egyik lényeges eleme. Mint szinte minden körülöttünk, a szoftvertesztelés világa is folyamatosan fejlődik, magazinunkban olyan témákat válogattunk, amelyek betekintést nyújtanak a legújabb tesztelési trendekbe. Kellemes böngészést, remélem a „Kevesebb most több”! Szrnkáné Balogh Edina A „kevesebb néha több”? A „kevesebb több” kifejezés először Robert Browning, Andrea del Sarto című versében jelent meg 1855-ben. Definíció szerint: Néha valami egyszerű jobb, mint valami fejlett vagy bonyolult. Vagy egy kicsit másképp: jobb, ha csak az alapvető dolgokkal foglalkozunk, mintha túl sok felesleges dologgal kellene. Ez lehetővé teszi, hogy arra összpontosítsunk, ami számít. Mi is szeretnénk arra összpontosítani, ami a szoftvertesztelés világában mostanság számít. Manapság - amikor a világ digitalizálódik - hatalmas változások tapasztalhatók a technológiai fejlődésben. Már most látszik, hogy 2020-ban eddig nem tapasztalt mértékű technológiai változások és a digitális átalakulás szemtanúi lehetünk, ezáltal nemcsak az egyéneknek, de a cégeknek is folyamatos innovációra és fejlődésre lesz szükségük. Hozni kell a minőséget, de gyorsan! Előtérbe kerül a folyamatok gyorsítása, de úgy kell ezt megoldani, hogy közben a minőség ne szenvedjen csorbát. A cégek egyre inkább átállnak az agilis munkamódszerre, ami a gyorsan változó követelményeket követni tudja, de megjelent a DevOps is, ami emellett a sebesség növelését is megcélozza. A DevOps egyre inkább előtérbe kerülésével a szoftverfejlesztő csapatok a Köszönöm!

4.oldal www.tesztelesagyakorlatban.hu TARTALOMJEGYZÉK 6 Tesztmanagement Lisa Crispin Hogyan légy sikeres tesztelő, ha a csapatod DevOps-ra áll át? A kultúraváltás nehéz, és a tesztelők gyakran szenvednek stressztől váltás közben, hogy a már megszokottól is gyorsabban kerülnek a gyártási folyamatba újabb és újabb kódsorok. A menedzsment gyakran él abban a tévhitben, hogy a DevOps és a folyamatos szállítás azonnal mindent „gyorsabbá” fog tenni. De ettől még nem lesz gyorsabb az új nagy feature-ök lefejlesztése – csak egyszerűen szétbontjuk ezeket a nagy feature-öket apróbb darabokra, melyekkel kisebb léptékben, de gyakrabban növekedhet a program. 10 Tesztmanagement Daniel Knott Hogyan gyorsítható fel a fejlesztési folyamat? Minden vállalat szeretne remek, és jó minőségű terméket nyújtani az ügyfeleinek. Emellett a cégeknek muszáj fejlődni, és gyorsabban szállítani anélkül, hogy veszítenének a minőségből. Ezért a vállalatok, de különösen a termék menedzserek, mindigpróbáljákoptimalizálni aszoftverfejlesztési folyamatot,hogyazgyorsabbáváljon, de ne veszítsenek a minőségből és előnyt szerezzenek a vetélytársakkal szemben. 12 Módsze r ta n Peter Varhol „Shifting Right” a tesztelésben Az elmúlt években a legtöbb tesztvezető a „Shifting Left” módszert támogatta, vagyis, hogya tesztelőketmára tervezési, ésa fejlesztési folyamatokba isvonjákbe.Atervezés, és végrehajtás megértésével a tesztelők még átfogóbb ismeretekre tesznek szert, megismerik a rendszer erősségeit és gyengeségeit. Én voltam annak a javaslatnak a hangoztatója, hogy a megszokott Shifting Left metódus helyett használjuk a Shifting Right-ot. Ezzel ugyanis folyamatosan lehet tesztelni és monitorozni az alkalmazást, még akkor is, ha az már telepítve van és élesben fut. 14 Tesztautomatizálás Torma Máté Puppeteer – A webes tesztautomatizálás bábjátékosa Pár évvel ezelőtt a Google Chrome fejlesztői csapata egy igazán érdekes koncepcióval rukkolt elő. Az általuk fejlesztett Node könyvtárral tulajdonképpen egy magas-szintű API-t valósítottak meg, ami a Parancssorból is utat nyithat számunkra egészen a böngésző DevTools-ig, így hozzáférhetünk a DOM-hoz, vagy akár a böngészőmotorhoz, szabályozhatjuk a sávszélességet, eszköz emulációt végezhetünk, felhasználói műveleteket hajthatunk végre, mindezt a böngésző grafikus interfészének megjelenítése nélkül! De, hogy ettől miért is kéne nekünk, tesztelőknek hátast dobni?

xxxxxxxx xxxxxx 5 . oldal .oldal TESZTELÉS A GYAKORLATBAN – A SZAKÉRTŐ TESZTELŐK LAPJA TARTALOMJEGYZÉK Munkaszervezés Horváth Zsolt Welcome Home avagy Gazdálkodj Okosan Akoronavírus fenekestül felforgattaéletünket. Azúj rend jött, látott ésúgydöntöttmégegy ideig velünkmarad. Nemkell túl nagy bátorság ahhoz, hogy ki lehessen jelenteni, életünk nem lesz már olyan, mint volt. Rengeteg megközelítésből lehetne vizsgálni a kialakult helyzetet, elég csak a társadalmi vagy éppen a gazdasági oldalát említeni. Az informatika – egyetemben azokkal a szektorokkal, ahol lehetőség adódik az otthoni munkavégzésre – a kevesebb nehézséggel szembenéző ágakhoz tartozik. 32 Teszttechnikák Kristin Jackvony A „kevesebb” néha több! Hallottál már a szerver nélküli architektúráról és gondoltál már rá, hogy vajon milyen is lehet az? Hogy lehet egy applikációt szerver nélkül kitelepíteni? A titok nyitja az, hogy nem lehet. És miért akarnád az applikációdat headless browser módszerrel tesztelni? Mert a tesztjeid gyorsabbak és kevésbé rétegeltek lesznek, ugyanis nem kell megvárnod a weboldal betöltését. Most arra gondolhatsz, hogy nem lehetséges a tesztjeid eredményeinek helyes megjelenítése ezzel a metódussal, de ez nem így van! 20 28 36 Tesztautomatizálás Kinga Witko Az éjszakai buildelés előnyei Az éjszakai build egy semleges build, ami általában akkor készül el, mikor valószínűleg senki sem dolgozik az irodában. Emellett a source kódban nem történik változtatás a buildelés ideje alatt. Minden éjjel automatikusan fut végig. Minden része a kódban, ami már átnézésre került, a source kód felügyelői által buildelésre kerül. Munkaszervezés Joel Montvelisky Mindful Testing Viccesen vagy furán hangzik? Nos, úgy gondolom, egy kicsit mindkettő... De mindenféleképpen fontos! Hallottál már a Mindfulness-ről, azaz tudatos jelenlétről? 24 Módszertan Toyer Mamoojee Az automatizálás bevezetése - mérhető tudatossággal! Ahogy a pénz átformálja a világot, az automatizálás is átalakítja a tesztelési világot. Az automatizálás már nem csupán egy távoli lehetőség, szóbeszéd, hanem túllépet ezen, és a legtöbb szervezet életében kritikus szerepet tölt be a szoftver release-k kiadásában. Azonban a kérdés továbbra is fennáll: a megfelelő módon történik a tesztautomatizálást? Vagy egy másik lényeges kérdést is fel kell tenni: van-e helyes módszer a tesztek automatizálására?

6.oldal www.tesztelesagyakorlatban.hu 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. JCL1 és JES22 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 Star3 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áltoztasdmegamindset-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” A kultúraváltás nehéz, és a tesztelők gyakran szenvednek stressztől váltás közben, hogy a már megszokottól is gyorsabban kerülnek a gyártási folyamatba újabb és újabb kódsorok. A menedzsment gyakran él abban a tévhitben, hogy a DevOps és a folyamatos szállítás azonnal mindent „gyorsabbá” fog tenni. De ettől még nem lesz gyorsabb az új nagy featureök lefejlesztése – csak egyszerűen szétbontjuk ezeket a nagy feature-öket apróbb darabokra, melyekkel kisebb léptékben, de gyakrabban növekedhet a program. Hogyan légy sikeres tesztelő, ha a csapatod DevOps-ra áll át

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

Publikálj nálunk!

TESZTELÉS A GYAKORLATBAN – A SZAKÉRTŐ TESZTELŐK LAPJA 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 DevOpsró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. Ilyenmó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! Szerző: Lisa Crispin Forrás: https://qablog.practitest.com/succeed-as-testerdevops-team/ Hivatkozások: 1. https://en.wikipedia.org/wiki/Job_Control_Language 2. https://www.ibm.com/support/knowledgecenter/ en/SSLTBW_2.1.0/com.ibm.zos.v2r1.hasa800/ has2s80017.htm 3.https://en.wikipedia.org/wiki/Xerox_Star 4.https://leanpub.com/testingindevops Lisa Crispin Lisa Crispin egyik társszerzője a More Agile Testing: Learning Journeys for theWhole Team (2014), Agile Testing: A Practical Guide for Testers and Agile Teams (2009) és a LiveLessons „Agile Testing Essent ials” videóknak. Tanfolyamokat tart pl. az „Agilis tesztelés az egész csapat számára” témában. Lisa-t társaik szavazták meg a legbefolyásosabb agilis tesztelés szakértőként az Agile Testing Days-en 2012-ben. A mabl munkatársa, aki a szoftverközösség tesztelésének vezető gyakorlatait fedezi fel. 9 . oldal TESZT MANAGEMENT

10.oldal www.tesztelesagyakorlatban.hu Az alábbi négy szempont figyelembe vétele elengedhetetlen a fejlesztési folyamat2 felgyorsítása érdekében úgy, hogy a minőségből1 ne veszítsünk: 1. Legyen egy jól meghatározott termékfejlesztési stratégia Minden vállalatnak és csapatnak az alapja, hogy rendelkezniük kell termék startégiával. A kidolgozott stratégia segítségével a csapat levonhatja a saját következtetéseit, amely segít felgyorsítani a termék fejlesztését. Első lépésként a cégeknek és a csapatoknak a piacot kell megismerniük és leginkább a célközönséget akiknek készítik a terméket. Ha ez a tudás, információ megvan, akkor sokkal könnyebb összpontosítani az ügyfelek igényeire. Acélközönségalapjánegyfejlesztőicsapat,éslegfőképpen a termékmenedzser, azUX/UI kollégákkal együttműködve elkezdhetik egy korai prototípus elkészítését. A cég bemutathatja ezeket a korai prototípusokat a célközönségnek, hogy első körben megismerhesse az új termék potenciálját. Ez a korai felhasználói bevonás segít a csapatnak, hogy újra azokra a szolgáltatásokra összpontosítson, amelyek valóban fontosak az ügyfelek számára. 2. Kövesd a lean & agilis vonalat a munkádban Ha a vállalati stratégia egyértelmű, akkor a legnagyobb fejlesztéseket meg lehet tenni a szoftverfejlesztő csoporton belül. Ha egy csapat olyan agilis módszert alkalmaz3, mint például a SCRUM vagy a KANBAN, akkor kialakíthat egy hatékony munkamódszert, még akkor is, ha a vállalat nem annyira elkötelezett az agilis környezet mellett. Legfontosabb a fókusz és az összpontosítás. Ha a fejlesztés, és a termék fókusz egyértelmű, akkor a csapat nagyszerű dolgokat érhet el. • Az első lépés a folyamat javításában az legyen, hogy csak olyan dolgokra koncentráljunk, amelyek igazán fontosak, és szüntessük meg a felesleges tárgyalásokat. Legfőképpen nagyobb vállalatokra jellemző, hogy mindenre megbeszélést szerveznek. A legtöbb témát, amire megbeszélést szerveznek, meg lehet oldani e-mailen vagy messengeren keresztül is. • Másodszor, a csapatoknak legyen egyértelmű a napirendje és legyen biztosítva, hogy a végeredmény elérésére tudjon koncentrálni. Legyenek például olyan tervezett megbeszélések a külső ügyfelekkel, amelyek a finomításra törekednek, arra, hogy a csapat jobban megismerhesse az igényeiket. • A következő javító lépés a függőségek, dependenciák kiküszöbölése, mint például más csoportokra vagy szolgáltatásokra támaszkodás. Ezegykihívást jelentő feladat a termékmenedzser Minden vállalat szeretne remek, és jó minőségű terméket nyújtani az ügyfeleinek. Eme l l e t t a cégeknek muszáj fejlődni, és gyorsabban szállítani anélkül, hogy veszítenének a minőségből. Ezért a vállalatok, de különösen a termék menedzserek, mindig próbálják optimalizálni a szoftverfejlesztési folyamatot, hogy az gyorsabbá váljon, de ne veszítsenek a minőségből és előnyt szerezzenek a vetélytársakkal szemben. Hogyan gyorsítható fel a fejlesztési folyamat

TESZTELÉS A GYAKORLATBAN – A SZAKÉRTŐ TESZTELŐK LAPJA számára, mert néha nem egyszerű átlátni a lehetséges dependenciákat. Ebben az esetben fontos bevonni a fejlesztőket, vagy a software architektet a korai termékfelfedezésbe, hogy technikai szemszögből is lássuk a helyzetet. • Amint a függőségek tisztázása megtörtént, a termék menedzsernek el kell kezdeni előkészíteni a backlogot a csapat számára, ahonnan majd képesek lesznek felvenni a feladatokat maguknak, valamint implementálni, és tesztelni az új funkciókat. Legjobb esetben, a backlog már elő van készítve a következő sprintre, vagy hétre. Ez idő alatt, a termék menedzser előre tud dolgozni, hogy előkészítse az új funkciókat, vagy az ügyfelekkel egyeztetni, visszajelzéseket kérni. Ezzel a munkamódszerrel a csapatnak mindig vanelőkészített backlogja, és képesa termékeket, funkciókat szállítani minden iteráció után. 3. Az automatizálás javítása Egy szoftverfejlesztő csoportban az automatizálás az a másik dolog, amit javítani lehet. Ez nyilvánvalóan nem a termékmenedzser feladata. A termék menedzsernek azonban ismernie kell, hogy milyen előnyei vannak az automatizálásnak, és támogatnia kell abban a csapatot, hogy időt tudjon fektetni a saját infrastrukturája fejlesztésébe, ami segíti a csapatot a termékszállításban. Az automatizálással nagyon sok idő megtakarítható, amit például arra tudnak használni, hogy jobban megismerjék a terméket, és annak architekturáját. Mielőtt a csapat időt és pénzt fektetne az automatizálásba, előtte tisztán kell értenie, hogy mi az ami automatizálható, mi az amit érdemes automatizálni, és mi az amit nem4. Például, ha a termék, vagya termékegy részeakövetkezőhetekben gyakran fog változni, akkor nem a legjobb ötlet az automatizálás a korai szakaszokban. Másrészt, ha vannak olyan kritikus részei az alkalmazásnak, amely mindig működnie kell, fontos, hogy ezek le legyenek fedve automata tesztekkel a kezdetektől fogva. A csapatnak kell meghatározni, hogy a program melyik része, mikor, és hogyan legyen automatizálva. 4. A kulcs a dokumentáció. Mindig. Minden terméket dokumentálni kell, ideértve a termék fejlesztésének módját is. Melyek a támogatott szolgáltatások, hol vannak a potenciális problémák, vagy mi várható a jövőben? Könnyű feladatnak tűnik, de a legtöbb csapat nem fordít elegendő időt saját termékének és szolgáltatásainak dokumentálására. Ez a befektetett idő azonban hosszú távon megtérül és segíti a fejlesztési folyamat felgyorsítását. Különösen akkor, ha egy termék fejlesztése már régebb óta tart és a termék mérete is növekszik, ez a fajta információ segíteni fogja a csapatot visszaemlékezni a döntésekre vagy a termék architektúrájára. Ezen kívül a megbízható termékdokumentáció5 segíti az új kollégák bekapcsolódását. A dokumentáció áttanulmányozásával sokkal gyorsabban megértik a függőségeket és a termék logikáját. Ez elősegíti az új kollégák gyorsabb beilleszkedését a csapatba. Végül, de nem utolsósorban a jól dokumentált termék az érdekelt felek számára is segít abban, hogy több ismeretet szerezzenek a termékről anélkül, hogy megkérdezzék és ezzel megszakítsák a csapat munkáját. A termék informatikai infrastruktúrájától függően a termékdokumentáció elkészíthető ticketing rendszerben, wikiben vagy akár a kódbanmagában is. Itt az idő gyorsítani: készen állsz? A vállalatoknak arra kell koncentrálniuk, hogy csökkentsék a termékeik piacra dobásának idejét. Elég gyorsnak kell lenniük ahhoz, hogy kiszolgálják, kielégítsék a felhasználói igényeket, és versenyelőnyben maradjanak a többi vállalattal szemben. Azonban ez a fejlesztési gyorsaság nem jön ingyen. A csapatnak időt kell belefektetnie abba, hogy elemezze a jelenlegi munkamódszerét, folyamatait. A fejlesztés javítása érdekében, a következő kérdésekre kell megtalálni a válaszokat: • Világos-e a termékfejlesztési stratégia mindenki számára? • Világos,ésegyértelmű-emindenacsapatnak, ami ahhoz kell, hogy koncentráltan és függetlenül dolgozhassanak a termékükön? • Megvan a termék fejlesztéséhez szükséges tudás és készségek a csapatban? • A csapat a megfelelő technologiát, és tech-infrastruktúrát használja-e, és az naprakész-e? • Engedélyezve van-e, és tud-e a csapat időt áldozni az automatizálásra, és a dokumentálásra6? Szerző: Daniel Knott Forrás: https://www.applause.com/blog/4-stepsto-ship-your-products-faster 1. https://www.applause.com/blog/realtors-keysto-achieving-speed-and-quality 2. https://www.applause.com/blog/its-all-or-nothingon-agile 3. https://www.applause.com/blog/which-agile-are-you 4. https://www.applause.com/blog/the-properrole-of-test-automation 5. https://www.applause.com/blog/steps-to-maturingtest-automation 6. ht tps: //www.applause.com/blog/adopt ingautomat ion- is-essent ial -for-growth Daniel Knott Daniel mobil tesztelési szakér tő, aki vezető szof t vertesztmérnökként dolgozik az XING mobil csapatában. Szoftvertesztelési pályafutása 2003ban kezdődött az IBM-nél, mint gyakornok. Az IBMnél töltött idő után szoftverfejlesztést és tesztelést tanult. 2009 óta olyan cégeknél dolgozott, mint az Accenture, az AOE és a XING. Számos mobil tesztelési automatizáló eszközzel kapcsolatos tapasztalattal rendelkezik, mint például a Robotium, a Calabash for iOS / Android, az Espresso és a Keep It Functional. Ezen eszközök segítségével kifejlesztett egy teljesen automatizált tesztelési környezetet Android és iOS számára. Szeret i megosztani tudását , ezér t elkezdte leírni tapasztalatait a www.adventuresinqa.com blogjában, valamint számos tesztelési magazinban. Európa különféle konferenciáinak előadója, és 2014 óta a Hands-OnMobile App Testing könyv szerzője. 11 . oldal TESZT MANAGEMENT

12.oldal www.tesztelesagyakorlatban.hu A Cloud telepítés lehetővé tette és szükségessé is tette a folyamatos tesztelés és monitorozást az élesben futó rendszereknél.MígaCloudugyanglobáliselérhetőséget és végtelen skálázhatóságot eredményez, addig ez sokkal bonyolultabb, összetettebb művelet, mint csak kitelepíteni egy vállalati adat központba. A legtöbb esetben a tesztelők általában helyi rendszereken vagy egyszerűsített Cloud rendszereken futtatják a teszteket, amelyek tulajdonságai nem mindig azonosak teljes mértékben a telepítési környezettel. Ha különbségek vannak a teszt és az éles környezet között, akkor a tesztelés nem tudja jól tükrözni, hogy milyen hibák merülhetnek fel élesben. Ezért fontos, hogya tesztelőkmegfigyeljék, és teszteljék a rendszert éles környezetben is. A munka még nem fejeződött be. Kihívást jelenthet meggyőzni a veterán tesztelőket arról, hogy igenis fontos élesben is tesztelni. Annak ellenére, hogy elfogadott az, hogy a teszt környezet eltérhet az éles környezettől, a tesztelők régóta igen elfogultak és ellene vannak a telepítés utáni tesztelésnek. Az alkalmazás módosítgatása éles környezetben súlyos következményekkel járhat és a tesztelők úgy gondolják, hogy a munkájuknak vége, amint az alkalmazás átadásra kerül. De ez egyszerűen nem így van. A Cloud-ban gyorsabban vissza lehet állítani a rendszert, egy hiba vagy egy rendszer zavar után. A legjobb esetben gyorsabban adhat eredményeket élesben megfigyelni az alkalmazást, mint ha a csapatok megvizsgálnák a teljesítményt, és a rendelkezésre álló adatokat. A legrosszabb esetben biztosítani kellene a gyors visszaállást az előző verzióra. Cloudban való megfigyelés, és tesztelés lehetővé teszi, hogy a tesztelők a hibákat előbb megtalálják, mint, hogyezproblémákat okozzona felhasználóknak. Nyilvánvaló, hogymiért fontosezadigitális felhasználói élmény korszakában. Megtalálni, és javítani a hibákat mielőtt a felhasználók észlelnék azt, jelentős nyereség a cég, vállalat számára, mert nem teszi ki a felhasználókat rossz tapasztalatoknak, és ezzel talán nem veszít a termelékenységből, és nem csökkennek az eladások. Szintetikus tesztelés éles környezetben A tesztelők ismerik a felhasználói felület (UI) tesztelés automatizálását - azaz a felhasználók lépéseit rögzítik1, és ezeket a rögzített lépéseket automatizálják. Éles környezetben ezt Az elmúlt években a legtöbb tesztvezető a „Shifting Left” módszert támogatta, vagyis, hogy a tesztelőket már a tervezési, és a fejlesztési folyamatokba is vonják be. Az tervezés, és végrehajtásmegértésével a tesztelők még átfogóbb ismeretekre tesznek szert, megismerik a rendszer erősségeit és gyengeségeit. Én voltam annak a javaslatnak a hangoztatója, hogy a megszokott Shifting Left metódus helyett használjuk a Shifting Right-ot. Ezzel ugyanis folyamatosan lehet tesztelni és monitorozni az alkalmazást, még akkor is, ha az már telepítve van és élesben fut. „Shifting Right” a tesztelésben

TESZTELÉS A GYAKORLATBAN – A SZAKÉRTŐ TESZTELŐK LAPJA MÓDSZERTAN nevezik Szintetikus tesztelésnek. Ez gyakran egy részmegoldása a megfigyelésnek, így az alkalmazást tesztelés alatt lehet megfigyelni. Ezek a tesztek az általános felhasználói esetekben működnek, gyakran határozzák meg úgy, hogy ezek azok a User Story-k, amelyek az alkalmazás alapját képezik. Amint ezt rögzítették, bármikor végrehajthatók, legyen nappal vagy éjjel. Ennek során az alkalmazás feltételei megvizsgálhatók különböző időpontokban és terhelésekkel. Különböző kéréseket lehet indítani, különböző adat központokba, a világ különböző részeire, hogy jobban megértsük a lehetőségeket és válaszidőt. Ez a legjobb módja annak, hogy megtaláljuk a hibákat és más problémákat még a felhasználók előtt. A Szintetikus tesztelés logikátlanságokat, hibákat tárhat fel, amiket nem fedeztek fel az élesítés előtt, még akkor is, ha a felhasználók nem jelentettek egyet sem. Ezeket a problémákat meg lehet állapítani, és javítani lehet, mielőtt hatással lenne bármilyen felhasználóra, vagy vállalkozásra. Megfigyelés az egészséges működés és a hatékonyság érdekében Még nem beszéltem arról, hogy mit kell figyelnünk egy élesben működő alkalmazáson. Először is ugyanazokatadolgokat,amelyeketazadatközpontban is figyelnénk - a CPU-t, a lemezt és a hálózatot. Ezek továbbra is alapvető fontosságúak az alkalmazás működésének megértésében. Mivel azonban a felhasználói élmény egyre nagyobb hangsúlyt kap, a hagyományos megfigyelési mutatók visszatérnek azokhoz az intézkedésekhez, amelyek befolyásolják a tényleges felhasználókat. Néhány megfigyelő eszköz valós felhasználói megfigyelést alkalmaz, vagy RUM-ot a visszatérő adatok időben történő ellenőrzése érdekében, esetleg ideje egy új képernyőképet csinálni, mint kapni 404, vagy más hiba üzenetet. Ez teszi lehetővé, hogy a tesztelők időben felfedezzék a felhasználói élmény hiányosságait. A megfigyeléshez kapcsolódó elemzések nem csupán pillanatfelvételek az alkalmazás állapotáról. Információt nyújtanak a trendekről, amelyek lehetővé teszik a tesztelők számára, hogy azonosítsák, várható-e, hogy a jövőben egy alkalmazással probléma adódik. Ha több héten, vagy hónapon keresztül tárolunk nagy mennyiségű megfigyelésből származó adatot, akkor lehetséges lesz majd azonosítani a memóriaszivárgást, a szűk keresztmetszeteket, vagy más egyéb rendellenességet, még mielőtt azok nagyobb problémákat okoznak. Tesztelőknek monitorozni kell az adatokat A tesztelésnek folyamatos megfigyelést kell tartalmaznia és élesben kell tesztelni a Cloud alkalmazásokat. Miért? Mert a tesztelés az utóbbi években megváltozott. Olyan praktikák kerültek előtérbe, mint DevOps, és a folyamatos telepítés2 (CD - continous deployment), valamint a szoftver fejlesztés életciklus fázisai közötti különbségtétel, beleértve a gyártást is. Agilis vagy DevOps szerint működő csapatoknál a tesztelőknek biztosan kell alkalmazni a Shifting right módszert, hogy megbizonyosodjanak arról, hogy az alkalmazás éles környezetben is az elvárt módon viselkedik. Beszéltem néhány szót arról, hogy mit kell megfigyelni, és miért, de arról nem, hogy hogyan kell kell ezt tenni. Több féle eszköz létezik az alkalmazások monitorozására. Megemlítek néhányat, de érdemes saját magunknak is utánanézni, hogymelyek az igényinknek leginkább megfelelők. A legismertebb kereskedelmi eszközök közé tartozik a Dynatrace, New Relic, AppDynamics, DataDog és a Sumo Logic, de szó szerint tucatnyi eszköz közül lehet választani. Számos nyílt forráskódú monitoring megoldás létezik. A Geekflare3 hat népszerű nyílt forráskódú eszközről ad leírást, míg az OpenAPM4 olyan folyamatot mutat be, amely lehetővé teszi a legjobb megoldások kiválasztását az igények alapján. Nem szeretném reklámozni egyik eszközt sem. A monitoring rendszerek különböző képességűek, különböző árfekvésűek, és nincs olyan, hogy egy termék mindenre megfelelő. De ezek a rendszerek elengedhetetlenné váltak a rendelkezésreállás, a teljesítmény, terhelés, a hibák monitorozásánál, azért, hogy egy jobb minőségű Cloud alapú alkalmazás legyen a végeredmény. És a rendelkezésre álló számos megoldás igazolja ezen tevékenységek fontosságát. Szerző: Peter Varhol Forrás: https://blog.testproject.io/2019/12/02/ shif ting-r ight-with-testing-and-monitor ing- inproduction/ Hivatkozások: 1. https://testproject.io/smart-test-recorder/ 2.ht tps: //blog.testproject.io/2019/08/27/ testautomation-ci-testproject-api/ 3.ht tps: //geek f lare.com/best - open-source - monitoring-software/ 4.https://openapm.io/ Peter Varhol Peter Varhol közismert író és előadó. Tucatnyi cikket írt és számos ipari konferencián és internetes közvetítésen adott elő. Felsőfokú v é g z e t t s é g g e l rendelkezik a számí tástechnikából , az alkalmazot t matemat ikából és pszichológiából . A Technology Strategy Research ügyvezetője, s z o f t v e r f e j l e s z t é s i tanácsadást folytat vállalatok részére s z o f t v e r f e j l e s z t é s , tesztelés és gépi tanulás területén. Régebben technológiai újságíróként, szoftver termékmenedzserként, szoftverfejlesztőként és egyetemi tanárként is dolgozott. 13 . oldal

14.oldal www.tesztelesagyakorlatban.hu Bevezető Fontos még indulás előtt megjegyezni, hogy mivel Node alapú modulokról lesz szó, így egy alapvető javascript tudást megkövetel a mélyebb szintű megér tés, de mint azt látni fogjuk, azoknak sem kell kétségbe esniük, akik teljesen kezdők a kódolás terén, hisz egy teszt lépésinek leírása igazán intuitív. Ebben a cikkben igyekszem a legjobb tudásom szerint egy kis ízelítőt adni ebből a nagyszerű eszközből, hogy aztán az olvasó kedvet kapva maga fedezhesse fel, mi más rejlik még a jéghegy csúcsa alatt. A Node.js világa Aki automata tesztjeihez aPuppeteer t választja eszköznek, óhatatlanul is szembesülni fog a Node.js végtelennek tűnő világával, ezér t fontosnak tar tok szót ejteni róla. A Node.js nem más, mint egy olyan modulokból felépülő szof tverrendszer, melyet eredetileg internetes alkalmazások és webszerverek készítésére hoztak létre. A programok JavaScriptben írhatók. Mivel tényleg egy óriási rendszerről beszélünk, kell valami, ami rendszerezi számunkra a modulokat, segít a modulok telepítésében, frissítésében, és intelligensen oldja meg a felmerülő konf liktusokat. Ezt a feladatot a Node Package Manager, vagyis az NPM látja el. Nekünk is nagy segítségünkre lesz a továbbiakban. Kezdjük az elején! Ha még nincs telepítve gépünkre a Node. js illetve az NPM csomagkezelő, nulladik lépésként ezek letöltését és telepítését kell elvégeznünk. Letöltésre az https://nodejs.org/ en/download/ oldalon lesz lehetőségünk. A parancssort megnyitva az npm –v, illetve a node –v parancsokkal ellenizhetjük, hogy a telepítés sikeres volt-e. Ha ezzel megvagyunk, a Node.js főkönyvtárába lépve az npm init parancs kiadásával létre fogunk hozni egy package.json nevű fájlt, mely tesztjeink inicializálásáért, beállításaiért lesz majd felelős. Én a továbbiakban szemléltetésre a Visual Studio Code nevű programot fogom használni, de ízlés szerint használható kód írásához akár Notepad++, akár más kódszerkesztő is. A létrejött fájlba kukkantva valami hasonlót fogunk látni (1. ábra) Pár évvel ezelőtt a Google Chrome fejlesztői csapata egy igazán érdekes koncepcióval rukkolt elő. Az általuk fejlesztett Nodekönyvtárral tulajdonképpen egy magas-szintűAPI-t valósítottak meg, ami a Parancssorból is utat nyithat számunkra egészen a böngésző DevTools-ig, így hozzáférhetünkaDOM-hoz, vagy akár a böngészőmotorhoz, szabályozhatjuk a sávszélességet, eszköz emulációt végezhetünk, felhasználói műveleteket hajthatunk végre, mindezt a böngésző grafikus interfészének megjelenítésenélkül!De,hogyettőlmiért is kénenekünk, tesztelőknekhátast dobni? Puppeteer – A webes tesztautomatizálás bábjátékosa

TESZTELÉS A GYAKORLATBAN – A SZAKÉRTŐ TESZTELŐK LAPJA Ezt követően jöhetnek a tesztünkhöz szükséges modulok telepítései. Először fel fogom sorolni, mely parancsokat kell kiadni a modulok telepítéséhez, alább pedig az eddig nem érintett modulokhoz található rövid ismer tetőt: "npm i - -save puppeteer" vagy "npm i - -save puppeteer-core" (utóbbit abban az esetben, ha a Chromium már telepítve van) "npm i - -save mocha" "npm i - -save chai" Mocha: Egy Node.js alapú tesztelői keretrendszer, mely hookok használatával(before(), af ter(), af terEach(), beforeEach(), stb.) egyszerűbbé teszi számunkra a Node-ban jellemző aszinkron tesztelést. Chai: Egy olyan "asser tion" modul, mely könnyedén párosítható bármelyik JavaScript alapú tesztelői keretrendszerrel, esetünkben a Mocha-val. Should, Expect és Asser t inter fészeket bocsátja rendelkezésünkre, melyeken keresztül a tesztjeink során összehasonlításokat, ellenőrzéseket végezhetünk. Én a tesztemhez az "Expect" interfészt fogom használni. Ha eddig kitar tottál, mostmár semmiképp se add fel, elérkeztünk tesztkörnyezetünk felépítésének utolsó lépéseihez! Hozzunk létre a package.json-t tar talmazó könyvtárban egy .js kiterjesztésű szöveges állományt, nevezzük el akárhogy, de mellőzzük az ékezetek használatát! Ha ezzel megvagyunk, nyissuk meg a szerkesztőben a package.json fájlt és a "scripts" objektum "test" kulcsának adjuk át a következőt: node <Mocha elérési útja> - -timeout:30000 <új .js fájlunk elérési útja> Ez az én esetemben valahogy így fog kinézni (2. ábra) Ha kész, mentsünk, zárjuk be a package.json-t, majd nyissuk meg a korábban létrehozott, még üres JavaScript fájlunkat! Ezzel elérkeztünk az izgalmas részhez! Készítsük el első Puppeteer projektünket! Az itt tárgyalt részek végére lesz egy scriptünk, mely a http://automationpractice.com-on hajt végre 15 . oldal 1.ábra 2.ábra 3.ábra 4.ábra „A tökéletesség nem létezik, de mindenfajta teljesítményből van csúcsteljesítmény; elégedj meg azzal, hogy afelé törekszel.” – Selye János „Még mindig jobb fölöslegeset tudni, mint semmit.” – Lucius Annaeus Seneca „Nincs olyan eszköz, melyhez az ember ne folyamodna, hogy megmeneküljön a gondolkodás fáradalmaitól.” – Thomas Alva Edison „Azt, amit már tudsz, próbáldmeg jól felhasználni a gyakorlatban, s ha így teszel, idővel fölfeded majd a rejtett dolgokat, amelyekre kíváncsi vagy. Hasznosítsd, amit tudsz, és ez segít majd tisztázni, amit még nem ismersz.” - Rembrandt „Az ember néha azt hiszi, tökéletesebbé tette a dolgokat, pedig csak másként csoportosította őket.” - Honoré de Balzac TESZTAUTOMATIZÁLÁS

16.oldal www.tesztelesagyakorlatban.hu két tesztesetet úgy, hogy közben különböző eszközök képernyőméretét emulálja a program. Kezdő lépésként impor táljuk és mentsük el változókba a Puppeteer és Chai modulokat! Erre azér t van szükség, mer t ezeknek a változóknak a segítségével hivatkozhatunk majd később a két modulból származó függvényekre (3. ábra). Egyébként érdemes lehet szétnézni a Node. js node_modules könyvtárában, itt látható ugyanis az összes Node modul, ami telepítve van a gépünkre, többek a között a fent említettek is. Ha ezzel megvagyunk definiáljunk egy describe() blokkot, ahova a tesztesetünket írjuk, a blokkon belül pedig hozzunk létre két változót, amiket majd az összes ezt követő függvényblokkban elérhetünk. A beforeEach() blokkba írhatunk minden olyan lépést és beállítást, mely minden tesztesetünk futtatásához szükséges. A Puppeteer launch() függvényének átadott kulcs-ér ték párokat tar talmazó objektum a böngésző indításának alapbeállításait tar talmazzák. Ezekre példa: headless: true - Ebben az esetben a böngészőnk UI nélkül fog elindulni a teszthez, így sokkal gyorsabban is fog futni. devtools: false - Ha az itt átadott ér ték "true", az azt jelenti, hogy böngészőnk úgy fog elindulni, mintha lenyomtuk volna az F12-t. Továbbá lehetőségünk van például a default timeout felülírására is. Az átadott érték miliszekundumban értendő, vagyis a programunk tízezer miliszekundum után fog timeout hibát dobni, ha valami miatt nemsikerül egy lépést a megadott idő alatt végrehajtania (5. ábra) Az afetEach() blokkunkban csak annyi fog történni, hogy bezárjuk a böngészőt minden teszteset lefutása után (6. ábra). Az ezután hozzáadott it() blokkok fogják tartalmazni a futtatandó teszteseteket. A kettő közti különbség az egyszerűség kedvéért most csupán csak annyi lesz, hogy az első esetben a böngésző egy általunk 5.ábra 6.ábra „Vannak dolgok, amikről tudni lehet, hogy meg fognak történni a jövőben. Az igazi kihívás az, hogy rájöjj, mi az, ami már most lehetséges, és pontosan hogyan lehet véghezvinni.”– Mark Zuckerberg „Az összpontosítás a siker egyik kulcsa. Tisztában kell lennünk a képességeinkkel, hogy mihez értünk, és arra a területre kell fordítani az időnket és az energiánkat.”– Bill Gates „Amit megtehetsz ma, ne halaszd holnapra. Ha még ma megteheted, hogy valamit holnaprahalassz, el ne mulaszd elhalasztani.”– Karinthy Frigyes „Mindent olyan egyszerűen kell csinálni, amennyire csak lehetséges, de semmivel sem egyszerűbben.” – Albert Einstein „A jó ötletek mindig őrültségnek tűnnek, amíg ki nem derül, hogy nem azok.” – Larry Page „A siker annyit jelent, hogy az ember épp azokkal a képességekkel rendelkezik, melyekre egy adott pillanatban szükség van.” – Henry Ford

Made with FlippingBook

RkJQdWJsaXNoZXIy MTEyMzcyNw==