A szoftvertesztelés világa elsőre hatalmasnak és kuszának tűnhet. Tesztesetek, hibák, határidők, fejlesztők, sprintcélok… és persze mindenki azt szeretné, hogy minden teszt készen legyen mielőtt a szoftver kikerül a felhasználókhoz. A valóságban azonban ritkán van idő mindent letesztelni. Itt jön képbe a priorizálás.
A jó tesztelő nem az, aki mindent letesztel — hanem az, aki a legfontosabb dolgokat teszteli le először.
Ebben a cikkben végigvesszük a legfontosabb elveket, amelyek segítenek eldönteni, mire érdemes fókuszálni, ha kevés az idő, sok a feladat, és szeretnél hatékony maradni.
Üzleti érték: mi a legfontosabb a felhasználóknak?
A tesztelés egyik legfontosabb kérdése: „Mi az, ami a legtöbb felhasználót érinti?”
Ha egy funkció kritikus az üzlet szempontjából — például fizetés, bejelentkezés, keresés — akkor ezeknek a tesztelése mindig elsőbbséget élvez.
Miért? Mert ha ezek hibásak, az közvetlenül bevételkiesést, felhasználói elégedetlenséget vagy akár teljes szolgáltatásleállást okozhat.
Példa: Egy webshopban a „Kosárba rakás” funkció fontosabb, mint a „Profilkép feltöltése”.
Kockázat alapú gondolkodás: mi romolhat el, és milyen következménnyel?
A kockázat két tényezőből áll:
- Mekkora az esélye, hogy elromlik?
- Mekkora a baj, ha elromlik?
A magas kockázatú területeket mindig előre kell venni.
Példa: Egy banki alkalmazásban a pénzátutalás funkció hibája sokkal súlyosabb, mint egy elcsúszott ikon a menüben.
Funkció összetettsége: minél bonyolultabb, annál több a hiba esélye
A komplex funkciók több komponensből állnak, több adatot mozgatnak, több külső rendszert érintenek — vagyis több helyen romolhatnak el.
Ezért a bonyolult funkciók tesztelése gyakran magas prioritást kap.
Példa: Egy több lépéses regisztrációs folyamat több hibalehetőséget rejt, mint egy egyszerű gombnyomás.
Időnyomás és határidők: mi készül el először?
A tesztelés gyakran a fejlesztés üteméhez igazodik. Ha egy funkció hamarabb készül el, azt előbb is kell tesztelni.
Ez nem csak praktikus, hanem segít abban is, hogy a fejlesztők még időben javíthassák a hibákat.
Tipp: Mindig kommunikálj a fejlesztőkkel — így tudod, mi mikor lesz tesztelhető.
Változások mértéke: ahol sokat módosítottak, ott több a hiba esélye
Ha egy funkciót vagy modult jelentősen átdolgoztak, az növeli a hibák kockázatát. Ezért a frissen módosított részeket érdemes előre venni.
Példa: Ha egy régi kódrészletet teljesen újraírtak, ott nagyobb eséllyel bukkan fel regresszió.
Alapvető működés (happy path): először a „boldog útvonalat” teszteld
A „happy path” az az útvonal, amikor minden úgy történik, ahogy kell:
- helyes adatok
- normál felhasználói viselkedés
- ideális körülmények
Ez az, amit a legtöbb felhasználó nap mint nap használ. Ha ez nem működik, minden más tesztelés értelmét veszti.
Automatizált tesztek eredményei: mire figyelmeztet a rendszer?
Ha vannak automatizált tesztek, azok eredményei segítenek a priorizálásban:
- Mi esett el?
- Hol vannak piros jelzések?
- Melyik modulban nőtt meg hirtelen a hibák száma?
Az automatizáció nem helyettesíti a manuális tesztelést, de kiváló iránytű.
Összegzés: a jó priorizálás fél siker
A tesztelés nem arról szól, hogy mindent letesztelj — hanem arról, hogy a legfontosabb dolgokat teszteld le időben. Ha kezdő vagy, ezek az elvek segítenek abban, hogy magabiztosabban dönts arról, mire fordítsd az idődet:
- Üzleti érték
- Kockázat
- Összetettség
- Határidők
- Változások mértéke
- Happy path
- Automatizált tesztek jelzései
Ahogy egyre több tapasztalatot szerzel, ezek a szempontok természetessé válnak, és egyre gyorsabban fogsz tudni jó döntéseket hozni.