QA software testerek Győrben: Vélemények és kedvező árak

QA software tester magánügyfeleknek

A QA software tester abban segít, hogy egy weboldal, webáruház, mobilalkalmazás vagy belső rendszer használat közben ne okozzon kellemetlen meglepetést. Magánügyfeleknél ez gyakran nem nagyvállalati fejlesztés. Inkább egy induló oldal, egy megrendelt alkalmazás, egy foglalási felület, egy fizetési folyamat vagy egy kisebb ügyviteli rendszer ellenőrzése. Ilyenkor nem elég annyi, hogy megnyílik az oldal. Látni kell, hol akad el a felhasználó, mi történik hibás adatnál, működik-e a regisztráció, rendben van-e a visszaigazoló levél, és mit lát a látogató telefonon.

Győr környékén sok ügyfél fejlesztővel dolgoztat, majd csak a végén keres tesztelőt. Ez érthető, de nem mindig szerencsés. Sok hiba olcsóbban javítható, ha a szoftvertesztelés nem az utolsó napon indul. A Qjob.hu felületén különböző szakemberek közül lehet választani, így nem egy cég szolgáltatásáról van szó, hanem önálló tesztelők munkájáról. A feladat lehet egyszeri ellenőrzés, részletes hibajegy készítés, átvételi teszt vagy ismétlődő minőségellenőrzés.

Po mojemu tapasztalatom szerint a jó tesztelő nem csak kattintgat. Kérdez. Megnézi, mire való a rendszer, ki fogja használni, milyen eszközről érkeznek a látogatók, és mi számít valódi hibának. Ez magánügyfélnél különösen fontos, mert sokszor nincs külön termékmenedzser vagy belső informatikai csapat. Egy szoftvertesztelő szakember ilyenkor fordít a technikai nyelv és a hétköznapi elvárások között.

Mit ellenőriz egy tesztelő

A tesztelő elsőként a fő folyamatokat nézi át. Belépés, regisztráció, rendelés, űrlapok, keresés, kosár, fizetés, időpontfoglalás, jogosultságok, értesítések. Egy kisebb webes rendszerben már ezek is sok hibalehetőséget rejtenek. Nem ritka, hogy az oldal asztali gépen rendben van, de telefonon szétesik egy gomb vagy eltűnik egy fontos mező. A manuális tesztelés pont az ilyen eseteknél hasznos, mert emberi szemmel vizsgálja a felületet.

A QA szakember hibajegyeket ír. Egy jó hibajegy nem csak annyi, hogy valami nem működik. Tartalmazza a lépéseket, az elvárt eredményt, a tényleges eredményt, a használt böngészőt, az eszközt és gyakran képernyőképet is. Ez a fejlesztőnek időt spórol. A megrendelőnek pedig átláthatóvá teszi, hogy miért csúszik vagy miért kell még javítani egy funkciót.

Sokan kérnek tesztelést akkor, amikor már vitában állnak a fejlesztővel. Ilyenkor a szoftvertesztelés nem döntőbíráskodás, hanem tények rögzítése. Mi működik. Mi nem. Melyik hiba kritikus, és melyik csak kényelmetlen. Volt eset, amikor egy ügyfél azt hitte, az egész webáruház rossz. A vizsgálat után kiderült, hogy a probléma főleg két szállítási beállításból és egy hibás visszaigazoló üzenetből állt. A javítás így sokkal nyugodtabban ment tovább.

QA software tester árak

Az ár függ a rendszer méretétől, a tesztelendő eszközök számától, a határidőtől és attól, kell-e részletes dokumentáció. Egy egyszerű átnézés olcsóbb, mint egy több böngészős, mobilos, fizetési folyamattal együtt végzett ellenőrzés. Szerintem gyanús, ha valaki nagyon alacsony áron vállal teljes körű tesztet egy összetett rendszerre. Olcsóbban 12.000 forintnál ritkán lesz minőségi, ha valódi hibakeresésről és írásos visszajelzésről van szó.

A táblázat csak tájékoztató. Egy magánfejlesztésnél sok múlik azon, mennyire rendezett az anyag. Ha van hozzáférés, rövid leírás és tesztadat, a munka gyorsabb. Ha a tesztelőnek először ki kell találnia, hogyan működne a rendszer, az növeli az időt. Én inkább óradíj és feladatlista kombinációját szeretem, mert így nem lesz vita abból, hogy mi tartozott bele az ellenőrzésbe.

Hogyan válassz QA szakembert

A jó választás nem csak az árról szól. Nézd meg, hogy a szakember dolgozott-e hasonló felülettel. Más tudás kell egy egyszerű bemutatkozó oldalhoz, más egy időpontfoglaló rendszerhez, és megint más egy fizetési vagy tagsági felülethez. A tapasztalt tesztelő nem ígéri, hogy mindent megtalál. Inkább elmondja, milyen kockázatokat fog átnézni, és milyen eszközökön dolgozik.

Sok ügyfél ott hibázik, hogy csak azt kérdezi, mennyiért nézi át az oldalt. Fontosabb kérdés, hogy mit ad át a munka végén. Egy rövid üzenet kevés lehet. Hasznosabb a hibajegy lista, a képernyőkép, a súlyossági szint és egy rövid összefoglaló. Ha javítás után újratesztelés is kell, azt előre érdemes tisztázni. A QA software tester munkája akkor igazán értékes, ha a fejlesztő rögtön tud belőle dolgozni.

Лично én azt preferálom, ha a megbízó először egy kisebb próbafeladatot ad. Például a regisztráció, a kapcsolatfelvételi űrlap és egy mobilos oldal ellenőrzését. Ebből gyorsan kiderül, mennyire érthető a visszajelzés, mennyire pontos a dokumentáció, és mennyire önálló a tesztelő. Egy szoftvertesztelő szakember stílusa legalább annyira számít, mint a technikai tudása.

Győri és környékbeli tesztelési igények

Győrben sok kisebb vállalkozás és magánmegrendelő használ saját webes felületet. Ide tartozhatnak oktatók, szépségipari szolgáltatók, autós szolgáltatások, lakáskiadók, helyi webáruházak és foglalási rendszerek. A helyi igény gyakran egyszerűnek látszik, de a hibák ugyanúgy pénzt és bizalmat vihetnek el. Egy rosszul működő űrlap miatt nem érkezik ajánlatkérés. Egy hibás mobilnézet miatt a látogató kilép.

A környékbeli munkáknál nem mindig szükséges személyes találkozó. Nádorváros, Révfalu, Marcalváros, Gyárváros, Ménfőcsanak és a közeli települések ügyfelei is tudnak távoli hozzáférést adni. Pannonhalma, Abda vagy Mosonmagyaróvár felől érkező megbízásoknál is elég lehet egy rövid egyeztetés, hozzáférés és világos tesztlista. Mégis hasznos, ha a tesztelő érti a helyi célközönséget, mert egy győri szolgáltató oldalán más lehet a fontos útvonal, mint egy országos portálon.

Ha a rendszer helyi ügyfeleket szolgál ki, a tesztelésnél érdemes ellenőrizni a térképes linkeket, a telefonszámokat, az időpontfoglalási sávokat és a kapcsolatfelvételi üzeneteket. Ezek apróságnak tűnnek. De egy magánügyfélnek gyakran pont ezek hozzák a bevételt.

Manuális tesztelés vagy automatizálás

A manuális tesztelés akkor jó választás, ha új vagy gyakran változó felületről van szó. Ilyenkor az emberi észlelés fontosabb, mint a gépi ismétlés. A tesztelő látja, ha egy szöveg félrevezető, ha egy gomb rossz helyen van, vagy ha a folyamat logikája zavaros. Egy magánmegrendelőnek általában ez adja az első valódi képet arról, hogy használható-e a rendszer.

Az automatizált ellenőrzés akkor hasznos, ha ugyanazokat a folyamatokat sokszor kell lefuttatni. Például belépés, keresés, kosárba helyezés vagy adatküldés. Nem minden kis projektnél térül meg. Sokszor előbb kézi ellenőrzés kell, utána lehet eldönteni, érdemes-e ismételhető teszteket építeni. A QA software tester ebben is tud tanácsot adni, de nem kell minden esetben bonyolult megoldás.

Volt olyan ügyfél, aki automatizálást kért egy háromoldalas bemutatkozó weboldalhoz. A beszélgetés után kiderült, hogy inkább mobilos ellenőrzésre és kapcsolatfelvételi űrlap tesztre van szüksége. Így kevesebbet fizetett, és azt kapta, ami tényleg hasznos volt. Nem minden technikai megoldás jobb csak azért, mert komolyabban hangzik.

Mit készíts elő a teszteléshez

A munka gyorsabb, ha a megbízó előre összeszedi a hozzáféréseket, a tesztelendő linkeket és a fő elvárásokat. Nem kell hosszú dokumentum. Elég egy rövid lista arról, milyen folyamatoknak kell működniük. Például felhasználó regisztrál, időpontot foglal, üzenetet küld, terméket rendel vagy adatot módosít. A tesztelő ebből már tud kiindulni.

Hasznos tesztadatokat is adni. Olyan e-mail címet, próbafelhasználót, kuponkódot vagy terméket, amelyen szabad kísérletezni. Ha fizetés is van, tisztázni kell, van-e próbakörnyezet. Éles fizetési rendszerben felelőtlen próbálgatni. Sok félreértés abból jön, hogy a megbízó szerint valami nyilvánvaló, a külsős szakember viszont nem ismeri a háttérszabályokat.

A végén kérj összefoglalót. Nem kell túl hosszú jelentés, de legyen benne, mi lett átnézve, milyen hibák maradtak, és mi számít sürgősnek. Egy QA munka akkor zárható le nyugodtan, ha nem csak hibákat kapsz, hanem döntési alapot is. Lehet, hogy néhány apró hiba marad. Ez nem tragédia. A lényeg az, hogy a kritikus folyamatok ne akadjanak el a valódi felhasználók előtt.