Magyar 
English (UK) 
Deutsch iOS, Android, verziók, készülékek: a mobiltesztelés gyorsan összetetté válik. Mutatjuk, mikor és hogyan éri meg automatizálni.
TL;DR
- Mobiltesztelésnél hamar megsokszorozódik az eszköz-, verzió- és konfigurációs kombinációk száma.
- A jól célzott automatizálás mobil appok esetében komoly ROI-t hozhat, a könnyen drágává és időigényessé váló manuális teszteléssel szemben.
- Az automatizálás a sokszori ismétlésnél kezd megtérülni, főleg regressziós és több eszközön futó teszteknél.
- A hosszú távon fenntartható automatizálás kulcsa a jól felépített, platformok között újrahasznosítható tesztarchitektúra.
- Mobilautomatizálást meglévő alkalmazásnál is érdemes bevezetni, de minél korábban figyelünk a tesztelhetőségre, annál kisebb lesz a későbbi költség és kockázat.
- Az optimális infrastruktúra kulcsa az emulátorok, fizikai eszközök és felhőalapú eszközfarmok tudatos megválasztása, illetve szükség szerinti kombinálása.
Tartalomjegyzék
Mobiltesztelés iOS-re, és Androidre: Így lesz 2 platformból végül 20
Amikor egy új mobilalkalmazás fejlesztése elkezdődik, általában már a legelején eldől, hogy iOS-re és Androidra is elkészül. Ilyenkor a csapat már ekkor számol jelentős többletköltséggel: két platform sajátosságait kell figyelembe venni, többféle UI-viselkedéssel, eltérő rendszerfunkciókkal, jogosultságkezeléssel és különböző technikai korlátokkal. A valódi költségnövekedés azonban gyakran később jelenik meg, ugyanis az alkalmazást nemcsak lefejleszteni, hanem folyamatosan ellenőrizni, azaz tesztelni is kell.
Papíron továbbra is két platformunk van. A gyakorlatban azonban egyik iPhone sem feltétlenül viselkedik pontosan úgy, mint a másik, és az Android sem egyetlen jól körülhatárolható környezet. Eltérő operációsrendszer-verziók, különböző gyártók, kijelzőméretek, hardverek és készülékspecifikus sajátosságok jelennek meg. Ehhez jönnek még az alkalmazás különböző verziói és természetesen maguk a funkciók, amelyeket minden release után ismét ellenőrizni kell.
Egy idő után tehát már nem azt kell nézni, hogy működik-e az alkalmazás iOS-en és Androidon is, hanem azt, hogy működik-e azon a valós eszköz- és rendszerkombináción, amelyet a felhasználóink ténylegesen használnak.
Ha például van 100 kritikus üzleti folyamatunk, és ezeket 10 releváns eszköz- vagy operációsrendszer-konfiguráción szeretnénk ellenőrizni, máris ezer tesztvégrehajtásnál járunk. Ráadásul mindezt nem egyszer kell elvégezni, hanem minden jelentősebb release-nél. Mindez jelentősen megnöveli a manuális tesztelés idejét.
Amikor túl időigényessé válik a mobileszközök manuális tesztelése
Ilyenkor kezdünk el általában kompromisszumot kötni:
- Nem tesztelünk minden eszközön, csak a legfontosabbakon.
- Nem futtatjuk végig az összes regressziós tesztet, csak egy részüket.
- Kockázatelemzés alapján priorizálunk.
Szakmailag teljesen rendben van, hogy nem teszteljük le minden lehetőséget 100%-osan. A gond az, ha mindez csak azért történik, hogy spóroljunk idővel. Mert ha emiatt nem ellenőrzünk valamit, akkor valójában nem a tesztelést optimalizáljuk, hanem a lefedettséget csökkentjük. És ezen a ponton lesz igazán érdekes a tesztautomatizálás.
Mobilappoknál az automatizált tesztek jelentős megtérülést hozhatnak
Az automatizált tesztelést gyakran úgy képzeljük el, mint a manuális tesztelés gyorsabb változatát: amit korábban egy ember végzett, azt most egy script csinálja. Ez részben igaz, de mobilalkalmazások esetén ennél sokkal fontosabb előnyökkel jár az automatizálás.
Egy jól megírt automatizált tesztet nemcsak egyszer tudunk lefuttatni. Ugyanaz a teszt végrehajtható több készüléken, több operációsrendszer-verzión, több alkalmazásverzión, és megfelelő infrastruktúra esetén mindez akár párhuzamosan is történhet. Az egyszer elkészített teszt tehát minden új futásnál újra értéket termel.
Ez azért fontos különbség, mert egy automatizált teszt elkészítése természetesen több munkát igényel, mint egyetlen manuális végrehajtás. Ha egy tesztet csak egyszer akarunk lefuttatni, valószínűleg nem sok értelme van automatizálni. Ha viszont minden release-nél, több platformon és több készüléken szeretnénk ugyanazt a folyamatot ellenőrizni, az egyenlet nagyon gyorsan megváltozik.
Az automatizálás ezért nem az első futtatásnál térül meg, hanem a 20.-nál, az 50.-nél vagy a 100.-nál.
A tesztautomatizálás megtérülése: mikor éri meg és hogyan számoljuk ki?
A tesztautomatizálás megtérülése kulcskérdés minden vállalat számára. Bemutatjuk azokat a tényezőket, amelyek befolyásolják a ROI-t, mikor érdemes beruházni, és hogyan kerülhetők el a leggyakoribb buktatók…
Mikor automatizálható jól egy mobilalkalmazás?
A jó automatizálás jóval a tesztek előtt kezdődik. Van azonban egy feltétel: az alkalmazásnak automatizálhatónak kell lennie.
Mik ennek a feltételei?
1. Már a fejlesztési fázisban gondolunk rá.
Ez triviálisnak hangzik, de a gyakorlatban rengeteg későbbi probléma már a tervezési és fejlesztési fázisban eldől.
2. Egyedi azonosítókat használunk benne.
Egy mobilalkalmazást úgy is meg lehet építeni, hogy a tesztautomatizálás számára stabil, jól azonosítható és kiszámítható felületet adjon, és lehet úgy is, hogy minden apró UI-változás után fél napot kell tölteni a tesztek javításával.
Vegyünk egy nagyon egyszerű példát: Ha egy gomb stabil, egyedi azonosítót kap, az automatizált teszt mindig ugyanazt az elemet fogja megtalálni. Ha nincs ilyen azonosító, a teszt elkezdhet szövegre, hierarchiára vagy más vizuális jellemzőre támaszkodni. Ez addig működik, amíg valaki át nem írja a gomb feliratát, meg nem változtatja a nyelvet vagy át nem rendezi a képernyőt. Egyetlen tesztnél ez apróság, de több száz vagy több ezer tesztnél már komoly karbantartási költség.
3. Következetes UI-struktúrát alkalmaznak.
Hasonlóan fontos, hogy az iOS- és Android-alkalmazás logikai struktúrája lehetőség szerint ne térjen el szükségtelenül egymástól. Nem kell minden pixelnek egyformának lennie, és természetesen a két platform saját UX-konvencióit sem érdemes figyelmen kívül hagyni, de ha ugyanaz az üzleti folyamat két teljesen eltérő struktúrában valósul meg, az automatizálási oldalon is sokkal több platformspecifikus logikára lesz szükség.
4. A komplexebb funkciókat már előre megtervezik.
A push notificationök, deep linkek, biometrikus funkciók, külső alkalmazásokkal történő interakciók vagy különböző jogosultságkérések szintén olyan területek, ahol a tesztelhetőség már a tervezési fázisban sokat nyerhet vagy veszíthet.
5. Támogató interfészeket építenek bele.
Egy tesztelést segítő technikai interfész is rengeteg automatizálási problémát megelőzhet.
A jó hír az, hogy ezeknek a döntéseknek nagy része nem jelent különösen nagy többletmunkát a fejlesztésben.
És ha az automatizálás nem volt része a tervezésnek?
Sok automatizálási projekt nem egy frissen induló alkalmazásnál kezdődik. Általában van már egy működő termék, több release van mögötte, kialakultak bizonyos technikai kompromisszumok, és valamikor később kerül elő az igény, hogy a regressziós tesztelés egy részét automatizálni kellene. Ilyenkor az a feladat, hogy a meglévő alkalmazást próbáljuk meg egy elfogadható mennyiségű ráfordítással automatizálhatóvá tenni.
Szerencsére általában nincs szükség ilyenkor teljes újratervezésre. A modern mobilautomatizálási keretrendszerek sok problémát önmagukban is képesek kezelni, és gyakran csak néhány kritikus területen van szükség fejlesztői támogatásra. Tipikus példa a stabil accessibility ID-k kialakítása, a notification flow-k tesztelhetővé tétele vagy bizonyos környezeti függőségek egyszerűbb vezérelhetősége.
Ebben ma már az AI-alapú fejlesztői eszközök is segíthetnek. Ezek elsősorban abban támogatják a fejlesztőket, hogy fel tudják készíteni az appokat a könnyű automatizálhatóságra. Mindez kevesebb erőforrással jár a részükről, bár fontos, hogy ilyenkor a tesztelők minden esetben a fejlesztőkkel szorosan együttműködve határozzák meg, mely területeken szükségesek módosítások. A tesztelők felelőssége a módosítások összegyűjtése, a fejlesztőké pedig a megvalósítás a meglévő frameworkben.
Mivel érdemes automatizálni a mobilteszteket?
A mobilteszt-automatizálás során gyakori téma az eszközválasztás. Appium, native frameworkök, különböző cross-platform megoldások, más-más futtatási és integrációs lehetőségek merülnek fel ilyenkor. Természetesen fontosak a technikai szempontok, de az eszköz önmagában ritkán dönti el egy automatizálási projekt sikerét.
Egy konkrét, gyakran használható technológiai stack például az Appium, a WebdriverIO és a TypeScript kombinációja. Ez a stack egy frameworkb integrálható Playwright alapú web UI és API tesztekkel, ami jelentősen segíti az esetleges e2e automata tesztek fejlesztését. Az Appium segítségével iOS- és Android-alkalmazások egyaránt vezérelhetők, a WebdriverIO jól használható keretet ad a tesztek szervezéséhez és futtatásához, a TypeScript pedig nagyobb tesztkódbázis esetén típusbiztonsággal és jól strukturálható fejlesztési környezettel segít.
Ez azonban csak egy lehetséges technológiai választás. A jó döntéshez figyelembe kell venni a csapat tapasztalatát, a meglévő fejlesztési stacket, a CI/CD-környezetet, az alkalmazás technikai felépítését és természetesen azt is, milyen hosszú távú automatizálási stratégiát szeretnénk kialakítani.
Szoftvertesztelési eszközök a gyakorlatban – Mi alapján válasszunk?
Selenium, Playwright, Appium, JMeter vagy k6? Gyakorlati útmutató ahhoz, hogyan válassz fenntartható teszteszközt KKV-ban vagy nagyvállalatnál.
Ennél egy sokkal fontosabb kérdés, hogyan építjük fel magát a tesztrendszert.
1 alkalmazás, 2 platform: lehetőleg ne két teljes tesztkód legyen
A legkézenfekvőbb megoldás természetesen az lenne, hogy írunk egy tesztcsomagot Andoridra, majd egy másikat iOS-re. Néhány hónappal később világos lesz, hogy minden üzleti változást két külön tesztkódban kell módosítani.
Egy jobb architektúrában az üzleti logikát lehetőség szerint egyben kezeljük, és csak azt választjuk külön, ami ténylegesen platformspecifikus. Például maga a teszt mondhatja egyszerűen azt, hogy a felhasználó jelentkezzen be, nyissa meg a profilját és módosítsa a nyelvi beállítást:
await loginPage.login(user);
await homePage.openProfile();
await profilePage.changeLanguage(„English”);
A teszt szempontjából lényegtelen, hogy az adott gomb iOS-en milyen locatorral található meg, és Androidon pontosan hol helyezkedik el a UI-hierarchiában. Ezt a platformspecifikus rétegnek kell kezelnie.
Ennek a megközelítésnek nemcsak az az előnye, hogy kevesebb kódot írunk. Ennél fontosabb, hogy az üzleti folyamat változása esetén egy helyen tudunk módosítani. A platformkülönbségek nem szivárognak be minden egyes tesztesetbe, így a rendszer hosszabb távon lényegesen könnyebben karbantartható.
Itt jelennek meg igazán a klasszikus automatizálási tervezési minták: page vagy screen objectek, közös üzleti rétegek, platform adapterek, tesztadat-kezelés és konfigurációs absztrakciók.
Amikor már van 500 tesztünk, előkerül egy új probléma
Tegyük fel, hogy a framework elkészült, az alkalmazás megfelelően tesztelhető, és idővel felépült 500 automatizált tesztesetünk. Egyenként 1,5 perc alatt futnak le. Ez egymás után több mint 12 óra. Tehát sikeresen automatizáltunk egy olyan regressziós tesztet, amelynek az eredményét csak másnap reggel kapjuk meg. Technikailag működik, de egy gyors fejlesztési folyamatban nem különösebben hasznos. Innen válik a párhuzamosítás az automatizálási stratégia alapvető részévé.
Ha ugyanazt az 500 tesztet 10 eszközön párhuzamosan futtatjuk, a végrehajtási idő nagyságrendileg a tizedére csökkenhet. Ha 20 vagy 30 párhuzamos sessionünk van, tovább rövidülhet a visszajelzési idő. Minél hamarabb kapja meg a fejlesztőcsapat a teszteredményt, annál hamarabb tud reagálni a hibára. Egy néhány perces vagy félórás feedback loop még ugyanahhoz a fejlesztési kontextushoz tartozik. Egy másnap reggel érkező teszteredmény már jóval kevésbé. Rögtön felmerül a következő kérdés: hol fusson ennyi teszt?
Mit válasszunk, ha mobil appot tesztelnénk: Emulátor, saját eszközpark vagy cloud device farm?
Ez több mindentől függ, mivel mindhárom megoldás más problémára nyújt jó megoldást. Mielőtt szolgáltatót választunk, ezeket a szempontokat érdemes megvizsgálni:
- Mennyire kalkulálhatóak előre a költségek és persze mennyire magasak
- Milyen karbantartást, üzemeltetést igényelnek?
- Mennyire platformhűek?
- Mennyire integrálhatóak a CI/CD-be?
Íme egy összesítés arról, mit érdemes tudni a fentiekről.
Mobil tesztelési infrastruktúrák PRO és KONTRA – Emulátor, saját eszköz vagy cloud farm
| Szempont | Emulátor / Szimulátor | Saját eszközpark | Cloud device farm |
| Költségek | – Alacsony és jól kalkulálható – Alacsony hardverköltség | – Magas rejtett költségek (beszerzés, amortizáció, kieső mérnökórák) | – Magasabb, fix licenc- vagy használatarányos díj |
| Karbantartás és üzemeltetés | – Minimális – Szoftveresen, automatizáltan kezelhető | – Nagyon magas (töltés, frissítés, fizikai tárolás, hálózati hibák elhárítása) | – Nulla (mindent a szolgáltató üzemeltet és frissít) |
| Valós működés leképezése | – Közepes/Alacsony – Nem mutatja ki a hardveres és gyártóspecifikus hibákat | – Maximális – Valós hardveres környezet és fizikai működés | – Maximális – Valós fizikai eszközök és operációs rendszerek széles skálája |
| Skálázhatóság és CI/CD integráció | – Kiváló – Gyorsan indítható, tetszőleges számban párhuzamosítható | – Korlátozott – A fizikai eszközök száma és instabilitása szűk keresztmetszet lehet | – Kiváló – Rendkívül gyors visszajelzés a nagy párhuzamosság miatt |
| Összeségében mikor a legjobb választás? | – Fejlesztés közbeni gyors tesztelésre – Korai regressziós körökhöz | – Néhány stratégiailag kiemelt fontosságú eszköz állandó tesztelésére | – Széles körű kompatibilitási tesztekre – Ritkább eszközök lefedésére |
Emulátorok és szimulátorok
Az emulátorok és szimulátorok gyorsan indíthatók, könnyen skálázhatók, és a tesztek nagy részére teljesen megfelelőek lehetnek. A fejlesztési és korai regressziós körökben különösen jól használhatók, hiszen olcsón és rugalmasan futtatható belőlük sok példány. Ugyanakkor nem minden problémát képesek valósághűen reprodukálni.
Bizonyos hardveres és eszközspecifikus funkciók (például a kamera, a biometrikus azonosítás, egyes szenzorok, NFC vagy Bluetooth) emulált környezetben csak korlátozottan, szimulált módon vagy egyáltalán nem tesztelhetők ugyanúgy, mint valódi készüléken. Ugyanez igaz egyes gyártóspecifikus sajátosságokra, teljesítményproblémákra és rendszerintegrációkra is, amelyek megbízható ellenőrzéséhez továbbra is fizikai eszközre van szükség.
Saját eszközpark farmok
Ezeket a hiányosságokat fedhetjük le saját fizikai eszközparkkal. Néhány stratégiailag fontos készülék fenntartása sok projektben teljesen ésszerű. A nehézségek akkor kezdődnek, amikor az öt telefonból 20 vagy 30 lesz. Ezeket meg kell vásárolni, tárolni, tölteni, frissíteni, konfigurálni és folyamatosan elérhetővé tenni a CI/CD pipeline-ban. A mobiltelefon sajnálatos módon nem tud arról, hogy ő egy kritikus CI infrastruktúra része, ezért néha egyszerűen úgy dönt, hogy egy frissítés után nem csatlakozik többé ugyanúgy, mint tegnap. Egy bizonyos méret fölött tehát a saját device lab már egy külön üzemeltetendő infrastruktúra.
Cloud device farmok
A harmadik lehetőség a cloud device farm, például BrowserStack, TestMU.AI (korábban LambdaTest) vagy Sauce Labs használata. Itt a szolgáltató biztosítja a fizikai készülékeket és az infrastruktúra jelentős részét, miközben a tesztek több eszközön, akár nagy párhuzamossággal futtathatók. Ez természetesen licencköltséggel jár, ezért gyakran felmerül a kérdés: olcsóbb-e saját telefonokat venni? A pontos válaszhoz minden költséget figyelembe kell vennünk. Egy telefon beszerzési árát a tervezett élettartam hónapjaira elosztva összevethetjük egy cloud szolgáltatás havi licencdíjával, de ez önmagában még nem mutatja meg a teljes költséget.
Saját eszközpark esetén a teljes költséghez hozzátartozik az eszközök beszerzése, amortizációja és cseréje, az infrastruktúra, az üzemeltetés, az OS-frissítések kezelése, a hibák és természetesen az a mérnöki idő is, amelyet mindez elvisz. Cloud device farm esetén a költség jellemzően licencből, a szükséges párhuzamosságból és adott esetben a használati volumenből áll össze.
A ROI-számításnál fontos szempont a gyorsabb visszajelzés értéke is. A tesztek párhuzamosításával jelentősen csökkenthető az átfutási idő, így a fejlesztők hamarabb értesülnek a hibákról, és a release folyamat is felgyorsulhat. A párhuzamosítás azonban nem kizárólag a cloud device farmok előnye, saját eszközparkon és virtualizált környezetben is megvalósítható.
Az optimális infrastruktúra mindig a tesztelési igényektől függ. Például a fejlesztés közbeni tesztelés történhet emulátorokon és szimulátorokon, míg a regressziós tesztek saját fizikai eszközökön vagy cloud device farmon futhatnak. A cél nem feltétlenül a különböző megoldások kombinálása, hanem a megfelelő lefedettség, futási kapacitás és visszajelzési idő biztosítása.
A megfelelő infrastruktúra tehát attól jó, hogy összhangban van a szükséges lefedettséggel, futási gyakorisággal és visszajelzési idővel.
A nagy mennyiségű automatizált tesztkészlet karbantartása
Ha mindez jól működik, felmerül egy újabb kérdés: Hogyan tartsuk karban azt a több 100 vagy több 1000 tesztet, amelyet korábban automatizáltunk?
Az alkalmazás ugyanis mindeközben tovább fejlődik. Új képernyők jelennek meg, mások átalakulnak, új készülékek és operációsrendszer-verziók kerülnek piacra. A tesztkód pedig – ugyanúgy, mint bármely más szoftver – technikai adósságot tud felhalmozni. Ha minden kisebb UI-változás több tucat teszt módosítását okozza, vagy egy új platformverzió miatt minden második futás instabillá válik, akkor a kezdetben megtakarított idő egy része lassan visszaszivárog karbantartási költségként.
Egy érett mobilautomatizálási rendszerben ezért arra érdemes nagy hangsúlyt fektetni, hogy hogyan tegyük az automatizálást alkalmazkodóbbá. Hogyan csökkentsük a platformspecifikus logika mennyiségét, hogyan válasszuk ki a futtatási környezeteket, hogyan kezeljük az eltérő eszközöket, és hogyan reagáljunk az alkalmazás változásaira kevesebb manuális beavatkozással.
Hol kell automatizálni és mikor maradjunk a manuális teszteknél?
A mobilalkalmazások tesztelésében továbbra is van helye a manuális tesztelésnek, hiszen vannak olyan területek, ahol továbbra is az emberi megfigyelés, az exploratív tesztelés vagy az üzleti gondolkodás tud jobb eredményt hozni. Ott viszont, ahol a feladat ismétlődő, jól definiált és sokszor kell végrehajtani, jöhet az automatizálás. Mobilalkalmazásoknál pedig ebből általában nincs hiány.
Ha jól automatizálunk, az első befektetés után minden következő futás egyre olcsóbbá válik. És talán ez a mobil tesztautomatizálás legfontosabb gazdasági tulajdonsága: nem feltétlenül az első teszten spórolunk sokat, hanem azon, hogy ugyanazt a munkát többé nem kell századszor is ugyanúgy elvégezni.
FAQ
1. Hogyan csökkenthető a mobil tesztautomatizálás karbantartási költsége iOS és Android platformon?
A karbantartási költség jellemzően akkor nő meg gyorsan, ha az iOS- és Android-tesztek külön logikára épülnek, és minden változást több helyen kell követni. Fenntarthatóbb megoldás, ha a közös üzleti folyamatok egységes tesztrétegben maradnak, és csak a platformspecifikus elemek válnak külön. Ezt tovább támogatja a stabil UI-azonosítók használata és az, ha az automatizálás a magas üzleti értékű, stabil folyamatokra koncentrál.
2. Milyen üzleti előnye van a párhuzamos mobilteszt-futtatásnak a release sebesség és a hibafelismerés szempontjából?
A párhuzamos futtatás jelentősen lerövidíti a visszajelzési időt, így egy többórás regresszió percekre vagy néhány tíz percre csökkenthető. Ez üzleti szempontból azért fontos, mert a csapat gyorsabban reagál a hibákra és kevesebb a várakozás a release folyamatban. Minél gyorsabb a teszteredmény, annál jobban támogatja az automatizálás a gyakori kiadásokat és a kiszámítható deliveryt.
3. Milyen szempontok alapján érdemes mobilapp-tesztelési szolgáltatót választani?
Mobilapp-tesztelési szolgáltató választásakor a tesztelési referencián túl érdemes azt is nézni, hogy a szolgáltatása mennyire illeszkedik a projekt működéséhez. Fontos szempont a szükséges lefedettség, a futtatási gyakoriság és az elvárt visszajelzési idő. Emellett érdemes viszont figyelembe venni a szolgáltatási modellt, az eszköz- és infrastruktúra-hátteret, a karbantartási felelősséget, a CI/CD integrálhatóságot, a riportálást, a biztonsági és megfelelőségi szempontokat, a szakmai referenciákat és a skálázhatóságot is.
Szerző: Nagy Győző, tesztautomatizáló architekt
