QA-tesztelők Békéscsabán: Vélemények és kedvező árak

QA tesztelő magánügyfeleknek

A QA tesztelő abban segít, hogy egy weboldal, alkalmazás, rendelési folyamat vagy belső rendszer ne a felhasználóknál bukjon el. Magánügyfélként ez akkor is fontos, ha nem nagy céges fejlesztésről van szó, hanem egy kisebb webáruházról, időpontfoglaló oldalról, mobilos felületről vagy egy már elkészült szoftver átvételéről. Békéscsaba környékén sokan fejlesztővel dolgoznak, de külön tesztelő szakembert csak későn keresnek. Ez érthető, mégis kockázatos. A fejlesztő általában a saját logikája szerint nézi a rendszert. A tesztelő másképp gondolkodik. Ő hibát keres, nem igazolást.

Magánmegbízásnál a munka gyakran egyszerű kérdéssel indul. Vajon rendben működik az oldal. De a válasz ritkán csak igen vagy nem. A minőségellenőrzés során előkerülhet rossz gombfelirat, hibás űrlap, lassú oldal, elcsúszó mobilnézet, félrevezető üzenet, hiányzó visszajelzés vagy olyan hiba, amely csak bizonyos böngészőben látszik. Szerintem egy jó QA szakember nem bonyolítja túl a helyzetet. Világos listát ad, képernyőképpel, lépésekkel és fontossági sorrenddel.

A Qjob.hu oldalán különböző szabadúszó szakemberek közül lehet választani, nem egyetlen cég csomagját kell elfogadni. Ez főleg kisebb munkáknál hasznos. Itt számít, hogy a tesztelő értse a megbízó nyelvét, és ne csak technikai szavakkal válaszoljon.

Manuális tesztelés és hibakeresés

A manuális tesztelés lényege, hogy a tesztelő valódi felhasználói helyzeteket próbál végig. Nem csak azt nézi, hogy egy gomb megnyomható-e. Azt is ellenőrzi, hogy a folyamat érthető, követhető és biztonságos-e. Egy egyszerű kapcsolatfelvételi űrlapnál például fontos, hogy a kötelező mezők jól legyenek jelölve, a hibák világosan jelenjenek meg, és a sikeres küldés után legyen egyértelmű visszajelzés.

Sokan ott hibáznak, hogy csak a fő útvonalat nézik. Megnyitják az oldalt, kitöltik az űrlapot, elküldik, és ha működik, késznek tekintik. De a felhasználók nem így viselkednek. Üresen hagynak mezőket, rossz e-mail címet írnak be, visszalépnek, mobilról próbálkoznak, lassabb kapcsolattal használják az oldalt. Egy tapasztalt szoftvertesztelő ezekre is figyel.

Volt eset, amikor egy ügyfél azt hitte, hogy a webshop fizetési része rendben van, mert az asztali gépen minden lefutott. Mobilon viszont a megrendelés gomb a képernyő aljára csúszott, és sok készüléken nem lehetett megnyomni. Nem nagy hiba volt a kódban, de közvetlenül pénzbe került. Ilyenkor a QA tesztelés nem elméleti extra, hanem nagyon gyakorlati ellenőrzés.

QA tesztelő árak és díjak

Az ár attól függ, hogy milyen rendszert kell átnézni, mennyi felület van, kell-e dokumentált hibajegy, szükséges-e újratesztelés, és milyen gyorsan kell elkészülni. Békéscsaba esetén a helyi egyeztetés előny lehet, de sok feladat távolról is elvégezhető. A legtöbb magánmegbízás nem igényel hosszú szerződést. Elég egy pontos feladatlista és egy tiszta határidő.

Én személy szerint óvatos lennék a túl olcsó ajánlatokkal. Egy gyors ránézés lehet olcsó, de az nem ugyanaz, mint a valódi hibakeresés. Olcsóbban mint 12.000 ritkán lesz alapos, ha nem csak egyetlen oldalról van szó. A túl magas ár sem garancia. A lényeg, hogy mit kap a megbízó a díjért. Hibajegyeket, képernyőképeket, rövid összegzést, újratesztelést vagy csak szóbeli véleményt.

A táblázat nem merev árlista. Inkább irányadó sáv. Ha a rendszerben sok szerepkör van, például admin, regisztrált felhasználó és vendég, akkor a díj emelkedik. Ha csak egy frissítés után kell ellenőrizni három konkrét funkciót, akkor a munka rövidebb és olcsóbb lehet.

Tesztelő szakember választása

A jó választás nem mindig az, aki a legtöbb technikai kifejezést használja. Magánügyfélként fontosabb, hogy a szakember érthetően kérdezzen. Milyen oldalt kell vizsgálni. Mi a cél. Van-e fejlesztő, aki javítja a hibákat. Kell-e külön jelentés. Milyen eszközökön kell ellenőrizni. Ezek egyszerű kérdések, de sok későbbi félreértést megelőznek.

Po mojem opytu, illetve magyarul mondva a saját tapasztalatom szerint az a tesztelő szakember megbízhatóbb, aki előre elmondja a munka határát. Például azt, hogy nem végez biztonsági behatolási tesztet, ha csak manuális ellenőrzésre kapott megbízást. Vagy azt, hogy a fizetési szolgáltató hibáit csak jelzi, de nem javítja. Ez nem gyengeség, hanem tiszta keret.

Érdemes mintát kérni egy korábbi hibajelentés formájáról. Nem kell benne ügyféladatnak szerepelnie. Elég látni, hogyan írja le a hibát. Egy jó hiba leírása rövid, mégis pontos. Tartalmazza a lépéseket, az elvárt működést, a tényleges eredményt és a környezetet. Ha ezek hiányoznak, a fejlesztő sok időt veszít a reprodukálással.

Online QA tesztelés Békéscsabán és környékén

Az online QA tesztelés jól működik akkor, ha a rendszer interneten elérhető, vagy a megbízó ad ideiglenes hozzáférést. Békéscsaba, Gyula, Orosháza, Mezőberény és Sarkad felől is megoldható a távoli egyeztetés. Helyi jelenlét főleg akkor hasznos, ha a projektet személyesen kell átbeszélni, vagy a megbízó nem szeret hosszú technikai levelezést.

A távoli munka előnye, hogy a tesztelő több eszközről, több böngészőből tud ellenőrizni. Az eredmény általában írásos lista. Ez lehet egyszerű táblázat, megosztott dokumentum vagy hibajegykezelőben vezetett feladat. Magánügyfélnél az egyszerű forma sokszor jobb. Nem kell felesleges rendszer, ha a fejlesztő egy rövid listából is pontosan dolgozik.

De van helyzet, amikor a személyes beszélgetés többet ér. Például ha a megbízó nem tudja pontosan megfogalmazni, mit kellene ellenőrizni. Ilyenkor egy rövid megbeszélés sok félreértést megold. Békéscsabán ez nem ritka, mert sok kisebb vállalkozás családi vagy egyéni alapon működik, és nincs külön műszaki vezető.

Hibajelentés és újratesztelés

A hibajelentés minősége legalább olyan fontos, mint maga a hibák megtalálása. Ha a leírás homályos, a javítás lassú lesz. A fejlesztő visszakérdez, a megbízó közvetít, a határidő csúszik. Egy rendes jelentésben a tesztelő leírja, hol jelent meg a hiba, milyen lépések vezettek oda, mi lett volna az elvárt eredmény, és mi történt valójában.

A hibák súlyossága sem mindegy. Egy elgépelés zavaró, de nem ugyanaz, mint amikor nem lehet fizetni vagy belépni. A jó minőségbiztosítás különbséget tesz kritikus, közepes és kisebb hiba között. Ez segít dönteni, mit kell azonnal javítani, és mi várhat a következő körre.

Sokan elfelejtik az újratesztelést. Pedig a javítás után újra meg kell nézni az érintett részt. Néha a javítás új hibát hoz létre. Volt olyan eset, amikor egy hibás kuponmezőt kijavítottak, de közben eltűnt a szállítási díj számítása. A megbízó csak azt látta, hogy az eredeti gond már nincs meg. A tesztelő viszont észrevette az új problémát.

Mikor elég egy gyors szoftverteszt

Nem minden projekt igényel hosszú ellenőrzést. Egy kisebb bemutatkozó oldalnál vagy egyszerű időpontkérő űrlapnál elég lehet egy gyors szoftverteszt. Ilyenkor a cél nem az, hogy minden elképzelhető hibát megtaláljon valaki, hanem hogy a legfontosabb problémák ne maradjanak bent. Linkek, űrlapok, mobilnézet, alapvető sebesség, érthető üzenetek. Ennyi sokszor már nagy különbséget jelent.

Nagyobb rendszer esetén viszont a rövid ellenőrzés kevés. Ha van fizetés, regisztráció, adatfeltöltés, több jogosultsági szint vagy ügyféladat, akkor alaposabb QA tesztelés kell. Ilyenkor nem érdemes csak az indulás előtti utolsó napra hagyni a munkát. A hibák javításához idő kell. És a javítás után újra ellenőrizni kell a működést.

Лично я предпочитаю, ha egy megbízó már a fejlesztés vége előtt bevon egy tesztelőt, de ezt magyarul egyszerűbben úgy mondanám, hogy jobb nem az utolsó órában keresni segítséget. A QA tesztelő akkor dolgozik igazán hasznosan, ha van ideje kérdezni, kipróbálni, jelezni és visszanézni. Így a végeredmény nyugodtabb lesz. Nem tökéletes, mert olyan ritkán létezik. De használhatóbb és kiszámíthatóbb.