QA engineerek Salgótarjánban: Vélemények és kedvező árak

QA engineer Salgótarján területén magánmegbízásokhoz

A QA engineer feladata, hogy egy weboldal, mobilalkalmazás vagy más digitális rendszer hibáit még az átadás vagy frissítés előtt feltárja. Magánmegrendelőként akkor lehet rá szükség, ha saját honlapot, kisebb alkalmazást, webáruházat vagy egyedi digitális megoldást készíttettél, és független ellenőrzést szeretnél. Salgótarján területén a munka egy része személyesen is egyeztethető, de maga a szoftvertesztelés többnyire távolról is elvégezhető. A Qjob.hu oldalon különböző tapasztalatú szakemberek közül lehet választani, így nem egyetlen szolgáltató feltételeihez kell igazodni.

A minőségbiztosítás nem egyszerű hibakeresés. A tesztelő végigveszi a fontos felhasználói folyamatokat, ellenőrzi a funkciókat, rögzíti az eltéréseket és megmutatja, milyen lépésekkel idézhető elő egy probléma. Egy kisebb honlapnál ez lehet kapcsolatfelvételi űrlap, belépés vagy mobilos megjelenés ellenőrzése. Összetettebb rendszernél jogosultságok, fizetési folyamatok, adatbevitel és több böngésző vizsgálata is szóba kerülhet. Személy szerint én azt tartom hasznosnak, ha a megrendelő előre megnevezi azt a néhány funkciót, amelynek hibája valóban komoly gondot okozna.

Szoftvertesztelési feladatok és ellenőrzési körök

A szoftvertesztelő először megismeri a rendszer célját és a várható felhasználói viselkedést. Ezután készülhet ellenőrzési lista vagy részletes teszteset. A funkcionális vizsgálat azt nézi, hogy az egyes műveletek a követelmények szerint működnek-e. A regressziós ellenőrzés arra szolgál, hogy egy javítás vagy új funkció ne rontson el korábban működő részeket. Gyakori feladat a különböző böngészők és képernyőméretek vizsgálata is.

Sok megrendelő ott hibázik, amikor csak azt kéri, hogy valaki gyorsan kattintgassa végig az oldalt. Ettől még fontos hibák maradhatnak rejtve. Jobb eredményt ad, ha a minőségbiztosítás kockázati sorrendet követ. Előbb a regisztráció, vásárlás, adatmentés vagy más lényeges folyamat kerül sorra, majd a ritkábban használt funkciók. Egy jó hibajegy tartalmazza a hiba helyét, az előidézés lépéseit, a várt és a tényleges eredményt, valamint szükség esetén képernyőképet.

Volt olyan eset a gyakorlatban, amikor egy megrendelő hibátlannak gondolta a saját bemutatkozó oldalát, mert számítógépen minden menüpont működött. Telefonon azonban az ajánlatkérő gomb egyes kijelzőméreteken nem volt elérhető. A probléma technikailag kicsi volt, de közvetlenül akadályozta a kapcsolatfelvételt. Az ilyen eltérések miatt érdemes valós felhasználói útvonalak alapján ellenőrizni a rendszert.

QA engineer árak és várható költségek

A díj függ a rendszer méretétől, a tesztelés mélységétől, a szükséges eszközöktől és a dokumentáció részletességétől. Egy rövid ellenőrzés olcsóbb lehet, míg egy webáruház több böngészőn és mobilon végzett vizsgálata több munkaórát igényel. Az alábbi összegek tájékoztató jellegű magánmegbízási ársávok. A tényleges ajánlatot mindig a konkrét feladat alapján érdemes kérni.

A túl alacsony ajánlatnál érdemes megnézni, pontosan mi fér bele az összegbe. Tapasztalatom szerint 7.000 Ft alatti óradíjnál ritkán fér bele alapos vizsgálat és használható dokumentáció egyszerre. Ez nem jelenti azt, hogy a magasabb ár automatikusan jobb munkát ad. A feladat leírása, a vállalt ellenőrzési kör és az átadandó eredmény többet mond az ajánlat minőségéről.

QA szakember kiválasztása

A megfelelő szakember kiválasztásánál először azt érdemes ellenőrizni, hogy dolgozott-e már hasonló rendszerrel. Egy egyszerű honlaphoz nem feltétlenül kell automatizálási tapasztalat. Egy rendszeresen frissülő alkalmazásnál viszont előny lehet, ha a QA szakember érti a regressziós folyamatot, az adatbázisok alapjait és a programok közötti kapcsolatok ellenőrzését is. Kérj rövid leírást arról, hogyan kezdené el a feladatot és milyen eredményt adna át.

Fontos a hibák dokumentálásának módja. A puszta felsorolás kevés. Egy fejlesztőnek reprodukálható leírás kell, különben idő megy el a probléma újbóli felderítésére. Érdemes rákérdezni arra is, milyen eszközökön tud tesztelni, vállal-e újratesztelést a javítás után, és hogyan kezeli a hozzáférési adatokat. Itt több szakember ajánlata összevethető a feladat terjedelme, a határidő és a tapasztalat alapján.

Manuális és automatizált minőségbiztosítás

A manuális ellenőrzés során a tesztelő emberként használja a rendszert, és olyan problémákat is észrevehet, amelyek nem pusztán technikai hibák. Ilyen lehet egy félreérthető gomb, egy nehezen követhető folyamat vagy egy olyan állapot, amelyből a felhasználó nem tud továbblépni. Magánmegrendeléseknél ez gyakran jó kiindulás, különösen egyszeri átadás előtti ellenőrzésnél.

Az automatizált vizsgálat akkor lehet indokolt, ha ugyanazokat a lépéseket sokszor kell megismételni. Gyakran frissülő alkalmazásnál időt takaríthat meg, de a létrehozása és karbantartása külön feladat. Nem minden kis projektnél térül meg. A QA engineer ezért jó esetben nem automatikusan egyetlen módszert javasol, hanem a rendszer kockázataihoz és várható életciklusához igazítja az ellenőrzést.

A kettő egymást is kiegészítheti. A stabil, ismétlődő folyamatokat gépi ellenőrzés figyelheti, míg az új funkciók és a felhasználói élmény emberi vizsgálatot kaphatnak. Személy szerint egy kisebb, egyszeri magánprojektnél előbb a jól megtervezett kézi tesztelésre költenék, és csak utána döntenék arról, szükséges-e további automatizálás.

QA engineer Salgótarján és környékén

Salgótarján esetén a helyi jelenlét akkor lehet hasznos, ha személyes egyeztetés, helyszíni rendszer vagy csak helyben elérhető eszköz vizsgálata szükséges. A városon belül Zagyvapálfalva, Beszterce, Kemerovo-lakótelep és a belváros környékéről is érkezhet megbízás. A közeli települések közül Bátonyterenye, Somoskőújfalu, Karancslapujtő és Kazár is szóba kerülhet, ha a feladat személyes találkozást kíván.

A legtöbb digitális projekt azonban helyfüggetlenül tesztelhető. Ilyenkor fontosabb a megfelelő eszközpark, a pontos kommunikáció és a hozzáférések biztonságos átadása, mint a fizikai távolság. Ha a rendszer csak egy helyi hálózaton működik, ezt már az ajánlatkérésben jelezni kell. Ugyanez igaz arra, ha speciális telefon, táblagép vagy más hardver szükséges az ellenőrzéshez.

A tesztelés átadása és a hibák javítása

A munka végén használható eredményre van szükség, nem egyszerűen arra a kijelentésre, hogy az alkalmazás jó vagy rossz. A hibákat érdemes súlyosság szerint rendezni. Más kezelést igényel egy elírás, mint egy olyan hiba, amely miatt nem lehet fizetni, menteni vagy bejelentkezni. A jelentésből legyen egyértelmű, melyik probléma ismételhető meg biztosan és milyen környezetben jelentkezett.

A javítás általában a fejlesztő feladata, majd következhet az újratesztelés. Ez azért fontos, mert egy módosítás új hibát is létrehozhat. Ha szűk a keret, először a kritikus felhasználói folyamatokat célszerű ismét ellenőrizni. A szoftvertesztelő munkája akkor zárható le ésszerűen, amikor a megrendelő pontos képet kap a megmaradt kockázatokról, és el tudja dönteni, mely hibákat kell azonnal javítani.

Az indulás előtt érdemes átadni a rendszer elérhetőségét, a tesztfiókokat, a fontos funkciók listáját és az ismert problémákat. Ha van fejlesztői dokumentáció, az is segít. Nem kell azonban mindent előre részletesen kidolgozni. Egy tapasztalt minőségbiztosítási szakember a hiányzó információkat célzott kérdésekkel tisztázza, majd a tényleges kockázatok alapján építi fel az ellenőrzést.