Amikor a teoretikus tudás találkozik a valósággal – és a valóság rendszerint visszaüt
Ha azt gondolod, hogy a szoftvertesztelés csak arról szól, hogy „kattints ide, kattints oda”, majd írd le, hogy „működik” vagy „nem működik”, akkor valószínűleg még nem találkoztál igazán komplex projektekkel. A valódi tesztelés olyan, mint a detektívmunka – sokszor nem is tudod, mit keresel, amíg rá nem bukkansz.
Az alábbiakban olyan gyakorlati feladatokat mutatunk be, amelyek valós projektekben fordulhatnak elő. Ezek nem a szokásos „teszteld le a bejelentkezést” típusú feladatok, hanem olyanok, amelyeknél gondolkodni kell, stratégiát kell felépíteni, és gyakran kreatívnak kell lenni.
A cikkben szereplő feladatok és esetek NEM fikciók, és a valós projektekkel való hasonlóság NEM a véletlen műve. Az élőkre és holtakra, valamint a titoktartási szerződésekre való tekintettel azonban néhány adatot megváltoztattunk – de a lényeg és a kihívások teljesen valósak.
1. Hibaüzenetek vadászata: Amikor a kód zárt könyv
Helyzet: Egy komplex pénzügyi alkalmazásnál a fejlesztők azt állítják, hogy minden hibakezelés implementálva van. A problémád csak annyi, hogy nincs hozzáférésed a forráskódhoz – csak a UI-t használhatod. A feladatod megtalálni azokat a hibaüzeneteket, amelyek valószínűleg léteznek a kódban, de a normál használat során nem jelennek meg.
Miért trükkös: Mint amikor egy épületben keresel titkos szobákat – tudod, hogy valószínűleg vannak, de nem látod, hogy hol. A hibaüzenetek gyakran „dead code” területeken vannak, amelyeket a normál tesztelés nem ér el.
Gondolkodtató tipp: Kezdd azzal, hogy térképezd fel az alkalmazás állapotait. Hol vannak azok a pontok, ahol a rendszer validációt hajt végre? Mi történik, ha ezeket a validációkat megkerülöd? Gondolj arra, hogy a frontend validáció és a backend validáció között gyakran van eltérés. A böngésző fejlesztői eszközei itt a legjobb barátaid.
2. Pairwise tesztelés: Amikor a kombinációk száma a csillagokéval versenyez
Helyzet: Egy e-commerce rendszer checkout folyamatánál 8 különböző paramétert kell tesztelned: fizetési mód (5 opció), szállítási mód (4 opció), kedvezménykód (van/nincs), új/visszatérő felhasználó, mobilapp/webes felület, különböző országok (10 fő célpiac), newsletter feliratkozás (igen/nem), ajándékcsomagolás (igen/nem).
Ha minden kombinációt tesztelnél, az 5×4×2×2×2×10×2×2 = 6400 teszteset lenne. Természetesen erre nincs időd, erőforrásod, és valószínűleg türelmed sem.
Miért intelligens megoldás?: A pairwise tesztelés azon a megfigyelésen alapul, hogy a legtöbb hiba két paraméter kölcsönhatásából adódik. Ez olyan, mint amikor egy új városban autózol – nem kell minden utcát végigjárnod ahhoz, hogy megértsd a közlekedési rendszert, elég, ha a főbb kereszteződéseket és azok kombinációit kipróbálod.
Gondolkodtató tipp: Használj pairwise tesztelés generáló eszközöket (pl. PICT, ACTS). De előtte gondold át: melyek azok a paraméterek, amelyek valószínűleg együtt okoznak problémát? A fizetési mód és az ország biztosan interakcióba lép, de a newsletter feliratkozás és az ajándékcsomagolás valószínűleg nem.
3. PICT mesterfokon: Amikor a pairwise találkozik a boundary értékekkel
Helyzet: Egy számlázórendszerben a következő paramétereket kell tesztelned:
- Számlázási időszak (havi/negyedéves/éves)
- Kedvezmény százalék (0-100%)
- Tételek száma (1-1000)
- Ügyfél típus (magánszemély/cég/nonprofit)
- Pénznem (HUF/EUR/USD)
Itt azonban nem elég a pairwise tesztelés, mert vannak boundary értékek is: a kedvezmény 0%, 1%, 99%, 100% értékeknél lehet érdekes, a tételek számánál pedig 1, 2, 999, 1000 értékeknél.
Miért összetett?: Ez olyan, mint a modern fociban a les helyzetek stratégiai használata – nem elég az alapvető játékhelyzeteket ismerni, hanem pontosan a szélsőséges pillanatokban (játékos épp a les vonalon van, vagy 5 centivel előtte/mögötte) dől el a meccs sorsa, és ezekre a bonyolult kombinációkban is figyelni kell. A PICT eszköz képes kezelni a constraints-eket és a súlyozást is.
Gondolkodtató tipp: Definiáld külön a boundary értékeket tartalmazó almezőket. Például a kedvezmény esetén: {0, 1, 50, 99, 100}. Használd a PICT súlyozási funkcióját, hogy a kritikus kombináció gyakrabban szerepeljenek. És ne felejts el constraint-eket definiálni – például nonprofit szervezeteknek valószínűleg más kedvezményi szabályok vonatkoznak.
4. Időutazás az adatbázisban: Historikus adatok konzisztencia ellenőrzése
Helyzet:
Egy HR rendszerben az alkalmazottak fizetési adatait tárolja a rendszer. Minden változtatás historikus, tehát láthatod, hogy ki mikor mennyit keresett. A probléma: gyanús, hogy vannak időbeli inkonzisztenciák. Például valaki 2023. március 15-én 500.000 Ft-ot keresett, április 1-jén 450.000 Ft-ot, de március 20-án valahogy 480.000 Ft szerepel – ami időben később lett rögzítve.
Miért nehéz?: Ez olyan, mint egy időutazós film logikai hibáinak keresése. Az adatbázis queries-eket írni kell, amelyek képesek az átfedéseket és időbeli anomáliákat detektálni.
Gondolkodtató tipp: Használj ablakozó függvényeket (window functions) SQL-ben. A LAG() és LEAD() függvények segítségével összehasonlíthatod az egymást követő rekordokat. Keress olyan eseteket, ahol a valid_from és valid_to dátumok átfednek, vagy ahol hiányoznak időszakok. Egy jó pattern:
sql:
SELECT employee_id,
salary,
valid_from,
valid_to,
LAG(valid_to) OVER (PARTITION BY employee_id ORDER BY valid_from) as prev_valid_to
FROM salary_history
WHERE valid_from <= LAG(valid_to) OVER (PARTITION BY employee_id ORDER BY valid_from)
5. API tesztelés: Amikor a dokumentáció hazudik
Helyzet: Egy mikroszolgáltatás-alapú rendszerben az egyik API endpoint dokumentációja szerint a válasz mindig JSON formátumban érkezik, és minden kötelező mező garantáltan benne van. A gyakorlatban azonban gyanítod, hogy vannak edge case-ek, amikor ez nem igaz.
Miért realisztikus?: Az API dokumentáció olyan, mint a GPS – általában jó, de néha olyan utakra küld, ami nem is létezik. A valós rendszerekben az API-k gyakran különböző állapotokban különbözően viselkednek.
Gondolkodtató tipp: Próbálj meg olyan kéréseket küldeni, amelyeket a dokumentáció nem említ. Mi történik, ha:
- A request body-ban extra mezőket küldesz?
- Hiányzó kötelező mezőket hagysz ki?
- Rossz típusú adatokat küldesz (string helyett number)?
- Nagyon hosszú stringeket küldesz?
- Különleges karaktereket (emoji, unicode) használsz?
Használj fuzzing technikákat és automatizált API tesztelő eszközöket. A fuzzing lényege, hogy életszerű, de véletlen adatokat (fake) generálsz és küldöd az API-nak, hátha valami váratlan válasszal vagy hibával reagál. Postman-ben ilyenek a dinamikus változók.
6. Teljesítmény tesztelés: A lassú halál szimulálása
Helyzet:
Egy közösségi média alkalmazásnál a fejlesztők állítják, hogy a rendszer 10.000 egyidejű felhasználót képes kiszolgálni. Neked kell ezt ellenőrizni, de nem érdekel a brute force „bombázás” – értelmes terhelési forgatókönyveket kell készítened.
Miért kifinomult?: A teljesítmény tesztelés olyan, mint egy zenekar próbája – nem elég, ha minden hangszer hangos, harmóniában is kell játszaniuk. A valós felhasználók nem egyszerre nyomják meg ugyanazt a gombot.
Gondolkodtató tipp: Modellezd a valós felhasználói viselkedést. Egy tipikus session: bejelentkezés, böngészés, poszt írása, kommentelés, kijelentkezés. Használj különböző „persona” mintákat: van aki sokat olvas, van aki sokat ír, van aki csak görget. A terhelést fokozatosan növeld, és figyeld, hogy hol vannak a töréspontok.
Egy másik fontos megközelítés a hosszútávú terhelés tesztelés (soak testing): itt nem a maximális kapacitást keresed, hanem egy közepesen magas terheléssel órákig vagy napokig futtatod a rendszert. Gyakran itt bukkannak fel a memóriaszivárgások, a lassan telítődő cache-ek, vagy azok a finom hibák, amelyek csak egy idő múlva válnak kritikussá.
Összegzés: A tesztelés művészete
Ezek a feladatok mind arról szólnak, hogy a tesztelés több mint mechanikus folyamat – kreatív problémamegoldás. Minden projektben vannak rejtett csapdák, dokumentálatlan viselkedések, és váratlan események.
A jó tesztelő olyan, mint egy jó nyomozó: felteszi a megfelelő kérdéseket, követi a nyomokat, és nem adja fel, amikor az első próbálkozás nem vezetett eredményre. És igen, néha a Watson-nak kell lenned, aki a nyilvánvaló dolgokat is ellenőrzi – mert a nyilvánvaló dolgok is potenciális hibaforrások.
A legfontosabb tanács: mindig gondolj arra, hogy a fejlesztők emberek, és az emberek hibáznak. A te feladatod megtalálni ezeket a hibákat, mielőtt a felhasználók találják meg őket. És hidd el, ők biztosan meg fogják találni – általában a legrosszabb pillanatban.
