QA-mérnökök Salgótarjánban: Vélemények és kedvező árak

QA-mérnök Salgótarján területén

A QA-mérnök magánügyfélnek akkor segít, ha egy weboldal, alkalmazás vagy egyedi szoftver minőségét még használatba vétel előtt, fejlesztés közben vagy egy nagyobb módosítás után kell ellenőrizni. Salgótarján területén a munka indulhat személyes felméréssel, de a legtöbb digitális rendszer távolról is vizsgálható. A minőségbiztosítási mérnök nemcsak hibákat keres. Megtervezi, mit és milyen sorrendben kell ellenőrizni, feltárja a kockázatos részeket, dokumentálja a problémákat, majd a javítások után újra megvizsgálja a fontos folyamatokat.

A Qjob.hu felületén különböző önálló szakemberek ajánlatai hasonlíthatók össze. Az első egyeztetés előtt érdemes röviden összefoglalni, mire szolgál a rendszer, mely funkciók a legfontosabbak, és milyen eszközökön használják. Személy szerint én nem az összes képernyő azonos részletességű vizsgálatával kezdenék. Először azokat a folyamatokat ellenőrizném, amelyek hibája adatvesztést, sikertelen műveletet vagy használhatatlan szolgáltatást okozhat.

Minőségbiztosítási terv

A tesztelési terv meghatározza, mely funkciók kerülnek ellenőrzésre, milyen környezetben történik a próba, és milyen eredmény számít elfogadhatónak. Egy kisebb projektben ez lehet rövid lista. Összetettebb alkalmazásnál külön kezelhetők a belépési, adatkezelési, jogosultsági és egyéb fontos folyamatok. A cél nem a dokumentáció mennyisége, hanem az, hogy a lényeges területek ne maradjanak ki.

A QA szakember a normál használat mellett hibás és szélsőséges eseteket is vizsgálhat. Mi történik üres mezőnél, hibás dátumnál, megszakadó kapcsolatnál vagy ismételt gombnyomásnál. Ezekből gyakran olyan problémák derülnek ki, amelyek a fejlesztés közbeni bemutatón nem jelentkeznek.

Sokan hibát követnek el, amikor a tesztelést csak a projekt végére hagyják. Ilyenkor egy alapvető működési hiba több már elkészült részt is érinthet. Kisebb időközi ellenőrzésekkel hamarabb kiderülhet, ha egy funkció másképp működik, mint ahogy az ügyfél várta. Az én tapasztalatom szerint a korán megtalált hiba általában egyszerűbben javítható.

Hibafeltárás és dokumentálás

A használható hibaleírásból kiderül, hogyan lehet a problémát újra előidézni. Tartalmazza a kiindulási állapotot, a lépéseket, az elvárt működést és a tényleges eredményt. Ha a hiba csak meghatározott böngészőben, eszközön vagy felhasználói jogosultsággal jelentkezik, ezt is rögzíteni kell. A képernyőkép segíthet, de önmagában ritkán elegendő.

Volt olyan eset a gyakorlatban, amikor egy webes felület mentési hibája csak bizonyos sorrendben végzett módosítások után jelentkezett. A fejlesztő külön külön minden funkciót működőnek látott. A teljes felhasználói folyamat végigpróbálásakor azonban kiderült, hogy egy korábbi lépés hibás állapotot hagyott maga után. A pontos reprodukció után a javítás már célzottan elvégezhető volt.

A hibákat célszerű súlyosság szerint rendezni. Egy kisebb megjelenítési eltérés nem azonos egy olyan problémával, amely miatt az ügyfél nem tud belépni vagy elveszíti a rögzített adatot. A fontossági sorrend segít abban, hogy a fejlesztési idő először a valóban kockázatos hibákra jusson.

Automatizált ellenőrzések

Ismétlődő tesztek egy része automatizálható. Ez főként akkor hasznos, ha ugyanazokat a fontos folyamatokat sok fejlesztési változat után újra ellenőrizni kell. Például a belépés, egy alapvető adatmentés vagy egy számítás eredménye rendszeresen vizsgálható automatikus próbákkal. Nem minden feladatnál indokolt ilyen megoldást készíteni.

Egy kis, egyszeri projektben az automatizálás kialakítása több munkát jelenthet, mint a kézi ellenőrzés. Hosszabb fejlesztésnél viszont megtérülhet, mert a korábbi működés gyorsan újratesztelhető. A minőségbiztosítási mérnök feladata annak eldöntése is, mely ellenőrzések ismétlődnek annyiszor, hogy érdemes őket automatizálni.

Az automatikus teszt sem helyettesít minden emberi vizsgálatot. Egy gépi ellenőrzés meg tudja állapítani, hogy egy gombnyomás után megjelent e a várt elem, de nem feltétlenül veszi észre, hogy a folyamat nehezen érthető. Ezért a két módszer gyakran egymást egészíti ki.

QA-mérnök kiválasztása

A QA-mérnök kiválasztásakor érdemes megnézni, milyen típusú rendszerekkel dolgozott korábban, és mennyire érthetően írja le a hibákat. Fontos kérdés, hogy csak kézi tesztelést végez e, vagy szükség esetén automatizált ellenőrzéseket is tud készíteni. Magánmegbízásnál azonban nem kell minden technikai lehetőséget igénybe venni. A feladathoz illő módszer fontosabb.

Érdemes előre rögzíteni, hány tesztelési kör tartozik a megbízásba, milyen eszközöket kell vizsgálni, és a javítás utáni visszaellenőrzés benne van e az árban. Ha több felhasználói szerepkör van, azt is tisztázni kell, melyiket próbálja végig a szakember.

Ezen az oldalon az ajánlatok összevetésekor szerintem a leadott eredményt kell összehasonlítani. Az egyik ajánlat csak hibajegyzéket tartalmazhat, a másik teszttervet, súlyossági besorolást és visszaellenőrzést is. Ugyanaz a végösszeg így eltérő mennyiségű munkát jelenthet.

QA mérnöki árak

A díj a rendszer méretétől, a vizsgált funkciók számától, az eszközök és felhasználói szerepkörök mennyiségétől függ. Automatizált tesztek kialakítása külön ráfordítást igényel. Egy rövid állapotfelmérés kevesebb munkával jár, mint egy teljes kiadás előtti ellenőrzés és a javítások utáni újratesztelés.

Személyes véleményem szerint 15.000 forint alatt ritkán várható érdemi mérnöki szintű felmérés, ha dokumentált eredményre is szükség van. Egy nagyon rövid próba lehet olcsóbb. Ha viszont több folyamatot kell megtervezetten ellenőrizni, a hibákat rögzíteni és a javításokat visszatesztelni, ennél nagyobb ráfordítás reális. A túl alacsony árnál megkérdezném, pontosan mi marad ki a munkából.

QA szakember Salgótarján környékén

Salgótarján környékén a helyszíni munka főként olyan programnál lehet szükséges, amely belső hálózaton, külön számítógépen vagy helyi eszközzel együtt működik. Zagyvapálfalva, Baglyasalja, Somoskő és Somoskőújfalu térségéből is kereshető szakember, ha személyes jelenlét indokolt. Interneten elérhető alkalmazásnál a tesztelés jellemzően távolról is elvégezhető.

Távoli teszteléshez külön próbahozzáférés célszerű. Érzékeny adatok helyett lehetőség szerint tesztadatokat kell használni. Ha a valós adatok elkerülhetetlenek, a szakember csak a feladathoz szükséges jogosultságot kapja meg. A munka lezárása után az ideiglenes hozzáférést érdemes megszüntetni.

A minőségbiztosítás akkor ad valódi értéket, ha az eredménye alapján dönteni lehet. A végén legyen világos, mely hibák maradtak nyitva, melyeket javították, és milyen környezetben történt az ellenőrzés. Én a legfontosabb folyamatokat az utolsó változaton még egyszer végigpróbálnám. Így nem csak egy hibajegyzék marad az ügyfélnél, hanem ellenőrizhető kép arról is, milyen állapotban van a rendszer.