Quality assurance testerek Veszprémben: Vélemények és kedvező árak

Quality assurance tester magánügyfeleknek

A Quality assurance tester akkor segít, amikor egy weboldal, alkalmazás vagy belső rendszer hibáit még azelőtt kell megtalálni, hogy azok az ügyfelekhez kerülnek. Magánügyfélként ez nem mindig nagy fejlesztési projektet jelent. Lehet egy frissen elkészült webshop, foglalási oldal, mobilos felület, fizetési folyamat vagy egy saját üzleti admin oldal. A lényeg az, hogy valaki kívülről, türelmesen és rendszerezetten végigpróbálja a fontos lépéseket.

Veszprém környékén sok kisebb vállalkozás és egyéni megbízó dolgozik távoli fejlesztővel. Ilyenkor különösen hasznos egy független QA tesztelő, mert nem ugyanazzal a szemmel nézi a rendszert, mint aki készítette. Szerintem ez a munka akkor ér valamit, ha nem csak hibalistát ad, hanem érthető leírást is. Mit próbált ki. Hol akadt el. Milyen eszközön jelentkezett a gond. Mennyire súlyos a hiba.

Sokan ott rontják el, hogy csak akkor keresnek szakembert, amikor már éles az oldal. Akkor minden apró hiba sürgős lesz. Egy hiányzó visszaigazoló e-mail, egy rosszul működő gomb vagy egy mobilon széteső űrlap is pénzt vihet el. A Qjob.hu felületén olyan magánszakemberek között lehet keresni, akik egyszeri ellenőrzést, részletes tesztelést vagy hosszabb együttműködést is vállalhatnak.

QA tesztelő feladatai

A QA tesztelő feladata nem az, hogy véletlenszerűen kattintgasson. A jó munka elején röviden tisztázni kell, mi számít sikeres működésnek. Egy webshopnál például fontos a regisztráció, a kosár, a kupon, a fizetés, a számla, az e-mail értesítés és a mobilos nézet. Egy szolgáltatói oldalon inkább az ajánlatkérés, az űrlapok, a naptár, a kapcsolatfelvétel és a nyelvi hibák kerülnek előtérbe.

A minőségbiztosítási tesztelő többféle ellenőrzést végezhet. Funkcionális tesztelésnél azt nézi, hogy a rendszer azt csinálja-e, amit kell. Használhatósági ellenőrzésnél azt, hogy egy hétköznapi felhasználó érti-e a lépéseket. Reszponzív tesztelésnél mobilon, tableten és asztali gépen is próbálja a felületet. Böngésző tesztnél az a kérdés, hogy Chrome, Safari, Firefox vagy Edge alatt is stabil-e a működés.

Volt eset, amikor egy ügyfél azt hitte, csak a rendelés visszaigazítása hibás. A teszt során kiderült, hogy a szállítási díj bizonyos irányítószámoknál rosszul számolódott. Ez nem látványos hiba, de minden rossz rendelésnél veszteséget okozott volna. Az ilyen részletek miatt érdemes nem csak gyors átnézést kérni.

Quality assurance tester árak

A QA szakember díja főleg attól függ, mennyi oldalt, folyamatot és eszközt kell ellenőrizni. Egy egyszerű weboldal átnézése olcsóbb, mint egy több szereplős rendszer vagy egy fizetési folyamattal működő webshop tesztelése. Olcsóbban 12.000 forint alatt ritkán lesz alapos munka, legfeljebb nagyon kis feladatra. Személy szerint inkább egy rövidebb, de pontosan meghatározott tesztet választanék, mint egy homályos olcsó csomagot.

Az ár akkor korrekt, ha a megbízó látja, mit kap érte. Egy rövid hibajegy lista sokszor kevés. Jobb, ha a szakember megadja a tesztelt eszközöket, a böngészőt, a lépéseket és a várt működést is. Így a fejlesztő gyorsabban javít. És nem indul vita arról, hogy valójában mi volt a probléma.

Minőségbiztosítási tesztelő kiválasztása

A minőségbiztosítási tesztelő kiválasztásánál nem csak az ár számít. Fontosabb, hogy hogyan kérdez. Ha egy szakember azonnal árat mond, de nem kérdez a rendszerről, az óvatosságra int. Legalább azt tudnia kell, hogy weboldalról, mobilalkalmazásról, webshopról vagy belső felületről van szó. Az is lényeges, hogy kell-e fizetési teszt, több nyelv, több jogosultsági szint vagy admin felület.

A saját tapasztalatom szerint az a jobb tesztelő, aki nyugodtan és pontosan ír. Nem kell túl technikai szöveg. De legyen világos. Például milyen lépés után jelent meg a hiba, mi volt a várt eredmény, és mi történt helyette. Egy jó jelentés nem hosszú regény. Inkább rendezett, visszakereshető és fejlesztőnek is használható.

Érdemes mintát kérni korábbi hibajegyről, természetesen érzékeny adatok nélkül. Az is jó jel, ha a szakember meg tudja mondani, hogy egy adott költségkeretből mit nem érdemes vállalni. Minden rendszert nem lehet teljes mélységben tesztelni pár óra alatt. Aki ezt őszintén kimondja, az általában megbízhatóbb, mint aki mindenre rábólint.

Quality assurance tester Veszprémben és környékén

Veszprémben a megbízás sokszor távolról is elvégezhető, mert a tesztelés nagy része böngészőben, telefonon vagy megosztott hozzáféréssel történik. Mégis számít a helyismeret, ha a szolgáltatás helyi ügyfeleknek készül. Egy veszprémi étterem, rendelő, oktató vagy kisbolt oldala más felhasználói szokásokkal találkozik, mint egy országos szoftver.

A belváros, Jutaspuszta, Dózsaváros, Cholnokyváros és az egyetemi környék más közönséget hozhat. Balatonalmádi, Balatonfüred, Ajka, Várpalota és Herend felől is érkezhetnek ügyfelek. Ha a weboldal helyi keresésre épül, a tesztelésnél azt is érdemes nézni, hogy a kapcsolatfelvétel, térkép, nyitvatartás és mobilos hívásgomb jól működik-e.

Nem minden hiba technikai. Volt olyan helyi szolgáltatói oldal, ahol minden gomb működött, de a foglalási lépés túl hosszú volt. A látogatók egy része egyszerűen kilépett. Ilyenkor a QA szakember nem csak hibát keres, hanem jelzi, hogy a folyamat feleslegesen nehéz. Ez magánügyfeleknél sokszor többet ér, mint egy nagyon részletes, de csak fejlesztőknek írt táblázat.

Weboldal és alkalmazás tesztelés menete

A tesztelés elején érdemes rövid listát adni arról, mely részek fontosak. Nem baj, ha a megbízó nem használ szakmai szavakat. Elég leírni, hogy az ügyfél tudjon időpontot foglalni, fizetni, üzenetet küldeni vagy fájlt feltölteni. A QA szakember ebből már készíthet ellenőrzési útvonalat.

Ezután jön a tesztkörnyezet tisztázása. Kell-e belépési adat. Van-e próba fizetés. Milyen eszközökön fontos a működés. Mely böngészők számítanak. Kisebb megbízásnál ez lehet egyszerű üzenetváltás. Nagyobb feladatnál jobb egy rövid táblázat vagy feladatlista. A lényeg, hogy ne a munka végén derüljön ki, kimaradt a legfontosabb folyamat.

A hibák rögzítése után a megbízó vagy a fejlesztő javít. Ezután jön az újrateszt. Ezt sokan kihagyják, pedig fontos. Egy javítás gyakran elront valami mást. Nem rosszindulatból. Egyszerűen a rendszerek összefüggenek. Ezért a regressziós ellenőrzés nem luxus, hanem óvatos lépés.

Gyakori hibák QA ellenőrzésnél

Az egyik gyakori hiba, hogy a megbízó csak asztali gépen nézi az oldalt. Közben a látogatók jelentős része telefonról érkezik. Egy rossz sortörés, takart gomb vagy nehezen használható menü elég ahhoz, hogy valaki ne küldjön ajánlatkérést. A másik probléma a túl kevés adat. Egy űrlap működhet rövid névvel, de hibázhat hosszabb címmel vagy ékezetes karakterrel.

Gyakori még a jogosultsági hiba. A felhasználó olyat lát, amit nem kellene. Vagy nem látja azt, amihez hozzáférése van. Webshopnál a kuponok, szállítási díjak és készletállapotok okoznak sok gondot. Szolgáltatói oldalon inkább az időpontfoglalás, az automatikus e-mail és a fájlfeltöltés szokott érzékeny lenni.

Én azt szeretem, amikor a teszt rövid, de következetes. Magyarul ez annyit jelent, hogy nem a látványos hibák vadászata a cél. Inkább az, hogy a valódi ügyfélút végig működjön. A QA szakember akkor ad jó értéket, ha a megbízó a végén pontosabban látja a saját rendszerét. Nem csak azt, hogy mi romlott el, hanem azt is, hol érdemes egyszerűsíteni.