QA engineerek Szegeden: Vélemények és kedvező árak

QA engineer magánprojektekhez

A QA engineer akkor segít, amikor egy weboldal, alkalmazás vagy kisebb digitális rendszer hibáit még éles használat előtt kell megtalálni. Magánügyfeleknél ez gyakran nem nagy céges folyamat. Inkább egy webshop, időpontfoglaló oldal, saját fejlesztésű alkalmazás, tanfolyami platform vagy belső használatú eszköz átnézése. A lényeg egyszerű. A felület működjön, a megrendelések ne vesszenek el, az űrlapok küldjenek adatot, és a felhasználó ne akadjon el az első percben.

Qjob.hu felületén különböző szakemberek között lehet keresni, nem egyetlen cég ajánlatát kapja az ügyfél. Ez fontos, mert egy kisebb feladatnál sokszor nem teljes tesztelő csapatra van szükség, hanem egy tapasztalt minőségbiztosítási mérnök pár órás vagy pár napos munkájára. Szeged esetében gyakori, hogy a megbízó helyi egyeztetést szeretne, de maga a tesztelés távolról is elvégezhető. Ettől még jó, ha a szakember érti a helyi vállalkozások tempóját és azt, hogy a hibák javítására nincs mindig külön projektvezető.

Saját tapasztalatom szerint a legjobb eredmény akkor születik, ha az ügyfél nem csak azt mondja, hogy nézd át az oldalt. Ennél pontosabb kérés kell. Például regisztráció ellenőrzése, fizetési folyamat próbája, mobilos nézet vizsgálata, hibajegyek készítése vagy új funkció átvétele. Sokan azt hiszik, hogy a QA csak kattintgatás. Ez tévedés. Egy jó szoftvertesztelő nem véletlenszerűen nézi végig a felületet, hanem kockázat alapján halad.

Mikor kell QA ellenőrzés

QA ellenőrzésre akkor van szükség, ha a fejlesztő már elkészült a munkával, de az ügyfél nem biztos benne, hogy minden részlet stabil. Egy kisebb weboldalnál is lehetnek olyan hibák, amelyek csak bizonyos böngészőben jönnek elő. Máskor az űrlap jól néz ki, de nem küldi el az üzenetet. Előfordul, hogy a kosár számolása hibás, a kedvezménykód rosszul működik, vagy a mobilos menü eltakar egy fontos gombot.

Magánügyfeleknél a tesztelés gyakran egy döntés előtt jön. Mehet élesbe az oldal, vagy még javítani kell rajta. Ilyenkor a QA szakember nem csak hibát keres, hanem segít eldönteni, mi számít komoly gondnak és mi várhat. Ez különösen hasznos, ha a fejlesztő és az ügyfél között vita van. A hibajegy ilyenkor tárgyilagos nyelvet ad. Nem érzés alapján megy a beszélgetés, hanem képernyőképpel, lépésekkel és várt eredménnyel.

Volt eset, amikor egy ügyfél egy egyszerűnek tűnő foglalási oldalt kért átnézni. A felület szép volt, de a visszaigazoló üzenet rossz dátumot mutatott, ha a látogató mobilról foglalt este nyolc után. A fejlesztő először nem látta a hibát, mert asztali gépen próbálta. A tesztelő szakember pontos lépésekkel leírta a helyzetet, így a javítás gyors lett. Ez nem látványos munka, de sok kellemetlenséget megelőz.

QA engineer árak és munkadíjak

A QA engineer díja a feladat méretétől, a dokumentáció állapotától és a tesztelés mélységétől függ. Egy rövid átnézés olcsóbb, mint egy teljes tesztterv készítése. 12.000 forint alatt ritkán szokott megbízható lenni, ha valódi ellenőrzésről van szó, nem csak pár kattintásról. Szerintem az is gyanús, ha valaki nagy rendszert vállal nagyon gyorsan, kérdések nélkül.

Az árak nem csak óradíjat jelentenek. A jó tesztelésben benne van az előkészítés, a próbaadatok létrehozása, a hibák rendszerezése és a javítás utáni ismételt ellenőrzés. Sok megbízó ezen spórolna, de pont itt vész el a lényeg. Ha a hibát nem lehet újra előidézni, a fejlesztő nehezen javítja. Ha nincs súlyossági besorolás, minden egyformán sürgősnek tűnik.

Szakember választása QA munkára

A szakember választásánál nem az a legfontosabb, hogy valaki hány eszköznevet sorol fel. Fontosabb, hogy tud-e világosan kérdezni. Egy QA engineer jó esetben rákérdez a célra, a felhasználókra, a böngészőkre, az eszközökre és arra, hogy mi számít hibának. Ha ezt nem teszi meg, könnyen félremegy a munka. Lehet, hogy sok apróságot talál, de a valóban fontos folyamatot nem nézi meg.

Én személy szerint azt szeretem, ha a minőségbiztosítási mérnök már az elején megmondja, milyen formában adja át az eredményt. Egyszerű lista is elég lehet, de legyen benne lépés, tényleges eredmény, várt eredmény és bizonyíték. Egy rövid videó néha többet ér, mint hosszú szöveg. De nem kell mindent túlbonyolítani. Kis projektnél a túl nagy módszertan csak lassít.

Sok ügyfél ott hibázik, hogy csak a legolcsóbb ajánlatot nézi. A tesztelésnél ez különösen veszélyes. Egy gyenge ellenőrzés hamis biztonságot ad. Az oldal élesedik, majd a látogatók találják meg a hibákat. Ez rosszabb, mint ha előre tudjuk, hogy van még javítanivaló. Egy megbízható tesztelő szakember nem ígéri, hogy minden hibát megtalál. Inkább elmondja, milyen területet fed le a vizsgálat, és hol marad kockázat.

QA feladatok Szeged környékén

Szeged városrészeiben eltérő típusú ügyfelek kereshetnek QA segítséget. Belvárosi szolgáltatóknál gyakori az időpontfoglaló és kapcsolatfelvételi oldal ellenőrzése. Újszegeden sokszor kisebb vállalkozói weboldalak, oktatási anyagok vagy online jelentkezési felületek kerülnek elő. Rókus, Móraváros és Alsóváros környékén előfordul webshop, helyi szolgáltatói oldal vagy belső nyilvántartó rendszer tesztelése is.

A helyi kapcsolat akkor hasznos, ha személyes egyeztetés kell, vagy a megbízó nem szeret hosszú írásos leírást készíteni. De a QA munka nagy része távolról is jól elvégezhető. Egy hozzáférés, egy rövid leírás és néhány próbaadat sokszor elég az induláshoz. Szeged mellett Algyő, Deszk, Sándorfalva és Tiszasziget felől is lehet olyan magánügyfél, akinek nem fejlesztőre, hanem független ellenőrzésre van szüksége.

Helyi projekteknél gyakori probléma, hogy a weboldal készítője és az ügyfél régóta ismeri egymást, ezért nehéz nyíltan kimondani, hogy valami nem működik. Egy külső szoftvertesztelő ilyenkor leveszi a személyes feszültséget. Nem bántó véleményt ad, hanem ellenőrzési eredményt. Ez egyszerűbbé teszi a javítást.

Hibajegyek és átadás

A jó hibajegy rövid, de elég pontos. Leírja, hol jelent meg a gond, milyen lépéssel ismételhető, mi történt valójában, és mi lett volna a helyes működés. Nem kell hosszú jelentés minden apróságról. De a fejlesztőnek értenie kell, mit javítson. A homályos megjegyzés, hogy valami nem jó, kevés. Az ilyen visszajelzés csak újabb köröket okoz.

A QA munka akkor hasznos igazán, ha az átadás nem csak egy hibákból álló lista. Kell egy rövid összkép is. Mi akadályozza az élesítést. Mi zavaró, de nem kritikus. Mi az, ami csak kényelmi javítás. Ezt a különbséget sok magánügyfél nem látja elsőre, pedig a döntéshez szükséges. Nem minden hibát kell azonnal javítani, de a fizetést, regisztrációt, adatküldést és jogosultságot érintő hibák ritkán várhatnak.

Hasznos, ha a javítás után van visszatesztelés. Sokszor egy módosítás máshol okoz új hibát. Ez nem feltétlenül rossz fejlesztői munka, inkább a szoftverek természetes kockázata. Saját tapasztalatom alapján a nyugodt projektzárás feltétele az, hogy az ügyfél ne csak a hibákat kapja meg, hanem értse is a következő lépést. Így a QA szolgáltatás nem felesleges plusz kör, hanem egy egyszerű biztosíték a használható végeredményhez.