QA-tesztelők Szombathelyen: Vélemények és kedvező árak

QA tesztelő Szombathelyen webes és mobil projektekhez

A QA tesztelő Szombathelyen abban segít, hogy egy weboldal, alkalmazás vagy kisebb egyedi program hibái még az átadás előtt kiderüljenek. Magánmegrendelőként ez különösen hasznos lehet saját honlap, időpontfoglaló, webáruház, mobilalkalmazás vagy egy fejlesztő által készített egyedi rendszer ellenőrzésénél. A tesztelő végigpróbálja a fontos funkciókat, rögzíti az eltéréseket, és olyan hibaleírást készít, amely alapján a fejlesztő könnyebben javíthat.

A szoftvertesztelés nem egyszerű kattintgatás. Meg kell határozni, mit várunk az adott funkciótól, milyen lépések vezetnek az eredményhez, és mi számít hibának. Egy bejelentkezési felületnél például nem elég azt ellenőrizni, hogy helyes adatokkal működik. Meg kell nézni a hibás jelszót, az üres mezőket, a visszaállítást, a különböző böngészőket és azt is, hogyan viselkedik a felület kisebb képernyőn. Személy szerint azt tartom jó tesztnek, amelyből a megrendelő nemcsak hibajegyeket kap, hanem világos képet is arról, mely problémák fontosak az indulás előtt.

Szoftvertesztelési feladatok

A tesztelés terjedelmét mindig a rendszerhez kell igazítani. Egy egyszerű bemutatkozó oldalnál elég lehet a hivatkozások, űrlapok, mobilnézet és alapvető böngészőkompatibilitás ellenőrzése. Egy webáruháznál már szükség lehet regisztráció, kosár, fizetési folyamat, kuponok, visszaigazoló levelek és rendelési állapotok vizsgálatára is. Mobilalkalmazásnál külön szerepet kapnak az eltérő képernyőméretek, jogosultságok, hálózati hibák és operációs rendszerek.

A QA szakember teszteseteket készíthet, manuálisan végigjárhatja a fontos felhasználói folyamatokat, hibákat dokumentálhat és az új javításokat újraellenőrizheti. Gyakori feladat a regressziós tesztelés is. Ennek lényege, hogy egy javítás után ne csak az adott hibát nézzük meg, hanem azt is, nem romlott-e el közben egy korábban működő rész. Kisebb projektnél ez sokszor rövid ellenőrzőlista alapján történik.

Sokan azt a hibát követik el, hogy csak a fejlesztés legvégén kérnek tesztelést. Ilyenkor több probléma egyszerre kerül elő, és a javítás könnyen felboríthatja az átadási időpontot. Jobb már egy működő első változatnál elkezdeni az ellenőrzést. Nem kell minden képernyőnek késznek lennie. A fő folyamatok korai próbája gyakran olcsóbb, mint később egy rosszul felépített megoldás javítása.

QA tesztelő árak

Az ár attól függ, mekkora rendszert kell átnézni, hány eszközön és böngészőben szükséges próbálni, kell-e részletes teszteseteket készíteni, valamint hány javítási kör után történik újratesztelés. Egy kisebb honlap gyors ellenőrzése jóval kevesebb munka, mint egy regisztrációval, fizetéssel és több felhasználói szerepkörrel működő alkalmazás vizsgálata. Az alábbi összegek tájékoztató magánmegrendelői sávok.

Az ajánlatnál érdemes tisztázni, hogy a díj csak az első tesztkört tartalmazza-e, vagy a javítás utáni ellenőrzés is benne van. Az sem mindegy, hogy a megrendelő rövid hibajegyzéket kér vagy részletes reprodukciós lépéseket képernyőképekkel. Tapasztalatom szerint a túl olcsó tesztelés gyakran csak felületes átnézést jelent. 10.000 Ft alatt ritkán kapunk alapos vizsgálatot egy összetettebb webes folyamatra, ha dokumentálás és visszaellenőrzés is szükséges.

Hibajegyek és teszteredmények

A jó hibajegy rövid, de reprodukálható. Tartalmazza, hol jelent meg a probléma, milyen lépések vezettek hozzá, mi történt valójában és mi lett volna az elvárt eredmény. Hasznos lehet képernyőkép, képernyőfelvétel, böngészőverzió vagy eszközinformáció is. A fejlesztőnek ebből kell tudnia újra előidézni a hibát. A puszta megjegyzés, hogy nem működik, kevés.

A hibákat érdemes súlyosság szerint is rendezni. Más kategória, ha egy gomb szövege elcsúszik, és más, ha a vásárló nem tudja befejezni a fizetést. Egy jó tesztjelentés segít eldönteni, mi akadályozza az indulást, mi javítható később, és mely eltérés csak kisebb kényelmetlenség.

Volt olyan eset, amikor egy ügyfél szerint az új webes űrlap már készen állt az indulásra. Asztali gépen valóban működött. Telefonon azonban a beküldés gomb részben a képernyőn kívülre került, és egy gyakori böngészőben a kötelező mező hibajelzése sem látszott. A probléma nem a háttérrendszerben volt, hanem a felületen. Néhány célzott próba elég volt ahhoz, hogy még az élesítés előtt kiderüljön.

QA szakember kiválasztása

A megfelelő szakember kiválasztásánál azt érdemes nézni, milyen típusú rendszereket tesztelt korábban. Weboldal, mobilalkalmazás, játék és üzleti rendszer eltérő tapasztalatot igényelhet. A Qjob.hu felületén a feladatleírásban célszerű megadni, milyen rendszerről van szó, milyen eszközökön kell működnie, van-e már tesztelhető változat, és milyen határidő előtt kell elkészülni az ellenőrzéssel.

Jó jel, ha a jelentkező rákérdez a legfontosabb felhasználói folyamatokra. Érdemes azt is tisztázni, milyen formában adja át az eredményeket. Egy táblázat kisebb projektnél teljesen megfelelő lehet, míg összetettebb munkánál célszerű hibakövető rendszerben dolgozni. Én azt a tesztelőt választanám, aki nemcsak sok hibát akar felsorolni, hanem képes fontossági sorrendet is adni.

Referenciánál nem szükséges bizalmas korábbi hibajegyeket kérni. Elég lehet egy név nélküli minta vagy annak bemutatása, hogyan dokumentál egy problémát. A kommunikáció is fontos. A QA szakembernek tárgyilagosan kell jeleznie a hibát, nem pedig minősíteni a fejlesztőt vagy a korábbi munkát.

Tesztelés Szombathelyen és környékén

A legtöbb szoftvertesztelési feladat távolról is elvégezhető, ezért a helyszín nem mindig döntő. Szombathely azonban előnyt jelenthet, ha személyes egyeztetésre, helyi eszköz kipróbálására vagy egy zárt rendszer bemutatására van szükség. A belváros, Olad, Kámon, Herény és a Derkovits városrész könnyen elérhető találkozási pont lehet. Kőszeg, Vép, Gencsapáti és Torony irányából is egyszerűen megszervezhető egy rövid személyes teszt.

Távoli munkánál a megrendelő általában tesztfelületet és külön hozzáférést biztosít. Éles ügyféladatokkal lehetőleg ne történjen próba. Ha fizetési funkciót kell ellenőrizni, célszerű tesztmódot vagy erre létrehozott rendelési folyamatot használni. A munka végén legyen egyértelmű, mely hibákat javították, melyek maradtak nyitva, és mit szükséges újraellenőrizni.

Az indulás előtt érdemes külön elfogadási listát készíteni. Ebben szerepelhet, mely böngészők és készülékek fontosak, milyen felhasználói útvonalaknak kell hibamentesen működniük, és mely hibák mellett nem adható át a rendszer. Ez segít elkerülni a későbbi vitát arról, hogy egy eltérés még belefér-e. Kisebb projektnél már tíz vagy tizenöt jól megfogalmazott ellenőrzési pont is elég lehet. A lényeg, hogy a fejlesztő és a megrendelő ugyanazt értse kész állapot alatt.

A tesztelés akkor ad valódi értéket, ha konkrét döntéshez vezet. Nem az a cél, hogy minél hosszabb hibalista készüljön. A fontos hibákat kell megtalálni, érthetően leírni, majd a javítás után ellenőrizni. Így egy magánmegrendelő is átláthatóbb helyzetben veheti át a saját weboldalát vagy alkalmazását, és kisebb eséllyel az első felhasználók jelzik a legalapvetőbb problémákat.