QA software testerek Veszprémben: Vélemények és kedvező árak

QA software tester Veszprémben szoftverek ellenőrzésére

A QA software tester akkor hasznos, amikor egy weboldal, alkalmazás, belső rendszer vagy kisebb digitális szolgáltatás már működik, de még nem biztos, hogy hibamentesen, érthetően és kiszámíthatóan használható. Magánügyfeleknél és kisebb vállalkozásoknál ez lehet időpontfoglaló, webáruház, ügyfélkezelő felület, mobilalkalmazás, oktatási rendszer vagy egyedi belső program. Veszprémben sok ilyen megbízás nem nagy fejlesztőcsapathoz kapcsolódik, hanem konkrét, gyakorlati ellenőrzéshez. A Qjob.hu felületén különböző szakemberek vállalhatnak ilyen tesztelési munkát, nem egyetlen cég szolgáltatásáról van szó.

A QA software tester nem csak véletlenszerűen kattintgat. Megnézi, hogy a rendszer azt csinálja e, amit az ügyfél vár. Ellenőrzi az űrlapokat, a belépést, a jogosultságokat, a hibajelzéseket, az adatmentést, a böngészők közötti különbségeket és a fő felhasználói folyamatokat. Személy szerint azokat a tesztelőket tartom hasznosnak, akik nem csak hibát találnak, hanem pontosan leírják, hogyan lehet azt újra előidézni. Egy jó hibajegy sok fejlesztői időt takarít meg.

Sokan hibáznak, amikor a tesztelést a munka legvégére hagyják. Már kész a felület, közeleg az átadás, és akkor derül ki, hogy a regisztráció nem működik egyes böngészőkben, vagy a visszaigazoló e mail rossz adatot tartalmaz. Ilyenkor a javítás drágább és idegesebb. Egy szoftvertesztelő korábban is bevonható, akár félkész rendszerhez is, mert a hibák egy része már akkor látszik.

Szoftvertesztelési feladatok

A szoftvertesztelés többféle munkát jelenthet. Lehet funkcionális teszt, regressziós teszt, felhasználói útvonal ellenőrzése, űrlapteszt, jogosultsági próba, mobilos ellenőrzés, böngészőteszt vagy egyszerű elfogadási teszt. Magánügyfeleknél gyakran nem kell nagy tesztelési rendszer. Elég egy pontos lista arról, hogy a legfontosabb folyamatok működnek e.

Volt eset, amikor egy kis webes foglalási felület fejlesztője szerint a rendszer készen állt. A tesztelő végigment a fő folyamaton, majd kipróbálta azt is, mi történik, ha a felhasználó visszalép, üres mezőt hagy, vagy kétszer nyomja meg a küldés gombot. A rendszer több foglalást hozott létre ugyanarra az időpontra. A hiba nem látszott a szokásos próbán, csak a kevésbé szabályos használatnál. Ezért fontos a tesztelés.

A jó teszt nem csak a helyes utat nézi. A felhasználó hibázik, gyorsan kattint, félreérti a mezőt, régi böngészőt használ, vagy mobilról próbálja elvégezni ugyanazt, amit a fejlesztő nagy monitoron tesztelt. A QA szakember ezeket a helyzeteket keresi meg és rendezi visszajelzéssé.

Manuális tesztelés és hibajegyek

A manuális tesztelés sok kisebb projektnél elég. A tesztelő végigmegy a megadott folyamatokon, figyeli az eltéréseket, és hibajegyeket készít. Egy használható hibajegy tartalmazza a rövid címet, a lépéseket, az elvárt eredményt, a tényleges eredményt, az eszközt, a böngészőt, a képernyőképet és a hiba súlyosságát. Ez nem túlzás. Enélkül a fejlesztő gyakran nem tudja megismételni a gondot.

Sokan csak annyit írnak, hogy nem működik a gomb. Ez kevés. Melyik oldalon, milyen belépéssel, milyen adatokkal, milyen eszközön, és mi történt pontosan. A QA software tester értéke abban van, hogy a hibából javítható információt csinál. Nem minden hiba egyformán fontos. Egy elgépelés más súlyú, mint egy elvesző rendelés.

Én szeretem, ha a tesztelő külön jelöli a súlyosságot. Blokkoló, fontos, kisebb hiba vagy észrevétel. Így az ügyfél nem érzi úgy, hogy minden egyszerre ég. A fejlesztő pedig tudja, mivel kezdjen. Ez különösen hasznos, ha a költség vagy a határidő szűk.

Weboldalak és mobilos ellenőrzés

Weboldalaknál és mobilos felületeknél a tesztelés gyakran egyszerűnek tűnik, de sok apró részleten múlik. Másképp viselkedhet az űrlap telefonon, tableten és asztali gépen. A menü elcsúszhat, a gomb túl kicsi lehet, a fizetési folyamat félbeszakadhat, vagy a hibaüzenet nem látható. Egy szoftverminőség ellenőr ezeket rendszerezetten nézi.

Nem minden eszközön kell mindent ugyanúgy tesztelni. Először a legfontosabb felhasználói útvonalakat érdemes kiválasztani. Például regisztráció, belépés, keresés, kosár, rendelés, foglalás, üzenetküldés vagy dokumentum feltöltése. Ezeket kell végigpróbálni több környezetben. Ha ezek stabilak, a kisebb részek később jöhetnek.

A mobilos ellenőrzésnél a lassabb internet, a kisebb képernyő és az érintés pontatlansága is számít. A fejlesztő sokszor ideális környezetben nézi a rendszert. A felhasználó nem. A tesztelő feladata, hogy közelebb vigye a próbát a valós használathoz.

QA software tester árak

Az ár attól függ, hogy milyen rendszer teszteléséről van szó, hány folyamatot kell ellenőrizni, hány eszközön történik a próba, kell e részletes hibajegy, és lesz e újrateszt. Olcsóbban 7.000 forintnál óránként ritkán lesz jó minőségű tesztelés, ha pontos jegyzet, képernyőkép, böngészőadat és ismételhető hibaleírás is kell. Lehet olcsóbb gyors véleményezés, de az nem ugyanaz, mint a szervezett QA munka.

Fix díj akkor működik jól, ha a tesztelendő funkciók listája adott. Óradíj akkor ésszerűbb, ha a rendszer még sokat változik, vagy nincs pontos határ. Sok félreértés abból jön, hogy az ügyfél teljes átnézést kér, de közben csak néhány órás keretet szán rá. A tesztelésnél a mélységet előre kell tisztázni.

Szakember választása

A megfelelő QA szakember kiválasztásánál nem elég az, hogy valaki türelmesen használja a rendszert. Fontos, hogy pontosan írjon, rendszerezetten gondolkodjon, és el tudja választani a hibát a személyes véleménytől. Egy szoftvertesztelő akkor hasznos, ha a fejlesztő érti a visszajelzését, az ügyfél pedig látja, melyik probléma sürgős.

Érdemes megkérdezni, milyen formátumban adja át a hibákat. Táblázat, képernyőkép, rövid videó, hibajegykezelő vagy összefoglaló. Kis projektnél egy egyszerű táblázat is elég lehet. A lényeg, hogy visszakereshető legyen. Ha a tesztelő csak szóban mondja el a hibákat, abból később könnyen vita lesz.

Én olyan tesztelőt választanék, aki az elején rákérdez a célra. Mit kell biztosan működőnek tekinteni, melyik felhasználói útvonal a legfontosabb, milyen eszközökön várható használat, és mi a határidő. Aki mindent egyszerre akar tesztelni kevés időből, az nem lesz pontos.

Veszprémi tesztelés és környék

Veszprémben a QA tesztelés többnyire távolról is végezhető, de a helyi egyeztetés néha előny. A belváros, Egyetemváros, Dózsaváros, Cholnokyváros és a Jutasi úti lakótelep környéke kényelmes lehet megbeszélésre, ha a megbízó személyesen szeretné megmutatni a rendszert. A közeli települések, például Balatonalmádi, Herend, Márkó, Nemesvámos és Várpalota felől is életszerű a megbízás, mert a legtöbb szoftveres teszt online hozzáféréssel működik.

A helyi jelenlét akkor fontosabb, ha a rendszer helyszíni eszközhöz, belső hálózathoz vagy irodai használathoz kötődik. Egy egyszerű weboldal vagy mobilos felület távolról is jól tesztelhető. Veszprém környékén sok kisebb vállalkozás nem tart saját minőségbiztosítási embert, de átadás előtt szüksége lehet külső szemre.

A távoli teszteléshez rend kell. Legyen tesztverzió, belépési adat, rövid feladatlista és visszajelzési forma. Ha ezek hiányoznak, a tesztelő ideje nem a hibák keresésére megy el, hanem arra, hogy kitalálja, mit is kell néznie.

Előkészítés és átadás

A tesztelés előtt érdemes összegyűjteni a rendszer címét, a belépési adatokat, a tesztelendő funkciók listáját, a támogatott eszközöket és az ismert hibákat. Nem kell mindent eltitkolni a tesztelő elől. Ha egy részről már tudni lehet, hogy bizonytalan, jobb jelezni. Így célzottabban nézi meg.

Hasznos külön tesztadatokat adni. Ne éles ügyféladatokkal induljon a próba, ha nem muszáj. Legyen próba felhasználó, próba rendelés, próba foglalás vagy teszt fájl. Ez biztonságosabb, és később könnyebb törölni. A QA software tester munkája akkor tisztább, ha nem kell valódi ügyféladatok között kísérleteznie.

Az átadásnál a tesztjelentés legyen rövid, de használható. Tartalmazza a talált hibákat, a súlyosságot, az ismétlés lépéseit és azokat a részeket is, amelyek rendben működtek. Ez utóbbi sokszor kimarad, pedig fontos. Az ügyfél így látja, hogy nem csak hibakeresés történt, hanem ellenőrzött területek is vannak.

A tesztelés akkor jó, ha utána kevesebb a találgatás. Nem kell minden apróságot azonnal javítani, de a sorrend legyen világos. Mi akadályozza az éles indulást, mi rontja a használatot, és mi várhat későbbre. Így egy Veszprémben készülő kisebb szoftveres projekt is nyugodtabban adható át.