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

Quality assurance tester

A Quality assurance tester akkor kell, amikor egy weboldal, ügyfélfelület vagy kisebb rendszer már majdnem kész, mégsem lehet rá nyugodtan rábízni a használókat. Ilyenkor nem új funkció a fő kérdés, hanem az, hogy a meglévő rész valóban működik-e. Pécs környékén ez sok magánmegrendelőnél ott bukik ki, amikor a belépés néha sikerül, néha nem, az űrlap elküldi az adatot, de nem mindig, vagy a mobilos nézet teljesen szétesik. Szerintem a hiba itt nem technikai részlet. Inkább bizalmi gond. Ha valami egyszer rosszul működik, a látogató másodszor már türelmetlenebb lesz.

Sokan azt hiszik, hogy a fejlesztő végső ellenőrzése elég. De sokan hibáznak akkor, amikor ugyanaz az ember építi és saját maga igazolja vissza a rendszert. Egy külső szem mást vesz észre. A Quality assurance tester éppen ezért hasznos. Lépésről lépésre végigpróbálja a valós helyzeteket. Nem azt nézi, papíron minek kellene történnie, hanem azt, mi történik ténylegesen. Egy jó szoftvertesztelő nem akadékoskodik. Inkább megelőzi azt a kellemetlen pillanatot, amikor a hibát már az ügyfél mutatja meg.

Mikor érdemes tesztelőt bevonni

Minőségbiztosítási tesztelőre nem csak a lezárás előtti napokban lehet szükség. Ez az egyik leggyakoribb tévedés. Ha túl későn kerül be, akkor már minden javítás lassabb, drágább és idegesítőbb. Sokkal jobb akkor bevonni, amikor a fő folyamatok már láthatók, de még lehet változtatni. Ilyen pont a regisztráció, a foglalás, a kapcsolatfelvételi űrlap, a fizetés előtti lépés vagy egy egyedi ügyféloldal használata. És igen, kisebb privát projektnél is számít. Egy egyszerűnek tűnő felület is okozhat komoly bosszúságot.

Volt olyan eset, amikor egy megrendelő biztos volt benne, hogy csak apró hibák vannak a kész oldalán. Kívülről tényleg rendezettnek látszott. A tesztelés alatt mégis kiderült, hogy bizonyos telefonokon a gomb nem kattintható, egy hosszabb név törte a felületet, és a hibás mezőkitöltésnél semmilyen érthető visszajelzés nem jelent meg. A tulajdonos először túlzásnak tartotta ezt. Később belátta, hogy ezek nem díszhibák voltak. Hanem olyan gondok, amelyek miatt az érdeklődő csendben kilép.

Milyen hibák derülnek ki tesztelés közben

A szoftvertesztelés során gyakran nem a látványos összeomlás a fő probléma. Hanem a kisebb, alattomos hibák. Rossz mezősorrend. Félreérthető gombszöveg. Nem működő visszalépés. Olyan oldal, amely asztali gépen rendben van, de mobilon kényelmetlen. A minőségbiztosítási tesztelő ezeket rendszerben nézi. Megnézi, mi történik helyes adatnál, hibás adatnál, üres mezőnél, lassabb kapcsolaton és különböző böngészőkben. Ettől lesz haszna a munkának.

Én ezt a szolgáltatást különösen hasznosnak tartom azoknál a megbízásoknál, ahol a tulajdonos nem műszaki ember. Ott ugyanis könnyű bedőlni annak, hogy valami késznek tűnik. De a valós használat szinte mindig kegyetlenebb, mint a bemutató. Egy tesztelő szakember nem csak hibalistát adhat, hanem sorrendet is. Mi sürgős. Mi zavaró, de halasztható. Mi az, ami csak ritka helyzetben jön elő. Ez azért fontos, mert nem minden hibát kell ugyanazon a napon javítani.

Quality assurance tester árak

A Quality assurance tester díja több dologtól függ. Mennyi oldalt vagy folyamatot kell végignézni, kell-e írásos hibajegy, van-e ismételt ellenőrzés a javítás után, és mennyire összetett a felület. Pécs térségében a kisebb magánprojektek ára még kezelhető szinten marad, de csak akkor, ha a megrendelő pontosan leírja, mit kell kipróbálni. Ha minden homályos, az ár is bizonytalanabb lesz. Szerintem a túl olcsó vállalás itt gyanús. Mert egy alapos ellenőrzés időigényes munka.

Ezek az összegek nem kirívóak, de nem is olcsók. Őszintén szerintem akkor fájnak igazán, ha valaki előtte már fizetett fejlesztésért, és most még egyszer költenie kell. Mégis sokszor ez a kisebb veszteség. Egy rosszul működő oldal csendben több érdeklődőt visz el, mint amennyit elsőre sejtene az ember.

Hogyan válassz quality assurance testert

A választásnál nem az a fő kérdés, ki ír a leghosszabban magáról. Inkább az, tud-e világosan gondolkodni. Egy jó szakember megkérdezi, kik használják a felületet, melyik résznél van a legtöbb panasz, mi számít súlyos hibának, és kell-e dokumentált átadás. Ha csak annyit mond, hogy mindent letesztel, az nekem kevés. A valódi munka mindig határokkal indul.

Érdemes megnézni, hogy a szoftvertesztelő hogyan kommunikál a hibákról. Röviden, érthetően, javítható módon írja le őket, vagy túl általánosan fogalmaz. Ez nem mellékes. Mert ha a fejlesztő nem tudja pontosan reprodukálni a hibát, akkor a javítás is elcsúszik. A Qjob.hu felületén ezért jó irány lehet az olyan jelentkező, aki nem csak vállalást ír, hanem kérdez is. Itt látszik meg, hogy tényleg átnézi majd a munkát, vagy csak gyorsan végigkattint pár oldalt.

Ami a megrendelésnél gyakran hiányzik

Sok magánügyfél túl rövid feladatleírást ad. Azt írja, hogy egy oldal tesztelése kell. De ebből semmi lényeges nem derül ki. Nem tudni, hány folyamat van, van-e belépés, kell-e mobilos próba, fontos-e több böngésző, van-e adminfelület, és mi a valódi gond. A tesztelő szakember ilyenkor vagy visszakérdez, vagy tippel. Az első jobb, a második kockázatos.

És van még egy gyakori hiba. A megrendelő nem írja le, hogy ki használja majd a rendszert. Pedig nem mindegy, hogy fiatal, rutinos felhasználó kattint rajta végig, vagy idősebb ügyfél, aki lassabban halad. Más útvonalat kell nézni. Más ponton akad el. Pécs környékén is ez dönt sokszor. Nem a technika szintje, hanem az, hogy a felület illik-e a valós használóhoz.

Tesztelés Pécs környékén

Pécs esetében a személyes találkozó néha előny, de nem minden projektnél szükséges. Sok ellenőrzés távolról is jól elvégezhető, ha a hozzáférések rendben vannak és a feladat világos. De vannak megrendelők, akik jobban szeretik, ha röviden át tudják beszélni a fő gondot. Ez érthető. Főleg akkor, ha korábban már csalódtak fejlesztésben vagy javításban.

A Quality assurance tester munkája nem látványos, mégis gyakran ez adja meg a nyugalmat a végén. Ha rendben van a belépés, a küldés, a visszajelzés, a mobilos használat és a hibakezelés, akkor a rendszer végre nem csak elkészültnek látszik, hanem használható is lesz. És ez az a pont, ahol a tesztelés ára már nem külön tehernek tűnik, hanem ésszerű ellenőrzésnek.