QA-mérnökök Miskolcon: Vélemények és kedvező árak

QA-mérnök Miskolc környékén magánmegbízásra

Ha QA-mérnök kell, akkor valójában nyugalmat veszel meg, nem csak hibakeresést. Miskolc térségében sok magánmegbízó akkor kér segítséget, amikor már élesben dől a panasz, és a fejlesztő csak tűzolt. Én személy szerint jobban bízom abban, ha a minőségbiztosítás már a következő kiadás előtt rendet tesz, mert a javítás ilyenkor kisebb, és nem kell utólag magyarázkodni a felhasználóknak.

Sokszor látom ugyanazt a konfliktust. A megrendelő gyorsan akar haladni, a fejlesztő meg azt mondja, működik nálam. A kettő között ott áll a felhasználó, aki egyszerűen csak használni szeretné. Itt tud jó lenni egy tesztelési mérnök, aki nem véleményt ad, hanem bizonyítékot, pontos lépéseket és képernyőképet. És közben kimondja azt is, mi a kockázat, ha valami így marad.

QA-mérnök feladatkör és hatókör

Egy QA-mérnök feladata nem az, hogy minden apróságot kiszúrjon, hanem az, hogy a legfontosabb folyamatok ne törjenek el. Fizetés, regisztráció, időpontfoglalás, űrlapküldés, jogosultság. Ilyen részeknél a hiba ára nagy. A minőségbiztosítási mérnök először összerakja, mi számít sikernek, és mi az, amitől a felhasználó elakad.

Szoftvertesztelőként én azt a hibát érzem a legdrágábbnak, amikor valami csak néha romlik el. Ritkán, de pont a rossz pillanatban. Ezeket nem lehet egy gyors próbakörrel elkapni. Kell hozzá türelem és rendszer. Például többféle adat, különböző eszközök, lassabb hálózat, visszalépés, újratöltés. A jó tesztelő szakember ezt mind beépíti, nem csak a szép, egyenes utat járja végig.

Volt egy eset, amikor egy ügyfél azt mondta, a kosár néha kiürül. A fejlesztő nem találta. Kiderült, hogy egy bizonyos böngészőn, egy adott méretű képernyőn a gomb takarásba került, és a kattintás nem oda ment, ahova kellett. Nem nagy hiba, de üzletileg fájt. Ilyenkor érzem, hogy a minőségbiztosítás tényleg pénzt spórol.

QA ellenőrzések a kiadás előtt

Magánmegbízásnál a leggyakoribb kérés az, hogy kiadás előtt legyen egy biztonsági kör. Ilyenkor a QA végigfut a kulcsfolyamatokon, és közben rögzíti a talált hibákat. Nem csak azt írja le, hogy nem jó, hanem azt is, milyen adatokkal, milyen lépések után, és mi lenne az elvárt működés. Ez azért fontos, mert a fejlesztő így gyorsabban javít.

Én a visszatesztelést sem hagynám ki. Sokan ott rontják el, hogy megvan a javítás, és késznek tekintik. De a javítás mellékhatása gyakori. A minőségbiztosítási mérnök ilyenkor visszanézi, hogy tényleg eltűnt a hiba, és közben nem tört el más. Ez a rész unalmasnak tűnik, mégis itt csúsznak el a projektek.

Ha a rendszer több szereplős, például ügyfél és admin felület, akkor a jogosultságokat is érdemes átnézni. A rossz jogosultság nem látványos, de kellemetlen. És ha van külső kapcsolat, például számlázás vagy értesítés, akkor külön ellenőrzés kell. Nem kell túlzásba vinni, de egy célzott próba sokat ér.

Minőségbiztosítási mérnök kiválasztása

A választásnál én nem a legszebb felsorolást nézem, hanem azt, hogyan gondolkodik az ember. A jó minőségbiztosítási mérnök kérdez, pontosít, és nem fél azt mondani, hogy ez így nem tesztelhető. Sok megrendelő hibázik, amikor csak annyit ír, nézd át az oldalt. Ebből lesz a félreértés. Aki jó, az rögtön keretet ad.

A másik szempont a dokumentálás. Nekem az vált be, ha a hibajegyben ott van a lépéssor, a várt eredmény, a kapott eredmény, és egy kép. Ha ez hiányzik, a fejlesztő visszakérdez, és lassul minden. A harmadik szempont az, hogy a tesztelő szakember tudja, mi az, ami valóban fontos. Egy elcsúszott margó néha csak esztétika, de egy rossz számítás már gond.

A Qjob.hu oldalon egyszerűen össze lehet rakni a képet a szakemberről, de én mindig rákérdeznék egy rövid próbafeladatra. Kicsi terjedelem, tiszta elvárás, és látod, milyen a visszajelzés. Miskolc esetén még az is előny, ha szükség esetén személyesen is lehet egyeztetni, de a tesztelés nagy része távolról megy.

QA-mérnök árak és tipikus csomagok

Az árak nagyon szórnak, mert más egy egyszerű bemutatkozó oldal és más egy több lépcsős rendelési folyamat. Én úgy látom, hogy a túl olcsó munka ritkán részletes. 12.000 alatt nehéz elvárni, hogy valaki alaposan végigmenjen, hibajegyet írjon, és még vissza is ellenőrizzen. Persze lehet kivétel, de én nem erre építenék.

Az alábbi példák a munkadíj jellegét mutatják. A tartományban benne van a rendszer állapota is. Ha rendezett, gyorsabb. Ha kusza, lassabb, és több a bizonytalan pont.

Én személy szerint szeretem a fix csomagot, ha a cél egy kiadás biztosítása. Ha folyamatosan változik a rendszer, akkor az óradíj rugalmasabb. És még egy őszinte mondat. A legolcsóbb ajánlat néha azért olcsó, mert nincs benne a visszatesztelés. Aztán a végén úgyis vissza kell hívni valakit.

QA együttműködés menete és átadandók

Ha azt akarod, hogy a teszt gyors legyen, előre add oda, amire szükség van. Próbafelhasználó belépéssel. Rövid leírás, hogy mi a cél, és kinek készül. És legalább egy kis lista a kulcsfolyamatokról. Nem kell hosszú dokumentum. Nekem az elég, ha van pár pont, mit tartasz létfontosságúnak.

Sokan ott csúsznak el, hogy nincs teszt adat. Nincs minta cím, nincs próbarendelés, nincs olyan szám, amit a rendszer elfogad. A tesztelő szakember ilyenkor találgat, és ez idő. A hozzáférések is ilyenek. Ha minden engedélyért külön kör van, a munka fele várakozás. Én mindig azt javaslom, hogy legyen egy elkülönített teszt környezet, ha megoldható. Ha nem, akkor legalább egy óvatos szabály, mit szabad és mit nem.

A visszajelzésnél én a rövid összefoglalót is szeretem. Mi a legnagyobb kockázat. Mi az, ami csak kényelmetlen. Mi az, ami kiadást blokkol. Így nem kell találgatni, mi a sorrend. És igen, néha ki kell mondani, hogy ez most nem engedhető ki. Ez kellemetlen, de még mindig jobb, mint utólag magyarázkodni.

Adatkezelés és visszajelzés minőségbiztosításnál

Magánmegbízásnál gyakran érzékeny adatok is előkerülnek. Ügyféladatok, címek, rendelési számok. Én óvatos vagyok. Inkább kérnék ál adatokat, vagy olyan teszt adatot, ami nem valódi személyhez kötődik. Aki erre legyint, annál én elgondolkodnék. Az adatvédelem nem dísz, hanem felelősség.

A másik gyakori gond a hangnem. A tesztelési lista könnyen tűnhet támadásnak. Pedig nem az. A tesztelő szakember azért írja le a hibát, hogy a rendszer jobb legyen. Nekem az a tapasztalatom, hogy ha a csapat ezt elfogadja, akkor a kiadások gyorsulnak. Ha nem, akkor a hibák el vannak fedve, és később robbannak.

És végül egy személyes zárás. Én jobban szeretem, ha a tesztelés közben is van rövid egyeztetés. Nem hosszú megbeszélés, csak tisztázás, mit láttunk. Miskolc környékén ezt akár gyorsan is meg lehet oldani, de online is működik. A lényeg az, hogy a megrendelő értse, miért fontos egy adott hiba, és ne csak a hibák számát nézze. A jó minőségbiztosítás nem ijesztget, hanem segít dönteni.