Egy működő bemutató még nem mutatja meg, hogyan viselkedik az app különböző telefonokon vagy szokatlan használat közben. Bemutatjuk, hogyan ellenőrzünk a specifikációtól az ügyféltesztig, és miért vizsgáljuk újra a kapcsolódó funkciókat is egy javítás után.
Egy alkalmazás bemutatóján minden működhet: be lehet lépni, betöltődnek az adatok, végig lehet menni a fő funkciókon. Az átadás előtt azonban azt is meg kell vizsgálni, hogyan viselkedik az app különböző telefonokon, meglévő felhasználói adatokkal vagy szokatlan használat közben.
Nálunk előfordult, hogy a képernyő biztonságos megjelenítési területének, a safe area kezelésének változása miatt elcsúszott egy felületi elem. Egy B2B-projektnél pedig a tesztelés során derült ki, hogy a Firebase-beállítások között még tesztkörnyezeti kulcs szerepel az éles helyett. Ezt a push értesítések későbbi ellenőrzése is felszínre hozta volna, de már korábban észrevettük.
Ezek hétköznapi példák arra, miért kell az elkészült funkciók mellett a megjelenítést és a kiadási beállításokat is ellenőrizni.
A Petadevnél a mobilalkalmazás tesztelése a fejlesztési munka része. A specifikáció alapján ellenőrzünk, valódi készülékeken tesztelünk, hibás használati helyzeteket idézünk elő és a javítások után visszatérünk a kapcsolódó funkciókhoz is. A projekt igényeihez igazodva ezt fejlesztés közben futó automatizált tesztek és szélesebb felhasználói próbák egészíthetik ki.
Röviden: hogyan jutunk el az átadásig?
- Specifikáció szerinti ellenőrzés: elkészültek-e a vállalt funkciók és megfelelően működnek-e?
- Tesztelés valódi készülékeken: ugyanazt a funkciólistát különböző iOS- és Android-eszközökön is végigvesszük.
- Hibás és szokatlan helyzetek vizsgálata: eltérünk az elvárt használattól, meglévő rendszer mellett pedig korábbi felhasználókkal is próbálunk.
- Javítás és újratesztelés: először az érintett és kapcsolódó részeket ellenőrizzük, majd a javítási kör végén ismét a teljes funkciólistát.
- Külső tesztelők és ügyfélteszt: az alkalmazást olyanok is kipróbálják, akik nem a fejlesztésén dolgoztak.
- Kiadási ellenőrzés: publikálás előtt a kiadandó verziót, az éles környezetet és az áruházi beállításokat is átnézzük.
Először azt ellenőrizzük, amiben megállapodtunk
Az átadás előtti ellenőrzés kiindulópontja a fejlesztési specifikáció. Végignézzük, elkészültek-e a vállalt funkciók és az egyeztetett működést adják-e.
Ez két külön kérdés. Egy funkció megjelenhet az alkalmazásban úgy is, hogy valamelyik fontos helyzetet még nem kezeli megfelelően.
Egy feltöltésnél például más ellenőrzés, hogy elérhető-e a feltöltési lehetőség és más, hogy a felhasználó végig tudja-e vinni a műveletet, majd látja-e annak eredményét. A vizsgálandó eseteket mindig az adott alkalmazás működéséhez kell igazítani.
A funkciólista nálunk a készülékeken végzett tesztelésnek is alapja. Így ugyanazokon a vállalt funkciókon megyünk végig a különböző teszteszközökön.
Miért fontos a valódi telefonokon végzett tesztelés?
A gyakorlatunkban nagy hangsúlyt kap a fizikai készülékeken végzett kézi tesztelés. Androidos telefonokkal és iPhone-okkal is dolgozunk és folyamatosan frissítjük a tesztkészülék-állományunkat.
Arra törekszünk, hogy az előző három-négy iOS- és Android-főverzióból is legyen lefedettségünk, eltérő képernyőméretű és hardverű eszközökkel. A támogatott rendszerverziókat és a vizsgált eszközkört az adott projekthez kell igazítani.
A safe area problémája jól mutatja ennek jelentőségét. A felület kialakításakor figyelembe kell venni például a kijelzőkivágás és a rendszer kezelőszervei körüli területet. Egy megváltozott működés miatt olyan elem is rossz helyre kerülhet, amely korábban megfelelően jelent meg.
Egyetlen telefonon sikeresen végigpróbált alkalmazásból nem következik, hogy a többi támogatott eszközön is megfelelő a működés.
Szándékosan eltérünk a normál használattól
A felhasználó nem feltétlenül abban a sorrendben és olyan adatokkal használja az alkalmazást, ahogyan a bemutatón látta.
Ezért a tesztelés során szándékosan próbálunk előidézni hibás vagy szokatlan helyzeteket. Olyan eseteket is keresünk, amelyek korábbi fejlesztési tapasztalataink alapján problémát okozhatnak. A kérdés ilyenkor az: hogyan viselkedik az alkalmazás, ha megpróbálunk eltérni az elvárt működéstől?
A projekthez igazított vizsgálatok között például ilyen kérdések merülhetnek fel:
- Mit tesz az alkalmazás hiányos vagy hibás adat megadásakor?
- Mi történik, ha a felhasználó megszakít egy folyamatot, majd újra elindítja?
- Hogyan reagál az app ismételt műveletre vagy váratlan sorrendre?
- Érthető-e a visszajelzés, amikor a feladat nem hajtható végre?
A korábbi hibákból szerzett tapasztalat itt közvetlenül hasznosul: segít kiválasztani, mely szokatlan helyzeteket érdemes megvizsgálni az adott alkalmazásban.
Meglévő rendszer mellett a régi felhasználókat is vizsgálni kell
Ha egy mobilalkalmazás már működő rendszerhez kapcsolódik, külön figyelmet fordítunk a meglévő felhasználókra.
Egy újonnan létrehozott tesztfiók ellenőrzése nem mutatja meg, hogy a korábban regisztrált felhasználó adatai is megfelelően elérhetők és jól jelennek-e meg az új alkalmazásban.
A meglévő webáruház mellé készített webshopappunknál ezért régi és új felhasználókkal egyaránt teszteltünk. Meg kellett nézni, hogy az alkalmazásban szükséges meglévő adatok átjönnek-e és megfelelően jelennek-e meg a mobilos felületen.
Itt a tesztelés tárgya a meglévő és az új rendszer együttműködése is. Az alkalmazás használhatóságához az is hozzátartozik, hogy a korábbi felhasználó a saját adataival tudjon továbblépni.
Egy javítás után a kapcsolódó részekhez is visszatérünk
Amikor javítunk egy hibát, először az érintett funkciót és a hozzá kapcsolódó részeket teszteljük újra.
A javított hiba ellenőrzését megerősítő tesztelésnek nevezik. A regressziós tesztelés pedig azt vizsgálja, okozott-e a változtatás problémát korábban működő részekben. A két ellenőrzés más kérdésre válaszol, ezért mindkettőnek szerepe van.
Nálunk a javítási kör lezárása után az alkalmazás ismét teljes, funkciólista szerinti tesztelést kap a teszteléshez használt készülékeken. Ez ad keretet annak, hogy az egyes javítások után az alkalmazást újra egészében is ellenőrizzük.
Automatizált ellenőrzés már fejlesztés közben
Bizonyos projekteknél már a fejlesztés során automatizált teszteket készítünk a fontosabb alapfunkciókhoz tartozó kódrészletekre. Ehhez Jestet használunk, amely megfelelő beállítással a kód módosítása után automatikusan újrafuttatja a teszteket.
Egy egységteszt például a regisztrációhoz tartozó adatellenőrzést vizsgálhatja: elfogadja-e a megfelelő adatokat és elutasítja-e a hibásakat. A teljes regisztrációs folyamat kipróbálásakor már több összetevő együttműködését is ellenőrizni kell.
Nagyobb, rendszeresen továbbfejlesztett alkalmazásoknál kifejezetten ajánljuk az automatizált tesztek használatát. Ha például negyedévente új funkciók készülnek, a módosítások korábbi működésre is hatással lehetnek. A megírt tesztek gyorsan jelezhetik, ha valamelyik ellenőrzött eset már nem a várt eredményt adja.
Az előny ilyenkor a korai visszajelzés: a fejlesztő már munka közben észreveheti a problémát és vissza tud térni az érintett kódrészlethez. Ez csökkenti annak kockázatát, hogy egy korábban működő rész hibája észrevétlenül maradjon.
Az automatizált tesztek a megírt eseteket ellenőrzik. A fizikai készüléken végzett próba pedig a tényleges használatról, a megjelenítésről és a felhasználói élményről is ad visszajelzést. A két megközelítést együtt használjuk az adott projektben vállalt keretek között.
Ki tesztel és mikor kapcsolódik be az ügyfél?
A csapatunkban van olyan kolléga, akinek a fejlesztés mellett a tesztelés és a felhasználói élmény vizsgálata is feladata. A végső ellenőrzésbe külső, nem fejlesztő tesztelőket is bevonunk.
Ez azért hasznos, mert ők nem a megvalósítás ismeretében közelítenek a felülethez. A visszajelzéseikből az is kiderülhet, hogy ami a fejlesztőcsapatnak magától értetődő, a felhasználónak mennyire érthető.
Az ügyfél a fejlesztés korábbi szakaszaiban is használhatja az alkalmazást, de ekkor még egy készülő verziót lát. A végső saját tesztelésére azután kapja meg, hogy a belső és külső ellenőrzéseket elvégeztük és az azok során feltárt hibákat javítottuk.
Az ügyfélteszt előtt tehát már végigmegyünk a saját ellenőrzéseinken. Az ügyfél ezután a saját munkafolyamatai és használati helyzetei alapján tud visszajelzést adni.
Több tesztelő többféle használatot jelent
A szélesebb felhasználói kipróbálás megszervezése a rendelkezésre álló kerettől is függ. Ha belefér, fizetett csoportos tesztelés is bevonható. Más esetben az ügyfél munkatársai vagy ismerősei segíthetnek további használati helyzeteket kipróbálni.
Érdemes olyan résztvevőket is bevonni, akik hasonlítanak az alkalmazás leendő felhasználóira. Az ő visszajelzéseik közelebb vihetnek ahhoz, hogyan fogják ténylegesen használni a kész terméket.
A csoportos kipróbálás a különböző használati helyzetek és a felület érthetőségének vizsgálatát segíti. A nagy számú egyidejű kérés kiszolgálását külön technikai terhelésvizsgálattal lehet ellenőrizni.
Mit ellenőrzünk közvetlenül a publikálás előtt?
Az alkalmazás működésének ellenőrzése mellett a kiadás összeállítását is át kell nézni. A korábban említett Firebase-kulcsos eset is ebbe a körbe tartozott.
A kiadás előtti ellenőrzéseink fő pontjai:
| Ellenőrzési pont | Mit nézünk meg? |
|---|---|
| Éles kulcsok és beállítások | A kiadásra szánt konfigurációban az éles használathoz tartozó kulcsok szerepelnek-e? |
| Production backend | Az alkalmazás a megfelelő éles háttérrendszerhez kapcsolódik-e? |
| A kiadandó verzió | Valóban a legutóbb letesztelt verzió kerül-e kiadásra? |
| Verziószám és buildszám | A kiadás verzióazonosítói megfelelőek-e? |
| Aláírás | A kiadáshoz megfelelő aláírási beállítások és profilok vannak-e használatban? |
| Áruházi adatok | A publikáláshoz megadott adatok érvényesek és megfelelőek-e? |
| iOS-beállítások | Az Info.plist alkalmazásbeállításait is átnézzük. |
A kiadás előtt az is kérdés, hogy pontosan melyik verziót, milyen beállításokkal készülünk a felhasználókhoz eljuttatni. Ezért a publikálási ellenőrzés a funkcionális tesztelés mellett külön figyelmet kap.
Mi tartozik bele a fejlesztési ajánlatba?
A leírt kézi tesztelés része az alap fejlesztési ajánlatunknak. A saját ellenőrzéseinket és a feltárt hibák javítását elvégezzük, mielőtt az alkalmazást végső ügyféltesztre átadjuk.
A nagyobb volumenű, szervezett felhasználói és felülettesztelés, illetve a kiterjedtebb egységtesztelés további feladatot jelenthet. Ezeket ajánljuk és igyekszünk már a tervezéskor belekalkulálni a projektbe. Szűkebb keret esetén az extra vizsgálatok terjedelmét külön kell meghatározni.
Rendszeresen bővülő alkalmazásnál ezt a későbbi fejlesztési ütemmel együtt érdemes mérlegelni. A többször újrafuttatható teszteknek minden újabb módosításnál szerepük lehet a korábbi működés ellenőrzésében.
Mit jelent, hogy az alkalmazást leteszteltük?
Azt, hogy az egyeztetett működést meghatározott esetekkel, eszközökön és verziókon ellenőriztük, majd a feltárt hibák javítását is visszanéztük.
Az ISTQB egyik tesztelési alapelve szerint a tesztelés hibák jelenlétét mutathatja meg, a teljes hiányukat nem tudja igazolni. Ezért akkor sem mondjuk egy alkalmazásra, hogy „100%-os”, amikor már a fejlesztőcsapat, a külső tesztelők és az ügyfél is kipróbálta.
Megrendelőként érdemes konkrétan rákérdezni, mely funkciókat, milyen eszközökön és milyen használati helyzetekben vizsgálták; mi történik egy hibajavítás után; és mi tartozik a vállalt tesztelési feladatba. Ezekből látható, milyen munka áll az átadás mögött.
Ha még fejlesztőpartnert keresel, a mobilalkalmazás-fejlesztő cég kiválasztásánál a tesztelés és az átadás menetét is érdemes tisztázni. A teljes fejlesztési folyamatunkról a mobil app fejlesztési szolgáltatásunk oldalán olvashatsz.
Az átadás menetét is tervezzük meg az elején
Mondd el, mire használnák az alkalmazásodat, milyen eszközökön, és mely meglévő rendszerekhez kell kapcsolódnia. Ezek alapján a fejlesztés mellett a szükséges tesztelési feladatokat is át tudjuk beszélni.
