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

Quality assurance tester magánügyfeleknek Szegeden

A Quality assurance tester akkor segít, ha egy weboldal, alkalmazás vagy online folyamat működését független szemmel kell ellenőrizni. Magánügyfélként ez gyakran egy új honlap, időpontfoglaló, webáruház, tanfolyami felület vagy kisebb ügyviteli rendszer átnézését jelenti. Szegeden sok ilyen munka nem nagy céges ellenőrzés, hanem gyakorlati próba. Meg kell nézni, hol akad el a felhasználó, melyik hiba zavaró, és mi az, ami valóban sürgős javítást kér.

A Qjob.hu felületén különböző önálló szakemberek között lehet keresni, ezért a megbízó nem egy cég általános csomagját kapja. Ez jó, de csak akkor, ha a feladat elején pontos a leírás. Nem elég annyi, hogy nézze át valaki az oldalt. Kell a cél, a fontos folyamatok listája, a használt eszközök köre, és az is, hogy milyen hibától tart leginkább az ügyfél.

Én személy szerint jobban szeretem, amikor a tesztelés kisebb, de pontos körrel indul. Például csak a regisztráció, a rendelés, a fizetés előtti lépések vagy a kapcsolatfelvételi űrlap ellenőrzése. Egy ilyen munka tisztábban mérhető. A Quality assurance tester nem varázsol hibátlan rendszert egy rosszul átadott projektből, de láthatóvá teszi, hol van a kockázat.

Minőségbiztosítási tesztelés kisebb rendszereknél

A minőségbiztosítási tesztelés lényege nem az, hogy valaki sokat kattint. A cél az, hogy a rendszer valós helyzetben is érthetően és megbízhatóan működjön. Egy magánügyfélnek ez különösen fontos, mert gyakran nincs saját fejlesztői csapata. Ha egy hibás oldal élesben marad, a vevők, jelentkezők vagy ügyfelek egyszerűen továbbállnak.

A szoftvertesztelő ilyenkor szerepeket, eszközöket és útvonalakat próbál. Megnézi, hogy egy új felhasználó tud-e regisztrálni, kap-e értesítést, jó helyre kerül-e az adat, és mi történik hibás kitöltésnél. Egy egyszerűnek tűnő űrlapnál is lehet gond. Rossz kötelező mező, eltűnő hibaüzenet, lassú betöltés, hibás visszaigazolás. Ezek külön-külön apróságoknak tűnnek, együtt viszont bizalmat rombolnak.

Volt eset, amikor egy kliens azt hitte, hogy a gond a bankkártyás fizetéssel van. A teszt során kiderült, hogy a vásárló már korábban elakadt, mert mobilon nem látszott a szállítási mód választása. A fizetési oldalhoz sokan el sem jutottak. Ez jó példa arra, miért érdemes a teljes felhasználói utat nézni, nem csak azt a pontot, ahol a panasz megjelenik.

QA ellenőrzés átadás előtt

Átadás előtt a QA ellenőrzés egyik legfontosabb feladata, hogy elválassza a késznek mondott állapotot a valóban használható állapottól. Egy fejlesztő sokszor a saját gépén, saját belépésével próbálja a rendszert. Ez nem ugyanaz, mint amikor egy új felhasználó telefonnal, lassabb kapcsolattal vagy hiányos adatokkal érkezik.

Sok megbízó ott hibázik, hogy csak a kinézetet nézi. Szép-e a főoldal, jó-e a szín, rendben van-e a logó. Ezek sem mellékesek, de a működés fontosabb. Ha a jelentkezési űrlap nem küld levelet, ha az admin felületen nem mentődik az adat, vagy ha a jelszó-visszaállítás hibás, akkor a projekt még nincs készen. A tesztelő szakember ezt tárgyilagosan tudja jelezni.

Az átadás előtti vizsgálatnál hasznos rövid listát készíteni. Melyik oldal a legfontosabb. Melyik folyamat hoz bevételt vagy ügyfelet. Hol volt korábban hiba. Milyen készülékeken kell működnie a rendszernek. Ha ez megvan, a munka nem csúszik át végtelen ellenőrzésbe.

Quality assurance tester árak

Az ilyen tesztelés díja főleg attól függ, hogy mennyi folyamatot kell ellenőrizni, mennyire részletes jelentésre van szükség, és kell-e javítás utáni visszatesztelés. Egy egyszerű bemutatkozó oldal átnézése gyorsabb, mint egy több lépéses rendelési folyamat vagy admin felület vizsgálata. Szerintem 12.000 alatt ritkán várható alapos munka, ha nem csak véleményt, hanem használható hibajegyeket is kér a megbízó.

Az árnál nem csak a munkaóra számít. Az is fontos, milyen formában kapja meg az ügyfél az eredményt. Egy üzenetben elküldött pár sor olcsóbb lehet, de nehezebb vele dolgozni. Egy rendezett hibajegyzék képernyőképpel, lépésekkel és fontossági sorrenddel többet ér. Főleg akkor, ha a fejlesztőnek kell továbbadni.

Tesztelő szakember választása

A megfelelő tesztelő szakember kiválasztásánál a kérdései sokat elárulnak. Rákérdez-e a célra, a felhasználókra, az eszközökre és az átadás módjára. Külön kezeli-e a hibákat, a javaslatokat és a felhasználói kényelmetlenségeket. Ha valaki minden részlet nélkül azonnal teljes vizsgálatot ígér, az nekem inkább bizonytalan jel.

Jó, ha a szakember tud példát mondani arra, hogyan épít fel egy hibajelentést. Nem kell korábbi ügyféladatokat mutatnia. Elég, ha látszik a munkamódszer. Milyen adat kerül egy hibához. Van-e súlyosság. Van-e ismétlési lépés. Kap-e az ügyfél rövid összegzést arról, mit érdemes először javítani.

A minőségbiztosítási szakember nem fejlesztő helyett dönt. Nem is az a dolga, hogy minden hibára kész megoldást adjon. Az a feladata, hogy pontosan megmutassa a gondot. Sok vita éppen azért keletkezik, mert a hiba leírása homályos. Azt írni, hogy nem működik, kevés. Azt leírni, hogy melyik gomb után, milyen adatokkal, milyen eszközön jelent meg a hiba, már használható.

Helyi tesztelés Szeged városrészeiben

Szeged helyi projektjeinél a tesztelés gyakran kapcsolódik valós ügyfélutakhoz. Egy belvárosi rendelő időpontfoglalója, egy újszegedi szolgáltató ajánlatkérő oldala, egy rókusi üzlet webes rendelési felülete vagy egy móravárosi oktató jelentkezési oldala más-más helyzetet hozhat. A technikai működés mellett számít, hogy a helyi felhasználó gyorsan megtalálja-e a címet, az elérhetőséget és a következő lépést.

Távoli ellenőrzés a legtöbb esetben elég. A szakembernek nem kell mindig személyesen jelen lennie. De ha a rendszer helyszíni szolgáltatáshoz, térképhez, kiszállításhoz vagy időponthoz kötődik, akkor a helyi részletek is számítanak. A városrészek, környező települések és útvonalak hibás megjelenése megtévesztheti az ügyfelet. Algyő, Deszk, Sándorfalva vagy Mórahalom felől érkező felhasználóknál például a távolság, nyitvatartás és foglalás egyszerre lehet fontos.

Szegeden sok magánmegbízásnál a telefonos használat a döntő. Az ember siet, keres egy szolgáltatót, megnyitja az oldalt, és azonnal kapcsolatot akar. Ha a hívás gomb nem működik, ha az űrlap túl hosszú, vagy ha a térkép rossz helyre visz, a hiba nem apróság.

Hibajelentés és visszatesztelés

A hibajelentés akkor jó, ha a fejlesztő újra tudja idézni belőle a hibát. Ehhez nem kell hosszú műszaki szöveg. Kell az oldal vagy képernyő neve, a megtett lépések, az elvárt eredmény, a tényleges eredmény és lehetőleg egy kép. Rövid videó is hasznos lehet, ha a hiba mozgás közben látszik.

A visszatesztelés sokszor alulértékelt rész. A javítás után nem elég megkérdezni, hogy készen van-e. Meg kell nézni, hogy az eredeti hiba megszűnt-e, és nem jelent-e meg új gond a közelében. Egy kosár javítása például hatással lehet az értesítésekre. Egy belépési hiba javítása érintheti a jelszó-visszaállítást. Ezért a második kör nem felesleges óvatosság.

Saját tapasztalatom szerint a legjobb eredmény akkor születik, amikor a megbízó elfogadja, hogy a hibalista nem támadás. Sok ügyfél személyes kritikának veszi, ha kiderül, hogy a frissen elkészült oldala több ponton hibás. Pedig ez a folyamat része. Jobb kontrolláltan megtalálni a gondot, mint éles használat közben.

Mit érdemes előkészíteni a QA munkához

A munka gyorsabb, ha az ügyfél előre összeszedi a belépési adatokat, a tesztelésre szánt linkeket, a fontos folyamatokat és azokat az eszközöket, amelyeken ellenőrzést kér. Nem kell mindent egyszerre vizsgálni. Sőt, sokszor jobb kisebb csomaggal kezdeni. Például csak a kapcsolatfelvételi folyamat, csak a rendelés, vagy csak az admin mentés.

Hasznos, ha van rövid leírás arról, mi számít sikeres működésnek. Ha valaki elküld egy űrlapot, hova érkezzen az üzenet. Ha rendelést ad le, milyen értesítés menjen ki. Ha admin felületen módosít adatot, hol kell megjelennie. Ezek egyszerű dolgok, mégis sok félreértést megelőznek.

A Quality assurance tester munkája akkor ad valódi értéket, ha a végén dönthető helyzetet teremt. Mit kell azonnal javítani, mi várhat, és mi csak kényelmi javaslat. Nem kell túlbonyolítani. Egy tiszta lista, néhány jó képernyőkép és egy rövid összegzés gyakran többet segít, mint egy hosszú, nehezen olvasható dokumentum.