Szoftvertesztelők Kaposváron: Vélemények és kedvező árak

Szoftvertesztelő Kaposváron magánügyfeleknek

Szoftvertesztelő akkor kell, amikor egy weboldal, alkalmazás vagy belső rendszer már működik, de nem biztos, hogy hibamentesen használható. Kaposváron sok magánügyfél és kisebb vállalkozó csak a fejlesztés végén gondol a tesztelésre. Ez gyakori hiba. A tesztelő szakember nem azért nézi át a rendszert, hogy akadékoskodjon. Azért dolgozik, hogy a felhasználó ne a hibákkal találkozzon először. Ez különösen fontos webáruháznál, időpontfoglaló oldalon, űrlapoknál, fizetési folyamatnál és ügyféladatokat kezelő felületeknél.

A szoftvertesztelés magánmegbízásban általában rövidebb és célzottabb, mint egy nagy céges projektben. Lehet néhány óra kézi ellenőrzés, egy hibajegy lista készítése, mobilos nézetek átnézése vagy egy frissítés utáni gyors próba. A Qjob.hu oldalán különböző független szakemberek között lehet keresni, ezért érdemes már az első üzenetben leírni, milyen rendszer készült, ki fejlesztette, milyen eszközökön kell működnie, és van e határidő.

Kézi tesztelés kisebb rendszerekhez

A kézi tesztelés sok esetben elég jó kezdés. A tesztelő végigmegy a fő folyamatokon, kipróbálja a gombokat, űrlapokat, belépést, keresést, rendelést vagy foglalást. Nem csak azt nézi, hogy valami elindul e. Azt is figyeli, hogy érthető e, gyors e, logikus e a működés. Ez magánügyfeleknél különösen hasznos, mert egy kisebb oldalnál sokszor nincs külön projektvezető vagy minőségbiztosítási csapat.

Személy szerint én a kézi ellenőrzéssel kezdeném, ha új oldalról vagy frissen elkészült alkalmazásról van szó. Nem azért, mert ez mindenre elég. Inkább azért, mert gyorsan kiderülnek a zavaró hibák. Rossz hibaüzenet. Nem működő link. Telefonon széteső menü. Elküldött űrlap, amelyről nem érkezik visszajelzés. Ezek apróságnak tűnnek, mégis ügyfeleket veszíthet miattuk az oldal.

Volt eset, amikor egy ügyfél csak azt kérte, hogy valaki nézze meg az új bemutatkozó oldalát. A fejlesztő szerint minden készen volt. A tesztelés során kiderült, hogy a kapcsolatfelvételi űrlap működött asztali gépen, de telefonon a küldés gomb részben takarásban volt. A hiba nem volt látványos, mégis pont a legfontosabb műveletet akadályozta. Egy rövid ellenőrzés megspórolt több elveszett megkeresést.

Árak szoftvertesztelésre

Az ár függ a rendszer méretétől, a tesztelendő eszközök számától, a jelentés részletességétől és attól, hogy kell e újratesztelés javítás után. Egy szoftvertesztelő óradíja gyakran alacsonyabb, mint egy fejlesztőé, de a túl olcsó ajánlat itt is kockázatos. Olcsóbban 8.000 forintnál óránként ritkán lesz gondos munka, főleg ha részletes hibaleírás, képernyőkép és ellenőrzési lista is kell. Szerintem a jó tesztelés nem hosszú szöveg, hanem pontos megfigyelés.

A táblázat csak irányadó. Egy webáruház tesztje például lehet egyszerű is, ha kevés termék és egy fizetési mód van. De bonyolultabb lesz, ha kuponok, szállítási módok, felhasználói fiókok és több nyelv is szerepel. A minőségellenőr akkor tud korrekt árat adni, ha látja a feladat határait. Sok félreértés abból indul, hogy az ügyfél teljes ellenőrzést kér, de valójában csak a fő folyamatokat szeretné megnézetni.

Tesztelő szakember kiválasztása

Tesztelő szakember választásánál nem elég azt nézni, hogy ki mennyit kér óránként. Fontosabb, hogyan írja le a hibákat. Egy jó szoftverellenőr nem csak annyit mond, hogy rossz. Leírja, hol találta a hibát, milyen lépések után jelent meg, milyen eszközön próbálta, és mi lenne az elvárt működés. Ez segít a fejlesztőnek is, az ügyfélnek is.

Sokan hibáznak, amikor olyan embert választanak, aki csak általános véleményt ad. Szép az oldal. Működik nagyjából. Ez kevés. A jó munka végén marad egy lista. Nem feltétlenül hosszú, de használható. Én azt javaslom, kérdezzen rá, hogy a hibákhoz készül e képernyőkép, rövid leírás és fontossági besorolás. Nem kell túl bonyolítani. De egy hiba súlya nem mindegy. Más gond egy elírás, és más az, ha nem lehet rendelést leadni.

Magánügyfeleknél az is számít, hogy a tesztelő érthetően beszéljen. Nem mindenki akar szakmai rövidítéseket hallgatni. Egy jó informatikus el tudja mondani egyszerűen, mi akadályozza a használatot, mit kell előbb javítani, és mi várhat. Ez bizalmi kérdés is, mert a tesztelés gyakran belépési adatokkal vagy próbaügyfél fiókkal jár.

Kaposvári és környékbeli megbízások

Kaposvár területén a szoftvertesztelés sokszor távolról is elvégezhető. Ez előny, mert nem kell minden apró hibához személyes találkozó. Egy weboldal, időpontfoglaló rendszer vagy egyszerű alkalmazás tesztje általában megoldható online hozzáféréssel. Helyszíni egyeztetés inkább akkor hasznos, ha több eszközön kell bemutatni a hibát, vagy az ügyfél nem tudja pontosan megfogalmazni a problémát.

A belváros, Donner, Cseri, Toponár és Kaposszentjakab környékén könnyebb lehet személyes időpontot találni. A közeli települések, például Kaposmérő, Taszár, Juta vagy Sántos esetén már érdemes rákérdezni az utazási díjra. Kaposváron sok kisebb vállalkozó működtet saját oldalt, foglalási felületet vagy online űrlapot. Nekik különösen hasznos lehet egy rövid, de célzott ellenőrzés indulás előtt.

Mit érdemes átadni tesztelés előtt

A szoftvertesztelés gyorsabb, ha az ügyfél előre összegyűjti a fontos adatokat. Kell a webcím, a próba belépés, a tesztelendő funkciók listája, a használt eszközök köre és az ismert hibák rövid leírása. Nem kell hosszú dokumentum. Elég egy világos lista. Ha van fejlesztő, jó megadni, milyen formában kéri a hibákat. Táblázatban, képernyőképpel, feladatkezelőben vagy egyszerű üzenetben.

A jelszavakat nem érdemes nyílt üzenetben küldeni. Jobb külön próba fiókot készíteni, amely nem tartalmaz valódi ügyféladatot. Ez apróságnak tűnik, de sok későbbi kellemetlenséget megelőz. Po mojemu tapasztalat szerint azok a projektek mennek nyugodtabban, ahol már az elején külön tesztadatok vannak. Például próba név, próba e mail, próba rendelés, próba kupon. Így a hibakeresés nem keveredik valódi ügyekkel.

Ha a tesztelés fizetési folyamatot érint, különösen óvatosan kell eljárni. Nem szerencsés valódi bankkártyás fizetéssel próbálkozni, ha van teszt mód. Ha nincs, akkor előre tisztázni kell, milyen összeggel és hogyan történik az ellenőrzés. Ilyen helyzetben a tesztelő nem dönthet egyedül. Az ügyfél jóváhagyása kell.

Gyakori hibák weboldalakon és appokban

A leggyakoribb hibák nem mindig mély technikai problémák. Sokszor egyszerű dolgok. Nem olvasható gomb telefonon. Hibás visszaigazoló szöveg. Üres oldal lassú betöltésnél. Rosszul működő szűrő. Olyan mező, amely nem jelzi, ha kötelező. Ezek bosszantják a felhasználót, és csökkentik a bizalmat. Egy szoftvertesztelő pont ezeket keresi célzottan.

Gyakori probléma az is, hogy a fejlesztő saját gépén minden működik, de más böngészőben már nem. Vagy asztali nézetben jó az oldal, telefonon viszont kényelmetlen. Ezért kell több helyzetben próbálni. Nem feltétlenül tíz készüléken. De legalább a legfontosabbakon. Szerintem egy kis projektben is legyen külön mobilos próba, mert sok ügyfél már telefonról érkezik.

Volt olyan munka, ahol a webáruház kosara csak akkor hibázott, ha a vevő előbb törölt egy terméket, majd kupont adott hozzá. Ezt a fejlesztő nem vette észre, mert mindig a legegyszerűbb útvonalat próbálta. A tesztelő viszont más sorrendben is végigment a folyamaton. Ez a különbség. A felhasználó nem mindig úgy viselkedik, ahogy a készítő elképzeli.

Reális elvárások és javítás utáni ellenőrzés

A szoftverellenőrzés nem azt jelenti, hogy a teszt után soha többé nem lesz hiba. Ilyen ígéretet nem érdemes komolyan venni. A cél az, hogy a fontos hibák előbb derüljenek ki, ne az éles használat közben. A tesztelés csökkenti a kockázatot, de nem szünteti meg teljesen. Ezt jó előre elfogadni.

A javítás utáni újratesztelés legalább olyan fontos, mint az első kör. Sok ügyfél ezen spórolna. Én ezt csak óvatosan tenném. Előfordul, hogy egy hiba javítása közben másik rész romlik el. Nem rossz szándékból, hanem mert a rendszerek összefüggenek. Egy rövid ellenőrzés ilyenkor sokat ér.

A minőségbiztosítás akkor hasznos magánügyfeleknél, ha nem válik túl nehézkessé. Nem kell nagy céges folyamat minden kis oldalhoz. Kell viszont tiszta feladatlista, reális határidő, érthető hibaleírás és utóellenőrzés. Itt a jó eredmény nem a hibátlan ígéret. Hanem az, hogy az ügyfél tudja, mi működik, mi kockázatos, és mit kell kijavítani a következő lépésben.