Manuális tesztelők Kaposváron: Vélemények és kedvező árak

Manuális tesztelő weboldalhoz, alkalmazáshoz és belső rendszerhez

A Manuális tesztelő akkor segít igazán, amikor nem elég ránézni egy oldalra, és nem elég megkérni a fejlesztőt, hogy próbálja ki, amit elkészített. A tesztelő felhasználói szemmel járja végig a folyamatokat, közben hibát, félreérthető működést, hiányzó visszajelzést, rossz jogosultságot, törött űrlapot, fizetési akadást vagy mobilos használhatósági gondot keres. Ez nem ugyanaz, mint a véleményezés. A jó tesztelés végén dönthető hibajegyek, reprodukálható lépések és rangsorolt kockázatok maradnak, nem csak egy lista arról, hogy valami furcsa.

Magánmegrendelőknél és kisebb cégeknél gyakori, hogy a tesztelés csak az utolsó napra marad. Ilyenkor a tesztelő már nem a minőséget építi, hanem a kárt próbálja csökkenteni. Sokkal jobb, ha legalább a fő felhasználói utak, a regisztráció, a kosár, az ajánlatkérés, a feltöltés, a belépés, az admin szerepkörök és az értesítések még élesítés előtt kapnak egy külön ellenőrzési kört.

Manuális tesztelő feladatok élesítés előtt

A manuális tesztelés értelme nem az, hogy valaki véletlenszerűen kattintgat. A munka akkor hasznos, ha előre tisztázott, mit kell védeni. Egy egyszerű bemutatkozó weboldalnál a kapcsolatfelvételi űrlap, a mobilnézet, a linkek és a sebességérzet lehet fontos. Egy webáruháznál már kosár, kupon, fizetés, számlázási adatok, készletállapot, e-mail értesítés és visszalépési helyzetek is belépnek. Egy belső rendszerben a jogosultság, a keresés, az export, a mentés és az adatvesztés kockázata nagyobb súlyt kap.

A tesztelőnek nem kell minden hibát megjavítania. Az a fejlesztő dolga. Viszont a hibát úgy kell leírnia, hogy a fejlesztő ne találgasson. Egy használható hibajegy tartalmazza a környezetet, a lépéseket, a várt működést, a tényleges működést, képernyőképet vagy rövid videót, valamint azt, hogy a hiba mennyire akadályozza a felhasználót. Ez a különbség a hasznos QA munka és a véleménylista között.

Manuális tesztelő árak

Az ár leginkább nem attól függ, hány oldalból áll a rendszer, hanem attól, hány állapotot és kivételt kell végigpróbálni. Egy három oldalas ajánlatkérő oldal olcsóbb lehet, mint egyetlen bonyolult kalkulátor, ahol sok bemeneti adat, hibakezelés és üzleti szabály van. A tesztelési időt növeli a rossz dokumentáció, a hiányzó tesztadat, a sok szerepkör, a több böngésző és a mobilos ellenőrzés.

Feladat típusa	Jellemző tartalom	Ár Ft
Landing oldal tesztelése	Űrlap, linkek, mobilnézet, alapvető hibák	18.000 - 35.000
Kisebb céges weboldal	Fő oldalak, kapcsolatfelvétel, több eszköz	35.000 - 70.000
Webáruház alap ellenőrzés	Kosár, rendelés, kupon, értesítések	65.000 - 140.000
Mobilalkalmazás próbakör	Telepítés, fő funkciók, készülékfüggő hibák	45.000 - 110.000
SaaS vagy ügyfélkapu teszt	Belépés, jogosultság, munkafolyamatok	90.000 - 220.000
Hibajegyek újratesztelése	Javítások ellenőrzése, regressziós kockázatok	25.000 - 80.000
Tesztforgatókönyv készítése	Lépések, elvárt eredmények, lefedettség	40.000 - 120.000
Sürgős élesítés előtti kör	Prioritásos ellenőrzés szűk határidővel	80.000 - 260.000

A túl alacsony ár akkor kockázatos, ha nincs benne hibajegyírás, újratesztelés vagy eszköz szerinti bontás. Olcsó első kör lehet hasznos, ha csak gyors kockázatfelmérés kell. Éles fizetési vagy adatkezelési folyamatnál viszont a felületes ellenőrzés drágább lehet, mint maga a tesztelés.

Manuális tesztelő választása

Jó jel, ha a szakember már az ajánlat előtt kérdez. Milyen rendszer készül, milyen állapotban van, van-e tesztelhető verzió, melyik böngésző és készülék fontos, van-e admin felület, milyen szerepkörökkel kell belépni, kell-e fizetést próbálni, van-e próbaadat. Aki ezek nélkül azonnal fix árat mond egy összetett rendszerre, valószínűleg csak felületes kattintgatásra számol.

Érdemes mintahibajegyet kérni. Nem titkos projektből, hanem anonimizált vagy saját példából. A minőség hamar látszik abból, hogy a hiba leírása reprodukálható-e. A gyenge tesztelő sokszor ilyen mondatokat ír, nem működik, rossz a gomb, fura a mobilnézet. Az erős tesztelő megadja, hogy melyik lépés után, milyen adattal, milyen böngészőben, milyen eredmény helyett mi történt.

A Qjob.hu felületén nem csak az árat érdemes összehasonlítani, hanem azt is, hogy a jelentkező vállal-e átadási formátumot. Egy táblázat, képernyőkép mappa vagy projektkezelőben rögzített hibajegy sokkal használhatóbb, mint egy hosszú üzenetfolyam, amelyből később senki sem tudja, mi javult és mi maradt nyitva.

Manuális tesztelő Kaposvár környéki projektekhez

Kaposvár esetén a manuális tesztelés többnyire nem helyszíni munka. A tesztelhető link, belépési adatok, próba felhasználók, rövid működési leírás és prioritáslista fontosabb, mint a személyes találkozó. Helyi vállalkozásnál viszont előny, ha a tesztelő érti, hogy egy ajánlatkérő, időpontfoglaló vagy kiszállítási folyamatnál milyen hibák okoznak azonnal elveszett érdeklődőt.

Ha a szolgáltatás Kaposvár ügyfeleinek szól, külön figyelni kell a kapcsolati adatokra, nyitvatartásra, űrlapmezőkre, térképes linkekre, visszaigazoló e-mailekre és mobilos hívásindításra. Ezek apró részleteknek tűnnek, de egy hibás telefonszám, rosszul működő ajánlatkérő vagy elcsúszó mobil gomb közvetlenül rendelésvesztést okozhat.

Manuális tesztelés hibái és gyenge brief

Sokan ott hibáznak, hogy csak annyit írnak, nézd át az oldalt. Ez túl tág kérés. A tesztelő ilyenkor nem tudja, hogy a dizájn, a funkció, a szöveg, a rendelési út vagy az admin működés fontosabb. Jobb brief, ha a megrendelő megadja a három legfontosabb felhasználói célt, a kritikus funkciókat, a nem módosítható részeket és azt, milyen hibák lennének üzletileg fájdalmasak.

Gyakori probléma, hogy nincs tesztadat. A tesztelő éles ügyféladatokkal ne dolgozzon, és ne neki kelljen kitalálnia, milyen felhasználóval, milyen termékkel vagy milyen jogosultsággal próbálja ki a rendszert. A próbaadat akkor jó, ha van sikeres, hibás és határeset is. Például üres mező, túl hosszú név, rossz e-mail formátum, lejárt kupon, elfogyott termék vagy nem engedélyezett fájltípus.

Az irreális elvárás is rontja az eredményt. Egyetlen rövid tesztkör nem garantál hibamentes rendszert. Arra jó, hogy a látható és üzletileg fontos hibák jelentős részét felszínre hozza. Komolyabb rendszerhez több kör kell. Első körben feltárás, utána javítás, majd újratesztelés és szűk regressziós ellenőrzés.

Manuális tesztelő határidők

A reális határidő attól függ, mennyire stabil a tesztelhető verzió. Egy kisebb oldal ellenőrzése akár egy munkanap alatt is lezárható, ha minden hozzáférés és próbaadat készen van. Egy több szerepkörös rendszerhez viszont előbb tesztterület, próba felhasználók és döntési sorrend kell. Ha a fejlesztés közben folyamatosan változik a felület, a tesztelő ideje részben újrakezdett ellenőrzésre megy el.

Manuális tesztelő átadása és javítási körök

A jó átadás nem csak hibákból áll. Kell hozzá rövid összegzés arról, mely területek lettek ellenőrizve, mi nem fért bele, milyen környezetben zajlott a teszt, és mely hibák akadályozzák az élesítést. Ez azért fontos, mert a megrendelő gyakran nem tudja megítélni, melyik hiba kozmetikai és melyik veszélyezteti a bevételt vagy az adatbiztonságot.

Normális, ha az első hibajegyek után van pontosító kérdés. Az is normális, ha javítás után néhány új hiba jelenik meg, mert egy módosítás más funkciót érint. Nem normális viszont, ha a tesztelő nem tudja megmondani, mit ellenőrzött, nem rögzíti a környezetet, vagy ugyanazt a hibát több külön néven adja le. Ilyenkor a fejlesztői idő feleslegesen fogy.

Megrendelés előtt érdemes tisztázni, hány javítás utáni ellenőrzés tartozik az árba. Kisebb munkánál egy újratesztelési kör elég lehet. Webáruháznál, alkalmazásnál vagy belső rendszernél jobb külön keretet hagyni rá, mert a minőség nem a hibák megtalálásánál, hanem a javítások ellenőrzésénél dől el.