Manuális szoftvertesztelés: mit vizsgálok, kinek van rá szüksége, és miért érdemes szakemberre bízni?

Egy weboldal, webáruház vagy üzleti alkalmazás fejlesztése során könnyű abból kiindulni, hogy ha egy funkció elkészült és a fejlesztői környezetben megfelelően működik, akkor a rendszer készen áll a használatra. A gyakorlatban azonban a valódi felhasználók ritkán ugyanúgy használják a szoftvert, ahogyan azt a fejlesztés során elképzelték.
Más sorrendben hajtják végre a lépéseket, hiányos vagy hibás adatokat adnak meg, visszalépnek egy folyamat közben, több alkalommal kattintanak ugyanarra a gombra, mobiltelefonról használják a rendszert, vagy egyszerűen olyan helyzetet teremtenek, amelyre a fejlesztés során senki nem gondolt.

A manuális szoftvertesztelés egyik legfontosabb feladata éppen ezeknek a helyzeteknek a feltárása. A tesztelés során nem kizárólag azt vizsgálom, hogy egy adott funkció technikailag működik-e, hanem azt is, hogy a teljes folyamat megfelel-e az üzleti elvárásoknak, érthető-e a felhasználó számára, megfelelően kezeli-e a hibás helyzeteket, illetve egy módosítás nem okozott-e problémát a rendszer egy másik részén.

Mit jelent a manuális szoftvertesztelés?

A manuális tesztelés során a rendszert valódi felhasználói folyamatokon keresztül vizsgálom, előre meghatározott tesztesetek, üzleti követelmények és tapasztalati alapú ellenőrzések segítségével. Ez jóval többet jelent annál, mint hogy valaki végigkattintja az alkalmazást, és megnézi, látszólag minden működik-e.

Egy tesztelőnek folyamatosan azt kell vizsgálnia, hogy az adott funkció milyen körülmények között működik megfelelően, hogyan viselkedik váratlan bemenet esetén, milyen visszajelzést kap a felhasználó, illetve mi történik akkor, ha a folyamat nem az ideális útvonalon halad.

Egy kapcsolatfelvételi űrlap esetében például önmagában nem elegendő azt ellenőrizni, hogy az űrlap elküldhető-e. Vizsgálni kell azt is, hogyan kezeli a rendszer a hiányzó kötelező mezőket, elfogad-e hibás e-mail-címet, megfelelő hibaüzenetet jelenít-e meg, megmaradnak-e a már kitöltött adatok egy sikertelen beküldés után, illetve valóban megérkezik-e az elküldött információ a megfelelő helyre.

Ugyanez igaz egy webáruház vagy összetettebb üzleti alkalmazás esetében is. Egy vásárlási folyamat nem attól működik megfelelően, hogy egy terméket sikeresen hozzá lehet adni a kosárhoz. A teljes folyamatot kell vizsgálni a termék kiválasztásától egészen a rendelés létrejöttéig, beleértve az árképzést, kedvezményeket, szállítási módokat, fizetési folyamatokat, visszaigazolásokat és a hibás vagy megszakított tranzakciók kezelését is.

Mit vizsgálok egy manuális tesztelés során?

A tesztelés terjedelme mindig az adott rendszer működésétől és üzleti céljától függ. Egy egyszerű bemutatkozó weboldal esetében más kockázatokra kell koncentrálni, mint egy több felhasználói jogosultsággal, fizetési folyamattal vagy külső integrációkkal rendelkező webalkalmazásnál.

A funkcionális tesztelés során azt vizsgálom, hogy az egyes funkciók megfelelnek-e az előzetesen meghatározott követelményeknek. Ide tartozhat például a regisztráció, a bejelentkezés, a jelszó-visszaállítás, az adatbevitel, a keresés, a szűrés, az űrlapok működése, a kosár- és rendelési folyamat, valamint az egyes felhasználói jogosultságok ellenőrzése.

Ezeknél nem kizárólag az úgynevezett happy path, vagyis az ideális felhasználói folyamat érdekes. Legalább ilyen fontosak a negatív tesztek és a szélsőértékek vizsgálatai. Egy megfelelően működő rendszernek nemcsak a helyes bemeneteket kell kezelnie, hanem kontrollált és érthető módon kell reagálnia a hibás adatokra és a váratlan felhasználói műveletekre is.

A felhasználói felület ellenőrzése szintén a manuális tesztelés fontos része. Ilyenkor azt vizsgálom, hogy a tartalom megfelelően jelenik-e meg, követhető-e a navigáció, logikusak-e a folyamatok, jól láthatók-e a fontos funkciók és egyértelműek-e a rendszer visszajelzései. Egy technikailag működő funkció is komoly használhatósági problémát okozhat, ha a felhasználó nem érti, mit kell tennie, vagy nem kap megfelelő visszajelzést arról, hogy egy művelet sikeresen megtörtént.

Külön figyelmet fordítok a reszponzív működésre és a különböző böngészők közötti eltérésekre is. Egy webes rendszer viselkedése jelentősen eltérhet asztali és mobilkörnyezetben, és az sem ritka, hogy egy funkció Chrome alatt problémamentesen működik, miközben egy másik böngészőben megjelenési vagy működési hiba jelentkezik. A különböző képernyőméretek, navigációs megoldások, űrlapok és interaktív elemek ezért külön ellenőrzést igényelnek.

Miért fontos a regressziós tesztelés?

Minden módosítás hatással lehet a rendszer más részeire is. Egy új funkció bevezetése, egy meglévő modul módosítása vagy akár egy egyszerűnek tűnő hibajavítás is okozhat nem várt mellékhatást.

A regressziós tesztelés célja annak ellenőrzése, hogy egy változtatás után a korábban megfelelően működő funkciók továbbra is helyesen működnek-e. Ez különösen fontos folyamatosan fejlesztett rendszerek esetében, ahol rendszeresen kerülnek ki új verziók vagy funkciók.

Egy webáruházban például egy kedvezménykezelési funkció módosítása hatással lehet a kosár végösszegére, a szállítási díjra vagy akár a fizetési folyamatra is. Emiatt a javítás vagy fejlesztés után nem elegendő kizárólag az új funkciót ellenőrizni. A kapcsolódó üzleti folyamatokat is újra kell tesztelni.

Kiknek lehet szükségük manuális szoftvertesztelésre?

Manuális QA-ra nem kizárólag nagy szoftverfejlesztő vállalatoknak van szükségük. Már kisebb fejlesztőcsapatok, digitális ügynökségek, startupok vagy webáruházak esetében is jelentős értéket teremthet egy független tesztelési folyamat.

Fejlesztőcsapatok esetében különösen fontos lehet a külső nézőpont. Egy fejlesztő természetesen ellenőrzi a saját munkáját, ugyanakkor pontosan ismeri a rendszer működését és az általa elképzelt felhasználási módot. Emiatt sokszor ösztönösen azokon az útvonalakon halad végig, amelyekről tudja, hogy működniük kell. Egy független tesztelő ezzel szemben kevésbé kötődik az implementációhoz, ezért más szemmel vizsgálja ugyanazt a funkciót.

Startupok és gyorsan fejlődő termékek esetében a gyakori változtatások miatt válik különösen fontossá a QA. Minél több új funkció kerül a rendszerbe, annál nagyobb az esély arra, hogy egy fejlesztés nem várt hatással lesz valamelyik korábbi folyamatra.

Webáruházaknál pedig a tesztelés üzleti jelentősége még közvetlenebb. Ha hibás a kosár, nem működik megfelelően egy kupon, elakad a fizetés vagy problémás a rendelés leadása, az nem egyszerű technikai kellemetlenség. Közvetlenül elveszített bevételt jelenthet.

Hogyan dolgozom egy tesztelési projekt során?:

A tesztelést mindig a rendszer és az üzleti célok megismerésével kezdem. Fontos megérteni, hogy kik használják a szoftvert, melyek a kritikus folyamatok, milyen funkciók hordozzák a legnagyobb üzleti kockázatot, illetve milyen környezetben használják majd a rendszert.

Ez alapján határozható meg, hogy milyen tesztelési módszerekre van szükség, mely funkciók igényelnek részletes teszteseteket, hol célszerű felfedező tesztelést alkalmazni, és mely területeket kell kiemelten kezelni regressziós ellenőrzések során.

A megtalált hibákat úgy dokumentálom, hogy azok a fejlesztő számára reprodukálhatók és egyértelműek legyenek. Egy jó hibajegy nem egyszerűen azt tartalmazza, hogy valami „nem működik”, hanem pontosan leírja az előfeltételeket, a hiba reprodukálásához szükséges lépéseket, az elvárt és tényleges eredményt, a használt környezetet, illetve szükség esetén képernyőképpel vagy videóval is kiegészíthető.

Ennek azért van jelentősége, mert a rosszul dokumentált hibák rengeteg felesleges kommunikációt generálnak. Ha a fejlesztőnek először ki kell derítenie, pontosan milyen körülmények között jelentkezett a probléma, az időt vesz el a tényleges javítástól.

A javítás után az érintett hibát újratesztelem, majd szükség esetén a kapcsolódó funkciókat is ellenőrzöm annak érdekében, hogy a módosítás ne okozzon regressziót.

Mikor érdemes tesztelőt bevonni?

Sok projektben a tesztelés csak közvetlenül az élesítés előtt kerül előtérbe, amikor már kevés idő maradt a feltárt problémák javítására. Ennél hatékonyabb megközelítés, ha a minőségbiztosítás már a fejlesztési folyamat korábbi szakaszaiban megjelenik.

Minél korábban derül ki egy félreérthető követelmény, hibás üzleti logika vagy rosszul definiált felhasználói folyamat, annál kisebb költséggel lehet korrigálni. Egy tervezési szakaszban észrevett probléma általában lényegesen egyszerűbben javítható, mint ugyanaz a hiba akkor, amikor már több funkció épül rá és a rendszer éles használatban van.

A manuális szoftvertesztelés ezért nem egyszerűen az elkészült rendszer ellenőrzéséről szól. A megfelelő időben alkalmazva a fejlesztési folyamat részeként segít csökkenteni a kockázatokat, javítani a felhasználói élményt és biztosítani, hogy a rendszer üzleti szempontból is megfelelően működjön.

Összefoglalva

A minőségbiztosítás célja sokkal inkább az, hogy a problémákat kontrollált környezetben, lehetőleg még azelőtt azonosítsuk, hogy azok a felhasználókat vagy az üzleti működést érintenék.

Egy kritikus hibát mindig olcsóbb és egyszerűbb a tesztelési folyamat során megtalálni, mint akkor, amikor már éles környezetben akad el miatta egy vásárló, ügyfél vagy belső munkafolyamat.

Ha weboldal, webáruház vagy webalkalmazás fejlesztésén dolgozol, élesítés előtt állsz, vagy folyamatos QA támogatásra van szükséged, az Elevión keresztül manuális szoftvertesztelésben is tudok segíteni.

A tesztelési folyamatot mindig az adott rendszerhez igazítom, legyen szó funkcionális tesztelésről, regressziós ellenőrzésről, felhasználói folyamatok vizsgálatáról vagy egy teljes rendszer élesítés előtti átvizsgálásáról.

Ha szeretnéd, hogy még az ügyfeleid előtt megtaláljuk a kritikus hibákat, vedd fel velem a kapcsolatot, és nézzük meg, milyen tesztelési megközelítés illik a rendszeredhez.