Folyamatellenőrzés: Az alkalmazás lépéseinek pontos ellenőrzése és fejlesztése

Lépésellenőrzés alkalmazás feladatok magánügyfeleknek

A Lépésellenőrzés alkalmazás akkor fontos, amikor egy mobilos vagy webes felületnél nem elég ránézni a képernyőkre, hanem végig kell menni minden felhasználói lépésen. A cél egyszerű. Kiderül, hol akad el a folyamat, melyik gomb nem érthető, mikor hibás az űrlap, és mikor nem azt kapja a felhasználó, amit vár. Magánügyfélként ez főleg akkor hasznos, ha van egy kész vagy félig kész alkalmazásod, prototípusod, megrendelői felületed, tanfolyami rendszered, rendelési folyamatod vagy belső használatra szánt kis alkalmazásod, és szeretnéd tudni, működik e a gyakorlatban.

Én azt látom, hogy sok ügyfél nem teljes tesztelést keres, hanem egy józan, lépésenkénti átnézést. Ez más, mint a fejlesztői ellenőrzés. A fejlesztő gyakran azt nézi, hogy a rendszer technikailag lefut e. A tesztelő szakember azt figyeli, hogy egy kívülálló ember megérti e, mit kell csinálnia. Ez nagy különbség. Egy jól elvégzett folyamatellenőrzés sok kellemetlen hibát kiszűr még azelőtt, hogy a felületet több ember használná.

A Qjob.hu felületén magánszemélyek is találhatnak olyan szabadúszót, aki távolról vállal ilyen munkát. A kapcsolatfelvétel, az anyagok átadása, a tesztelési lista egyeztetése és az eredmény küldése is történhet online. Nem kell személyes találkozó, mert a munka lényege a képernyők, útvonalak, űrlapok, gombok, jogosultságok és visszajelzések vizsgálata.

Lépésellenőrzés alkalmazás mikor indokolt

A lépésalapú alkalmazásteszt akkor indokolt, ha a felhasználónak több egymás utáni műveletet kell elvégeznie. Ilyen lehet a regisztráció, bejelentkezés, adatfeltöltés, rendelés, foglalás, fizetés előtti ellenőrzés, dokumentumküldés, kérdőív kitöltése vagy egy oktatási modul végigjárása. A hiba sokszor nem egyetlen képernyőn látszik. Csak akkor derül ki, amikor a felhasználó a harmadik vagy ötödik lépéshez ér.

Szerintem a leggyakoribb gond az, hogy a folyamat belül logikusnak tűnik, de kívülről nem az. A tulajdonos tudja, mit akart kérni az űrlap. A fejlesztő tudja, mi történik a gomb után. A felhasználó viszont csak azt látja, ami előtte van. Ha nincs világos visszajelzés, ha nem érthető a következő lépés, vagy ha egy hibaüzenet túl általános, akkor a folyamat könnyen megszakad.

Volt olyan eset, amikor egy ügyfél egy kis előfizetéses felületet akart ellenőriztetni. A rendszer első ránézésre működött. A gond csak akkor jelent meg, amikor valaki hibás e mail címet adott meg, majd visszalépett javítani. A javítás után az utolsó gomb már nem küldte tovább az adatokat. Ez nem látványos hiba, de éles használatban sok elveszett megrendelést okozhat. Az ilyen hibák miatt érdemes a felhasználói útvonalakat nemcsak egyszer, hanem több változatban is végigpróbálni.

Alkalmazás lépéseinek ellenőrzése és tipikus feladatok

Az alkalmazás lépéseinek ellenőrzése általában egy rövid egyeztetéssel indul. A megbízó átadja, milyen folyamatokat kell nézni, milyen eszközön, milyen hozzáféréssel, és mi számít jó eredménynek. Ezután a szabadúszó tesztelő végigmegy a megadott útvonalakon. Közben jegyzetel, képernyőképet készít, rögzíti a hibákat, és jelzi, ha valami nem egyértelmű.

A munka nem mindig csak hibakeresés. Gyakran értelmezési gondokat is feltár. Például túl hosszú mezőnév, rossz sorrend, félreérthető gombfelirat, hiányzó megerősítés, nem látható sikerüzenet, lassú átmenet vagy zavaró visszalépési lehetőség. Ezeket nem minden automatizált ellenőrzés veszi észre. Tapasztalatom szerint a kézi ellenőrzés különösen hasznos olyan felületeknél, ahol a használhatóság fontosabb, mint a puszta technikai lefutás.

Az árak tájékoztató jellegűek, de jól mutatják a különbséget egy rövid átnézés és egy részletes teszt között. A túl olcsó munka ezen a területen gyakran gyengébb minőséget jelent, mert a tesztelő nem tölt elég időt a kivételekkel. Pedig sok hiba nem az első próbánál jön elő, hanem akkor, amikor rossz adatot adunk meg, megszakítjuk a folyamatot, visszalépünk, vagy más sorrendben használjuk a képernyőket.

Lépésalapú alkalmazásteszt ára

A Lépésellenőrzés alkalmazás ára főleg attól függ, hány folyamatot kell átnézni, mennyire részletes a hibaleírás, és szükséges e több eszközön tesztelni. Egy rövid, egyképernyős ellenőrzés olcsóbb. Egy több szerepkörös rendszer, ahol más látszik a felhasználónak és más az adminisztrátornak, már több időt kér.

Sokan ott hibáznak, hogy csak darabszám alapján kérnek árat. Például azt mondják, hogy öt képernyőt kell ellenőrizni. De nem a képernyők száma a lényeg, hanem az útvonalak száma. Egyetlen képernyő is lehet bonyolult, ha sok mező, feltétel, hibaüzenet és visszalépési lehetőség van rajta. És tíz képernyő is lehet egyszerű, ha csak információt mutatnak.

Én korrekt árnak azt tartom, ahol a megbízásban benne van a tesztelési kör, az eredmény formátuma és legalább egy rövid összefoglaló. Ha csak annyi a vállalás, hogy megnézem és szólok, az kevés. A magánügyfélnek később is értenie kell, mit talált a szakember, hogyan lehet újra előidézni a hibát, és melyik gond sürgős.

Megfelelő tesztelő szakember kiválasztása

A megfelelő tesztelő szakember nemcsak hibát keres, hanem érthetően írja le, mi történt. Ez nagyon fontos, mert a hibajegy sokszor a fejlesztőhöz kerül tovább. Ha a leírás pontatlan, akkor a javítás is nehezebb lesz. Jó jel, ha a szabadúszó előre megkérdezi, milyen célcsoport használja az alkalmazást, melyek a legfontosabb folyamatok, és milyen eredményt vársz a munka végén.

Érdemes olyan embert választani, aki tud képernyőképpel, rövid videóval vagy lépéslistával dolgozni. Nem kell minden esetben hosszú jelentés. De kell átlátható eredmény. Egy jó tesztelő szakember meg tudja különböztetni a valódi hibát, a kényelmetlenséget és az ízlésbeli észrevételt. Ez segít abban, hogy ne apró részleteken menjen el az idő, hanem azokon a pontokon, amelyek tényleg rontják a használatot.

Portfóliónál nem mindig látványos képeket kell keresni. Hasznosabb, ha a szakember tud mutatni példát hibajegyzékre, ellenőrző listára vagy korábbi tesztelési leírásra. Magánügyfélként az is fontos, hogy egyszerűen kommunikáljon. Nem mindenki ért a fejlesztői nyelvhez. A jó szabadúszó le tudja fordítani a problémát hétköznapi mondatokra.

Online munkamenet és eredményátadás

Az online munkamenet akkor működik jól, ha a feladat elején tiszta a hozzáférés és a tesztelési cél. Kellhet próba felhasználói fiók, belépési adat, tesztkártya helyett biztonságos tesztkörnyezet, tervfájl, rövid leírás vagy előre megadott útvonal. Ha ezek hiányoznak, a munka lassul. Nem azért, mert a szabadúszó nem akar dolgozni, hanem mert találgatnia kell.

A folyamat általában négy részre bontható. Először a brief és az anyagok átvétele történik. Utána jön a tesztelési lista pontosítása. Ezt követi a tényleges ellenőrzés. Végül a szakember átadja az eredményt. Ez lehet táblázat, szöveges jegyzet, képernyőképes dokumentum vagy rövid videós magyarázat. A lényeg az, hogy a hiba újra előidézhető legyen.

Határidőnél a rövid feladatok gyakran egy vagy két napon belül elkészülnek. Összetettebb alkalmazásnál érdemes több napot hagyni, főleg ha javítás utáni újratesztelés is kell. Szerintem a túl gyors határidő itt kockázatos. A lépésellenőrzés nem csak kattintgatás. Figyelem kell hozzá, és néha második átnézés is, mert elsőre nem minden összefüggés látszik.

Minőségi gondok és gyakori ügyfélhibák

A leggyakoribb ügyfélhiba az, hogy nincs leírva, mi számít sikeres folyamatnak. Ha a tesztelő nem tudja, milyen eredményt kell elérni, akkor csak általános hibákat talál. Ez kevés. Egy rendelési folyamatnál például nem elég azt nézni, hogy a gomb működik e. Azt is látni kell, hogy a felhasználó kap e visszajelzést, mentődik e az adat, módosítható e a választás, és nem vesznek e el a korábbi lépések.

Másik gyakori gond a túl sok elvárás kis költségkeret mellett. Egy teljes mobilalkalmazás átnézése, több szerepkörrel, több eszközön, részletes jelentéssel nem fér bele egy nagyon alacsony összegbe. A túl olcsó ajánlat ilyenkor csábító, de gyakran csak felületes ellenőrzést jelent. Én inkább kisebb, pontosan meghatározott tesztkört választanék, mint egy nagy, de homályos vállalást.

A minőség ott látszik, hogy a hibák leírása használható e. Jó hibaleírásban szerepel a kiinduló helyzet, a pontos lépéssor, a várt eredmény, a tényleges eredmény és a bizonyíték. Nem kell bonyolult szakmai nyelv. Sőt, magánügyfélként jobb, ha a jelentés egyszerű. A fejlesztő mégis tudjon belőle dolgozni.

Alkalmazás folyamatellenőrzés javítás után

Az alkalmazás folyamatellenőrzés nem mindig ér véget az első jelentéssel. Ha a fejlesztő javította a hibákat, érdemes újratesztelést kérni. Ez rövidebb munka, de fontos. Egy javítás néha új hibát hoz létre. Például működni kezd a tovább gomb, de közben eltűnik egy korábbi adat. Vagy javul a hibaüzenet, de rossz helyen jelenik meg.

A Lépésellenőrzés alkalmazás feladatnál ezért hasznos, ha a szabadúszó külön jelöli a hibák súlyosságát. Sürgős, közepes vagy kisebb gond. Így nem minden kerül egy szintre. Egy elütés nem ugyanaz, mint egy megszakadó fizetési előtti folyamat. Egy homályos gombfelirat sem ugyanaz, mint az adatvesztés. Ez a különbségtétel segít dönteni, mit kell először javítani.

Jó lezárásnak azt tartom, amikor a magánügyfél nemcsak hibákat kap, hanem egy rövid képet is arról, mennyire használható a folyamat. Nem szép szavak kellenek, hanem tiszta állapot. Mi működik, mi zavaró, mi kockázatos, és mit érdemes később külön tesztelni. Így az online megbízás nemcsak egy kipipált feladat lesz, hanem valódi segítség a jobb alkalmazáshoz.