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

QA engineer Miskolc

QA engineer akkor kell, amikor van egy készülő rendszered, de nem akarsz találgatni. A cél, hogy valaki végigpróbálja a fontos lépéseket, és megfogja a hibát még azelőtt, hogy ügyfél látja. Miskolc környékén sokan egyedül viszik a fejlesztést, ezért különösen fáj, ha egy apró hiba napokig állítja a munkát.

Sokan azt a hibát követik el, hogy a tesztelést összekeverik a gyors ránézéssel. Pedig a minőségbiztosítási mérnök munkája inkább kitartó ellenőrzés és fegyelmezett jegyzetelés. Lassan halad, de cserébe a végén nem maradnak homályos mondatok, csak pontos lépések és egyértelmű következtetések.

A Qjob.hu felületén olyan önálló szoftvertesztelő szakembert is találsz, aki kifejezetten magánmegbízásokra dolgozik. Neked ez rugalmasabb. Nem kell csapatot szervezned. Elég, ha átadod a hozzáférést és a célfolyamatokat, majd kapsz egy tiszta hibajegyzéket.

Minőségbiztosítási alapok a gyakorlatban

A jó tesztelés ott kezdődik, hogy tiszta a fókusz. Mi a legfontosabb három folyamat. Belépés, vásárlás, foglalás, ajánlatkérés. Én személy szerint mindig ezekkel indulok, mert itt bukik el a legtöbb bevétel. Ha ezek stabilak, a többi már kezelhető.

De van egy visszatérő konfliktus. A megrendelő gyorsan szeretné a listát, a fejlesztő pedig már tegnap javítana. Ilyenkor a tesztmérnök feladata, hogy ne engedje el a részleteket. A tapasztalatom szerint a kapkodás szül még több hibát, mert a javítás beleüt egy másik részbe. És akkor újra kezdődik az egész.

Hasznos, ha van egy rövid leírás arról, hogy mi számít helyes működésnek. Nem kell hosszú dokumentum. Pár mondat elég. Például a jelszó hossza, a visszaigazolás szövege, a kötelező mezők. Ha ez nincs meg, a kézi tesztelő csak tippel, és abból mindig vita lesz.

Funkcionális tesztelés és a kritikus utak

A funkcionális tesztelés egyszerű kérdésre válaszol. A rendszer azt csinálja, amit ígér. Itt jönnek elő az olyan gondok, mint a rossz mezőellenőrzés, a nem működő gomb, a félrement számítás. Ezek gyakran nem látványosak, de a felhasználó azonnal kilép tőlük.

Volt egy eset, amikor egy ügyfél azt mondta, a rendelés néha eltűnik. A fejlesztő nem találta. A teszt során kiderült, hogy bizonyos böngészőben a kosár frissítésnél a rendszer nullázza a mennyiséget, és a felhasználó nem kap figyelmeztetést. A hiba végül rövid javítás volt. De ha nincs következetes végigpróbálás, ott maradt volna hetekig.

Én azt kedvelem, ha a tesztelő szakember nem csak hibát ír, hanem jelzi a kockázatot is. Például ez csak kényelmetlen, vagy ez bevételt visz. Így te is tudsz dönteni, mit javítsatok először.

Regresszió és kiadás előtti ellenőrzés

Minden javítás hozhat új hibát. Ezért fontos a regressziós ellenőrzés, amikor ugyanazokat a lépéseket újra lefuttatjuk. Sok megrendelő ezt kihagyja, mert unalmasnak tűnik. De szerintem ez az a rész, ami a legjobban védi a pénzedet.

Ha kiadás előtt állsz, legyen egy rövid ellenőrző kör. Belépés több fiókkal, hibás adatok próbája, jelszó emlékeztető, fizetés vagy foglalás. A minőségbiztosítási mérnök itt tud igazán hasznos lenni, mert nem a kódot nézi, hanem a valós használatot. És itt derül ki, ha egy apró változás szétverte az egész folyamatot.

Hibajegyek és együttműködés a fejlesztővel

A hibajegy akkor érték, ha reprodukálható. Rövid cím, pontos lépések, várt eredmény, kapott eredmény. És ahol lehet, képernyőkép vagy felvétel. Sokszor látom, hogy valaki csak annyit ír, hogy nem jó. Ezzel nem lehet dolgozni, csak veszekedni.

Én személy szerint szeretem, ha a tesztelő jelzi azt is, hogy milyen eszközön és milyen környezetben futott a teszt. Nem a szakkifejezések miatt, hanem mert így gyorsabb a javítás. A jó QA engineer nem akar okosabbnak tűnni, csak időt spórol mindenkinek.

Fontos a visszateszt is. A javítás után újra meg kell nézni, tényleg eltűnt e a hiba. És azt is, nem történt e mellékhatás. Ha ez kimarad, a hibák visszajárnak. Olyan ez, mint amikor a falat lefestik, de a száradást már nem várják meg.

QA engineer árak Miskolc környékén

Az ár leginkább attól függ, mekkora a rendszer, mennyi a fő folyamat, és mennyire rendezett a feladat. Ha nincs leírás, több idő megy el a tisztázásra. A tapasztalatom szerint 10.000 - 12.000 alatti óradíj ritkán ad stabil minőséget, főleg ha a hibajegyek is rendben vannak. Olcsóbban is találni szoftvertesztelő szakembert, de ott gyakori a felszínes átnézés, és a valódi gond benn marad.

A táblázat tájékoztató. A végösszeg akkor lesz pontos, ha a QA mérnök látja a felületet és a célokat. Én azt javaslom, kezdj egy kisebb körrel, és csak utána bővíts.

Ha valaki azt mondja, hogy mindent megtalál pár óra alatt, én óvatos vagyok. A jó munka nem a hibák számáról szól, hanem arról, hogy mennyire használható a leírás. És hogy a következő kiadásnál kevesebb legyen a meglepetés.

QA engineer kiválasztása

Választásnál én nem az ígéreteket nézem, hanem a mintát. Kérj egy rövid példát hibajegyre. Ha a leírás tiszta, jó eséllyel a munka is az lesz. Nézd meg, vállal e visszatesztet. Ha nem, az nálam piros jelzés.

Érdemes rákérdezni, hogyan kezeli a hozzáférést és az adatokat. Legyen külön belépés, és legyen világos, mit ment le. Sok ügyfél itt követ el hibát, mindent elküld minden csatornán, aztán csodálkozik. Én személy szerint a minimális hozzáférést preferálom, ami még elég a teszthez.

És legyen határ. Ha minden egyszerre fontos, a munka szétfolyik. Kijelölsz három célfolyamatot, és abban legyen vége. Utána jöhet a következő kör. Ez Miskolc környékén is működik, mert a kisebb projekteknél a gyors lezárás ad lendületet. A végén pedig nem marad benned az érzés, hogy fizettél valamiért, ami csak félkész.