Robert Whitney
A pontos és helyes szoftvertesztelés végrehajtása számos elvet követ. A Nemzetközi Szoftvertesztelési Képesítési Testület hét alapvető elvet különböztet meg, amelyeket ma meg fogunk beszélni. Kíváncsi vagy, hogy mik ezek? Olvass el egy cikket a kulcsfontosságú ISTQB tesztelési elvekről!
ISTQB tesztelési elvek – tartalomjegyzék:
- A tesztelés felfedi a hibákat, de nem tudja bizonyítani azok hiányát
- A teljes körű tesztelés lehetetlen
- A korai tesztelés időt és pénzt takarít meg
- A hibák hógolyó hatása
- A peszticid-paradoxon
- Ez a kontextustól függ
- A hibátlan szoftver hirdetése nem megengedett
- Összefoglalás
A tesztelés felfedi a hibákat, de nem tudja bizonyítani azok hiányát
A tesztelés növeli a hibák felfedezésének valószínűségét, ami megkönnyíti azok javítását. Azonban nem tudja teljes mértékben garantálni, hogy a szoftver mentes minden hibától, még akkor sem, ha a többségüket észlelik és javítják. A hibátlan szoftver létrehozásának képtelensége miatt sokan negatívnak tartják a folyamatot, mivel soha nem kapsz pozitív eredményt, és mindig találsz valami “piszkot” a programokban.
A teljes körű tesztelés lehetetlen
A fenti irányelv azt állítja, hogy minden szoftverhibát észlelni lehetetlen. Ez azonban nem vonatkozik az egyszerű, rövid programokra. Ez pedig azt jelzi, hogy van esély arra, hogy lássuk az összes bemeneti és előfeltételi kombinációt, hogy néhány programot teljesen teszteljünk. Bonyolult szoftverek értékelésekor még a legjobb mesterséges intelligencia sem tudja végrehajtani az összes szükséges mérést, nemhogy a manuális tesztelők. Az automatizált értékelők hatékonyabban és pontosabban futnak át az alkalmazásokon, de még mindig nem tudják garantálni a hibátlan teljesítményt. Ehhez további feladatokat kell vállalni, mint például a prioritás megállapítása, kockázatelemzés, valamint más tesztelési technikák keresése és végrehajtása.
A korai tesztelés időt és pénzt takarít meg
Sok szakember ezt az elvet “balra tolásnak” is nevezi. Minél előbb észleled a hibákat, annál könnyebben tudod azokat javítani, ezért a statikus és dinamikus tesztelést a lehető leghamarabb el kell kezdeni. Röviden:
- Statikus tesztelés – a termék értékelése a kód futtatása nélkül.
- Dinamikus tesztelés – a modul vagy rendszer kódjának értékelése a teljesítése során
A hibák észlelése a megvalósítás első fázisaiban megkönnyíti a további diagnózist. De amikor a szoftver két területe kölcsönhatásba lép, a hibák javítása nehézkessé válik, mivel nem lehet pontosan meghatározni, hogy melyikben van a hiba. Ilyen esetekben extra időre, erőfeszítésre és munkaerőre van szükség a kezeléshez. Összességében a felmerülő akadályokra adott gyors válaszok megakadályozhatják a repedések szaporodását.
A hibák hógolyó hatása
A legtöbb hiba a legkritikusabb modulokban csoportosul, így a mélyreható vizsgálat felfedi és elegendően megszünteti a legtöbbet. Ezek a csoportok a kockázatelemzés fő fókuszává válnak a jövőbeli cselekvések térképezéséhez és megállapításához. A hibák többsége a felhasználók által követett utak mentén bukkan fel, de ezekben az esetekben a tudás önmagában nem teszi a modulokat kifogástalanná.
A Pareto-elv azt mondja, hogy a eredmények 80%-a csupán 20%-ból származik. Más szavakkal, a hibák 80%-a a modulok 20%-ában található. Ha számos hibát találsz egy modulban, folytasd a kutatást, mert ott lesznek.
A peszticid-paradoxon
Ugyanazoknak a teszteknek az ismételt futtatása kudarcot vallhat, mert lehet, hogy eredetileg helytelenül tervezték őket, és soha nem bizonyulnak hatékonynak. Módosítanod és fejlesztened kell a tesztelést az új hibák felfedezésének esélyének növelése érdekében.
Teljesen új diagnosztikai rendszer létrehozása sem segít. Az előző kombinációk követése megállíthatja az értékelési folyamatot ugyanazon a szinten. Ezt az elvet ‘peszticid-paradoxnának’ nevezik, mert a kártevők ellenőrzésére szolgáló peszticidek is elveszítik hatékonyságukat egy adott használati mennyiség után.
Ez a kontextustól függ
A tesztelés végrehajtásának módja a vizsgált alanyoktól függ. Így egy könyvelési program, egy videójáték vagy egy közösségi hálózati alkalmazás tesztelése lényegesen eltérő. Ez a helyzettől is függ, például egy alkalmazás praktikusságára összpontosító elemzés, mint például a felhasználók számára vonzó, használhatóság, vizuális réteg stb. szintén eltér azoktól az értékelésektől, amelyek a program funkcionális attribútumaira irányulnak, pl. helyes számítások végrehajtása.
A hibátlan szoftver hirdetése nem megengedett
Különböző diagnosztikai eszközök alkalmazása nem garantálja a pontos alkalmazásokat. Sokan, akik azt állítják és hirdetik az alkalmazásaikat, hogy ilyenek, tévednek, de valószínűleg csak a marketing erőfeszítéseik miatt teszik ezt a kijelentést. Több manuális és automatizált tesztet végezhetsz, hogy növeld a hibák felfedezésének és javításának valószínűségét, de még mindig nincs garancia a tökéletes teljesítményre. Egyes esetekben az akadályok a működő szoftverrel kapcsolatosak, pl. a program nem felel meg minden felhasználói elvárásnak.
ISTQB tesztelési elvek – összefoglalás
Így az ISTQB alapvető szinten bemutatja a hét ISTQB tesztelési elvet, amelyet egy szoftvertesztelőnek követnie kell. Először is, jelzik a teljes szoftverdiagnózis megvalósíthatatlanságát, ezért fontos, hogy mások mellett módosítsuk a teszteket, valamint alapos keresést végezzünk a kulcsfontosságú modulokban. Ezek a lépések javítják a hibák többségének keresését és eltávolítását, csökkentve a jövőbeli hibák valószínűségét.
Mi a szoftvertesztelés? Most már tudod a választ! Nézd meg más sorozatainkat a Python és Javascript témában!
Ha tetszik a tartalmunk, csatlakozz a szorgos méheink közösségéhez a Facebookon, Twitteren, LinkedInen, Instagramon, YouTube-on, Pinteresten.
Robert Whitney
JavaScript szakértő és oktató, aki IT osztályokat mentorál. Fő célja, hogy növelje a csapat termelékenységét azáltal, hogy megtanítja másoknak, hogyan működjenek együtt hatékonyan a kódolás során.
