QA-tesztelők Miskolcon: Vélemények és kedvező árak

QA tesztelő keresése Miskolc területén

Ha QA tesztelő kell, a cél egyszerű: a programod működjön úgy, ahogy a felhasználó várja, és ne az éles használat közben derüljenek ki a hibák. Miskolc környékén sokan későn kérnek szoftvertesztelő segítséget, amikor már panaszos üzenetek jönnek, és kapkodás lesz. Én inkább előbb nézetem át a rendszert, még akkor is, ha csak egy kisebb weboldalról, egy mobilos felületről vagy egy belső űrlapról van szó. A tesztelés ilyenkor gyorsabb, olcsóbb, és kevesebb kellemetlenséget okoz.

Sokan azt hiszik, a tesztelés annyi, hogy valaki végigkattint pár oldalt. De a jó manuális tesztelő nem csak kattint. Megpróbálja elrontani a folyamatot. Rossz adatot ír be, kihagy lépéseket, újratölt, visszalép, eltér a megszokott úttól. És közben feljegyzi, mit lát, mikor romlik el, és mi lehet a kiváltó ok. A végén olyan hibajegyet ad, amit a fejlesztő is megért, nem csak egy mondatot arról, hogy nem jó.

A QA tesztelés tipikus feladatai

Egy minőségbiztosítási szakember általában először rendet rak a fejében. Mit kell tesztelni, mi számít késznek, mi a legnagyobb kockázat. Ha a rendszer pénzt kezel, ott nem lehet lazázni. Ha időpontfoglalás van benne, akkor a naptár, az értesítések és a lemondás a kényes pont. Ha belépés van, akkor a jogosultság és a jelszó visszaállítás kerül előre. Nekem az vált be, hogy a legfontosabb folyamatokat végigveszem, és csak utána megyek a ritkább esetekre.

A szoftvertesztelő munkája lehet funkcionális ellenőrzés, integrációk próbája, visszaellenőrzés frissítés után, és egyszerű teljesítmény alapvizsgálat is. Automatizálásról is lehet szó, de magánmegbízásoknál gyakran elég az, ha a tesztelő szakember kézzel átnézi a kritikus részeket, és ad egy tiszta listát. Később, ha a termék nő, jöhet a tesztautomatizáló, de sokszor nem ott éri meg kezdeni.

Volt olyan eset, amikor a megrendelő azt mondta, minden rendben, csak néha nem érkezik meg az e mail. Kiderült, hogy egyetlen rossz karakter miatt bukott el az értesítés, és csak bizonyos címeknél. A fejlesztő hetekig nem látta, mert a saját teszt címe mindig működött. Egy óra célzott tesztelés után megvolt a hiba. Az ilyen történetek miatt tartom fontosnak, hogy ne csak a saját környezetben legyen kipróbálva a rendszer.

Gyakori hibák, amiket az ügyfelek elkövetnek

Sokan hibáznak, amikor a tesztelést a legvégére hagyják. A gond nem csak az, hogy később drágább, hanem az is, hogy a javítások újabb hibákat hozhatnak. És akkor indul a kör. Másik tipikus hiba, amikor a megrendelő csak annyit mond, nézd át. Ebből nehéz jó munkát csinálni. Én azt szeretem, ha van legalább egy rövid leírás, mi a cél, kik használják, és mi az, ami most fáj.

Gyakori probléma az is, hogy nincs teszt adathalmaz. Nincs minta felhasználó, nincs próbamegrendelés, nincs próbaszámla. Ilyenkor a QA tesztelő vagy a fejlesztőtől kér adatot, vagy improvizál, és ez lassít. A harmadik hiba a hozzáférések. Ha mindenhez külön engedély kell, a tesztelő fél napot vár, mire beléphet. Ezt érdemes előre rendezni.

És van még egy dolog. Sok ügyfél a hibát személyes kritikának veszi. Pedig a tesztelő szakember nem ellened dolgozik. A cél az, hogy ne a felhasználó találja meg a hibát először. Nekem az a tapasztalatom, hogy ahol ezt megértik, ott a fejlesztés nyugodtabb, és a végén jobb a termék.

Árak és díjazás szoftvertesztelésnél

Az ár mindig attól függ, mennyire összetett a rendszer, hány képernyő van, mennyi integráció, és mennyire sürgős. Miskolc esetén is ugyanaz a logika, mint máshol, csak a személyes egyeztetés könnyebb. Én reálisnak tartom, ha először egy rövid felmérés történik, utána egy fix csomag vagy óradíjas munka. De a túl olcsó ajánlatot én óvatosan kezelem. 10.000 alatt ritkán lesz minőségi, részletes hibajegy, főleg ha dokumentációt is vársz.

Az alábbi árak tipikusak lehetnek, ha magánmegbízásról beszélünk, és nem egy teljes csapatról. A tartomány azért fontos, mert ugyanaz a feladat lehet tiszta és lehet kusza. Nekem az a tapasztalatom, hogy a legnagyobb spórolás az, ha a tesztelő gyorsan megtalálja a valódi okokat, nem csak tüneteket ír le.

Ha csak egy gyors kontroll kell, a csomagok jól működnek. Ha folyamatosan változik a rendszer, az óradíj a tisztább. És még egy személyes megjegyzés. Én jobban szeretem, ha előre megállapodunk abban, mi a kész állapot. Különben a munka elnyúlik, és egyik fél sem elégedett.

Megfelelő tesztelő szakember kiválasztása

A kiválasztásnál én három dolgot nézek. Először azt, hogyan kérdez. Aki jó, az pontosítja a célokat, és nem fél azt mondani, hogy ez így kevés információ. Másodszor azt, hogyan dokumentál. Egy képernyőkép, a pontos lépések, és az elvárt eredmény sokat ér. Harmadszor a gondolkodásmódot. A jó minőségbiztosítási szakember nem csak hibát gyűjt. Megpróbálja megérteni, miért történik, és hogyan lehet megelőzni.

Sokan elkövetik azt a hibát, hogy csak az árat nézik. Pedig egy tapasztalt QA tesztelő hamarabb ad használható listát. A végén olcsóbb. Ha nagyon olcsó ajánlat jön, én rákérdeznék, mit kapsz érte. Lesz e részletes leírás. Lesz e újrateszt javítás után. Lesz e rövid összefoglaló a kockázatokról. Ezek nélkül a lista csak egy halom panasz, amivel a fejlesztő nem tud mit kezdeni.

Ezen a felületen a Qjob.hu csak egyszer szerepel név szerint, mert a lényeg a szakember. Itt érdemes olyan profilt keresni, ahol van többféle munka, és látszik, hogy a szoftvertesztelő valódi projekteken dolgozott. Miskolc esetén az is előny, ha szükség esetén személyesen is tudtok egyeztetni, de a munka többnyire távolról is megy.

Mit adj át a tesztelés előtt

Ha gyors és tiszta munkát akarsz, adj át pár dolgot előre. Belépési adatok próbafelhasználóval. Rövid leírás, mire való a rendszer. Ha van, akkor a legfontosabb folyamatok listája. Én szeretem, ha kapsz egy mondatot minden kulcsoldalról, mit kellene tudnia. És kell teszt adat. Példa név, cím, rendelési szám, bármi, amivel életszerűen lehet próbálni.

Ha vannak régi hibák, amik visszajárnak, írd le. A tesztelő szakember így célzottan keresi. És mondd el azt is, mi a tűréshatár. Van, ahol egy apró elcsúszás a felületen belefér. Van, ahol nem. Nekem az a tapasztalatom, hogy ha ez nincs kimondva, később vitát okoz. A tesztelés végén pedig legyen idő a javításokra és az újrapróbálásra. Sok projekt ott csúszik el, hogy hibák megvannak, de nincs kapacitás visszanézni, tényleg javult e.

És még valami, amit ritkán mondanak ki. Néha a tesztelés nem csak hibát talál. Kiderül, hogy a folyamat túl bonyolult, vagy a felhasználó nem érti a lépéseket. Ilyenkor a szoftvertesztelő jelzi, és te döntesz, változtatsz e. Én személy szerint örülök ezeknek a jelzéseknek, mert nem csak javítunk, hanem egyszerűsítünk is. És ez sokszor többet hoz, mint egy új funkció.