Mobil tesztautomatizálási kihívások

Amikor a TenKodnál kezdtem dolgozni automatizálási megoldásokon, a mobilok már a napi élet részei voltak és csilli-villi mobil alkalmazások jelentek meg napról napra. Arra kerestük a választ, hogyan segíthetünk a vállalatoknak a robusztus automatizálási projektek minél egyszerűbb és gyorsabb megoldásában. Azt láttuk, hogy a mobil teszt automatizálás implementálása gyakran sokkal nagyobb erőfeszítéssel jár, mint maga az alkalmazás kifejlesztése. Akarod tudni, hogy mi ennek az oka? Ha igen, akkor jó helyen jársz! Mivel elég sok ilyen kihívással találkoztunk már, azt gondoljuk, hogy olyan tapasztalatokat tudunk megosztani, amik igenis értékesek lehetnek a számodra.

Válaszd ki a megfelelő eszközt

Az első kihívás, amivel valószínűleg találkozni fogsz, hogy megtaláld a megfelelő eszközt a teszteléshez. A rengeteg mobilkészülék, képernyőfelbontás és operációs rendszer miatt annyira nem triviális a feladat. Az automatizált tesztek futtatása az összes típusú mobilon ugyanazzal a megoldással gyakorlatilag lehetetlen. Rá kell szánnod egy kis időt, hogy meghatározd, kik (kik lesznek) a felhasználók és ők milyen készülékeket használnak (fognak használni) leggyakrabban. Az ökölszabály az, hogy válasszuk ki az 5 leggyakrabban használt mobilkészüléket, a többit pedig szimulátoron keresztül teszteljük.

Az első kihívás, amivel valószínűleg találkozni fogsz, hogy megtaláld a megfelelő eszközt a teszteléshez. A rengeteg mobilkészülék, képernyőfelbontás és operációs rendszer miatt annyira nem triviális a feladat. Az automatizált tesztek futtatása az összes típusú mobilon ugyanazzal a megoldással gyakorlatilag lehetetlen. Rá kell szánnod egy kis időt, hogy meghatározd, kik (kik lesznek) a felhasználók és ők milyen készülékeket használnak (fognak használni) leggyakrabban. Az ökölszabály az, hogy válasszuk ki az 5 leggyakrabban használt mobilkészüléket, a többit pedig szimulátoron keresztül teszteljük.

Válasszunk szoftvert

Most következik a kód megírása, amely a következő fejtörést okozza majd – melyik szoftvert használjuk az automatizált megoldás megírásához? Rengeteg nyílt forráskódú és fizetős megoldás elérhető a piacon és a legtöbb nyílt forráskódú (mint például az Appium, Selendroid Robotium) rendelkezik automatizáló keretrendszerrel, ami alkalmas a tesztek implementálására. De sajnos egyelőre nincsenek integrált fejlesztői környezetek, amik lefedik a teljes tesztelési életciklust (tervezés, fejlesztés, futtatás, karbantartás). Így tehát az összes ilyen megoldásnak megvan a maga kelepcéje, ami az igazán nagy erőfeszítést jelentheti, mire megtaláljuk az aktuális konfigurációs beállításokat, amikre szükségünk lesz.

A fizetős megoldások legtöbbje már fel van készítve erre, de ott következik az újabb fejtörés, a „vendor-lock”. Más szóval egy fizetős megoldás nehezen, vagy egyáltalán nem integrálható a meglévő rendszerekhez, illetve csak a szállító

által meghatározott szoftverekkel működik együtt és ad teljes funkcionalitást. Ezek a szállítók minden esetben csodát ígérnek, de csendben azt kérik, hogy „finomhangold” az alkalmazást hozzájuk, vagy jailbreak-eld a készüléket amelyen tesztelsz.

A „finomhangolás” azt jelenti, hogy egy bizonyos előre megadott kódsort tegyünk be a tesztelt alkalmazásba a tesztelhetőség és kompatibilitás biztosításához, a jailbreak pedig megsérti az eszköz szolgáltatási feltételeit (terms of service). Mindkét megoldás erősen ellenjavallt és a legtöbb esetben ezt a vállalatok egyszerűen nem is vállalják be.

Rögzítsd és ne játszd vissza

és belőlük automatizált tesztek gyártására. Ezek a lehetőségek bár igen csábítóak, de minden esetben alaposan meg kell vizsgálni az általuk generált kódok minőségét. A legtöbbször ezek egyáltalán nem fejlesztőbarát megoldások és a későbbiekben igen nehéz változtatni rajtuk, amennyiben az üzleti logika változik. Ilyen esetekben általában nem marad más megoldás, mint a tesztek újbóli nulláról való elkészítése. Ez néhány tesztesetnél még kezelhető, de robusztus automatizált megoldásoknál igen időigényes és elveszi az időt a további fontos tesztek megírásától. A legjobb megoldás az volna, ha ezekkel a megoldásokkal létre lehetne hozni olyan teszteket, amelyeknek a kódjai olvashatók és karbantarthatók. Ez lehetőséget adna arra, ha az alkalmazás változik, néhány sor hozzáadásával vagy módosításával a tesztet hozzá lehetne igazítani és karban lehetne tartani.

Ha a tesztek elkészültek, futtatni kell őket az elvárt gyakorisággal a regressziós esetek minél korábbi feltárására. A 21. század emberének elvárása, hogy ezek a tesztek automatizáltak legyenek. Itt jönnek képbe a folyamatos integrációt támogató eszközök (Jenkins, TeamCity) ezeket a megoldásokat lehet úgy paraméterezni, hogy az automatizált tesztek minden változtatás után, vagy minden release után ütemezetten lefussanak.Amikor egy szemináriumra, vagy előadásra megyek, előbb utóbb jön a kérdés: „Szóval, ki merre dolgozik?” A válaszom azoknak akik nem járatosak az online kaszinók területén ismeretlenül hangzik, mert még nem hallottak a NetEnt-ről. Amikor leesik nekik, jön a felismerés: „Ja, Te csak egy játéktesztelő vagy!” Ilyenkor mosolyogni szoktam a megvető pillantásokon abban a tudatban, hogy túl sok energiámba telne elmagyarázni, hogy én ugyanolyan jó tesztelő vagyok, mint ők!

A hétköznapi munkában a hibák és a regressziós kérdések mindennaposak, szóval ezek a tesztek biztosan le fognak állni. A hibák feltárásában nagy segítség a teszt riport, amely a lehető legalacsonyabb szinten adja meg, hogy mely tesztek futottak le sikeresen és melyek álltak le. Álmodhatunk képernyő mentésekről a tesztfuttatások során, valamint automatikus videofelvételekről is. A modern folyamatos integrációt támogató eszközök az egyszerű riportokat alapból támogatják és elég flexibilisek ahhoz, hogy a kívánt többlet kimeneteket könnyen lehessen paraméterezni, vagy kódolni a keretrendszerükbe.

Konklúzióként a mobil alkalmazások automatizált tesztelésének még nagyon sokat kell fejlődnie, mire eléri az asztali- és webes alkalmazások automatizált szintjét. A fejlődés ebben a szakaszában még azt javasoljuk, hogy igen körültekintően kezdjünk neki a mobil applikációk automatizált tesztelésének.

Körültekintő eszközválasztás

Úgy válasszunk eszközt, hogy az a legmesszemenőbbekig támogassa az aktuális mobilalkalmazás automatizált tesztelését, ne legyenek benne elkötelezettségek a gyártó felé és egyéb trükkös kötöttségek.

Az automatizált tesztek rögzítéséhez olyan nyílt forráskódú vagy fizetős eszközt válasszunk, amelyben a rögzített automata aktivitások kódjai könnyen olvashatók, változtathatók és karbantarthatók.

Győződjünk meg arról, hogy a kiválasztott megoldás integrálható-e a meglévő környezetbe és könnyen alkalmazkodik-e a mobil alkalmazás folyamatos változásához.

A legtöbb, mobil alkalmazásokkal foglalkozó vállalat komolyan veszi és invesztál az mobil automatizálásba, ezért mindenkit arra buzdítok, hogy kezdje el beépíteni a hétköznapi munkájába az itt olvasott ajánlásokat!

Forrás: http://www.ministryoftesting.com/2014/10/got-mobile-test-automation-challenges/
Szerző: Danail Branekov, Emil Simeonov