QA engineerek Debrecenben: Vélemények és kedvező árak

QA engineer Debrecenben

A QA engineer akkor hasznos, amikor egy weboldal, alkalmazás vagy kisebb online felület már elkészült, de a használat közben mégis bizonytalan marad. A QA engineer feladata ilyenkor az, hogy végigmenjen a fontos folyamatokon, észrevegye a hibákat, és érthetően leírja, hol csúszik meg a rendszer. Debrecen környékén ez nem csak céges projektnél merül fel. Magánügyfelek is keresnek ilyen segítséget, amikor van egy időpontfoglaló, egy rendelési felület, egy jelentkezési oldal vagy egy saját fejlesztésű rendszer, amit még élesítés előtt át akarnak nézetni. A Qjob.hu felületén is sok ilyen feladat jelenik meg, mert egy jó tesztelő szakember gyakran olcsóbb, mint utólag tűzoltani.

Én személy szerint jobban szeretem, ha a megrendelő nem azt mondja, hogy nézze át valaki az egészet, hanem azt, hogy melyik folyamat a fontos. Belépés, regisztráció, rendelés, kapcsolatfelvétel, fizetés. Ezekből rögtön látszik, mire kell figyelni. Sok ügyfél ott hibázik, hogy túl későn kér ellenőrzést. Már fut a hirdetés, jönnek a látogatók, aztán kiderül, hogy mobilon nem küldhető el az űrlap. Ilyenkor a hiba már nem csak technikai gond, hanem elveszett érdeklődő és kidobott pénz is.

Hol bukik meg leggyakrabban a felhasználói út

A legtöbb hiba nem a nyitóoldalon jön elő. Általában a második vagy harmadik lépésnél látszik meg, hogy valami nincs rendben. Egy minőségbiztosítási szakember ilyenkor nem csak kattintgat. Azt figyeli, mi történik akkor, ha az adat hiányos, rossz formátumban érkezik, lassabb a hálózat, más böngészőt használ a látogató, vagy visszalép egy korábbi oldalra. És pont ezek azok a helyzetek, amelyeket a tulajdonos ritkán próbál végig.

Gyakori hiba a hiányos mezőellenőrzés, a rosszul működő jelszó-visszaállítás, a félbemaradó fizetés, a hibás megerősítő levél vagy az, hogy a rendszer eltűnteti a már kitöltött adatokat. De ide tartozik az is, amikor az oldal asztali gépen még rendben van, telefonon viszont szétesik. Egy QA engineer ilyen helyzetben nem csak hibát talál, hanem segít sorrendet is állítani. Mi az, ami azonnali javítást kér. Mi az, ami zavaró, de együtt lehet vele élni pár napig. És mi az, ami csak később érdemel külön figyelmet.

Volt egy eset, amikor a megrendelő azt mondta, hogy az oldallal alapvetően nincs gond, csak néha furcsán viselkedik. Elsőre ez nagyon tág megfogalmazás volt. A tesztelés közben viszont kiderült, hogy a jelentkezési folyamat végén a rendszer egyszerűen nem küldte tovább az adatot, ha a felhasználó túl gyorsan váltott mezőt telefonon. A tulajdonos ezt soha nem vette észre, mert mindig laptopról próbálta. Szerintem az ilyen hiba tipikus példa arra, miért nem elég a saját próba. A felhasználó nem úgy mozog, ahogy a készítő várja.

És van egy másik gyakori probléma is. Sokan azt hiszik, hogy a hibák listája önmagában elég. Pedig a jó visszajelzéshez kell rövid leírás, lépéssor, várt eredmény és valós eredmény. Én azt látom, hogy a fejlesztővel is akkor lehet haladni, ha a hiba nem csak meg van nevezve, hanem meg is lehet ismételni. Ebben erős egy tapasztalt szoftvertesztelő.

QA engineer árak

A QA engineer ára attól függ, mekkora felületet kell átnézni, hány eszközön fut a vizsgálat, kell-e részletes hibajegy, és benne van-e az újraellenőrzés a javítás után. Debrecenben a magánügyfelek általában kisebb csomagokban gondolkodnak, mert ritkán van szükség folyamatos jelenlétre. De a túl olcsó ajánlat itt is gyanús. Az én tapasztalatom szerint 10.000 alatt legfeljebb nagyon rövid alapellenőrzés fér bele. Komolyabb átnézés, ahol a hibák valóban használható formában vannak leírva, ennél többe kerül. Őszintén szólva a túl olcsó munka ritkán alapos.

Ezek irányárak. A valós összeg attól is függ, mennyire van előkészítve a munka. Van-e tesztlink. Van-e hozzáférés. Van-e lista arról, melyik rész a legfontosabb. És kell-e több kör. Szerintem 12.000 alatt csak nagyon szűk feladatnál érdemes reménykedni jó eredményben. Ha valaki részletes hibajegyet, képernyőképet és újratesztet is kér, annál a középső ársáv sokkal reálisabb.

QA engineer választása

Jó QA engineer általában nem azzal kezd, hogy mindent látott már, hanem azzal, hogy kérdez. Milyen eszközön jelentkezik a gond. Mi a legfontosabb folyamat. Volt-e már panasz valódi felhasználótól. Kell-e csak ellenőrzés, vagy részletes dokumentálás is. Ezek egyszerű kérdések, de sokat elárulnak. Aki már az elején biztos megoldást ígér anélkül, hogy látná a felületet, az szerintem kockázatos választás.

Én azt preferálom, ha a tesztelő szakember mintát is tud mutatni korábbi hibajegyből vagy legalább elmondja, milyen formában adja át az eredményt. Nem mindegy, hogy annyit ír, hogy itt valami rossz, vagy pontosan leírja a lépéseket. Sok vita abból lesz, hogy a megrendelő és a fejlesztő nem ugyanazt érti a hiba alatt. Egy jó minőségbiztosítási szakember ezt a részt rendbe teszi. Nem bonyolítja túl, csak világosan fogalmaz.

Sokak hibája, hogy kizárólag árat néznek. Pedig ennél fontosabb, hogy a szakember mennyire érti a felhasználói oldalt. Egy QA engineer nem csak technikai ember. Azt is látnia kell, hol bizonytalanodik el a látogató, mikor veszíti el a fonalat, és melyik ponton hagyja ott a folyamatot. Nekem az a benyomásom, hogy a türelmes, pontos és kissé szkeptikus hozzáállás többet ér, mint a hangzatos bemutatkozás.

Debreceni városrészek és közeli területek

A tesztelési munka nagy része távolról is megoldható, mégis van helyzet, amikor számít a helyi közelség. Debrecenben sok magánügyfél szeret legalább egyszer személyesen beszélni a projektről, főleg akkor, ha egy régebbi rendszerhez kell hozzáférést átadni, vagy több ember között kell egyeztetni. A Belváros, Nagyerdő, Tócóskert, Józsa és Pallag felől érkező megkereséseknél ez gyakran előjön. De a tényleges vizsgálat utána már szinte mindig online történik.

És szerintem ez teljesen rendben van. Egy szoftvertesztelő munkájának értékét nem az adja, hogy egy irodában ül-e, hanem az, hogy észreveszi-e a valós hibát. Debrecen környékén is sok projekt úgy indul, hogy a tulajdonos csak gyors ellenőrzést szeretne, aztán a munka közben derül ki, hogy több pontot is át kell nézni. Ilyenkor jól jön, ha a kommunikáció egyszerű, és nem kell napokat várni egy rövid visszajelzésre.

A közeli települések felől érkező ügyfeleknél is hasonló a helyzet. A rendszer ugyanúgy lehet rosszul tesztelt, ha valaki a városközponton kívül működteti. A lényeg inkább az, hogy legyen világos cél. Mit kell kipróbálni. Milyen eszközön. Mi számít sürgősnek. Ha ez megvan, a helyszín másodlagos. De ha valaki Debrecenben keres segítséget, sokszor nyugodtabb érzés olyan embert megbízni, aki helyben vagy a közelben is elérhető.

Mit készíts elő a megrendelés előtt

A munka gyorsabb lesz, ha a megrendelő előre összeszedi az alapinformációkat. Melyik oldalon jelentkezik a gond. Milyen készüléken látszott. Mi a fő célfolyamat. Van-e tesztfiók. Lehet-e próbavásárlást vagy próbaregisztrációt csinálni. Nem kell hosszú dokumentáció. Pár tiszta mondat is elég. De ez a pár mondat sok időt takarít meg.

Sok ügyfél elköveti azt a hibát, hogy túl általános kéréssel indul. Nézze át valaki az egészet. Ez elsőre jól hangzik, de valójában drágább és lassabb. Én személy szerint jobb megoldásnak tartom, ha először a pénzt hozó vagy érdeklődőt gyűjtő részeket nézik át. A kapcsolatfelvételi űrlapot, az ajánlatkérést, a foglalást, a rendelést. Ha ezek rendben vannak, utána lehet szélesíteni a tesztet.

Volt már olyan projekt, ahol a tulajdonos biztos volt benne, hogy a fő gond a lassúság. A vizsgálat után mégis az derült ki, hogy a látogatók azért estek ki, mert a hibás megerősítő üzenet miatt nem tudták, sikeres volt-e a beküldés. Vagyis nem a sebesség volt a fő baj, hanem a bizonytalanság. Szerintem ezért érdemes kívülről ránézetni a folyamatra. A tulajdonos ismeri a rendszert. A felhasználó nem ismeri. A QA engineer pont ezt a távolságot tudja áthidalni.

Összességében a QA engineer szolgáltatás akkor ad valódi értéket, ha nem csak hibavadászatként kezelik, hanem döntést segítő ellenőrzésként. Mi működik. Mi nem. Mi sürgős. Mi várhat. Debrecenben is ezt keresik a legtöbben, amikor nem akarnak mellébeszélést, csak tiszta képet arról, hogy a rendszer készen áll-e a valódi használatra.