Szoftver tesztelés és minőségbiztosítás 2002 Molnár D. László A szoftver tesztelése során vallott missziónk A misszió minden lépést befolyásol, és segítséget nyújt számos területen, hogy Gyorsan felfedezzük a fontos programhibákat Általános kulcsunk legyen a termék minőségének megállapításához Igazoljuk, hogy a termék megfelel bizonyos standardoknak A felhasználók is hozzájáruljanak a termék minőségének és tesztelhetőségének javításához A tesztelési folyamat feleljen meg bizonyos "számonkérhetőségi" standardoknak Fejlessze a felhasználókat is a tesztelésben és a tesztelőkkel való együttműködésben Bizonyos előre meghatározott módszerek és szabályok érvényesüljenek a tesztelés során Elősegítse a terméktámogatás költségének megállapítását és ellenőrzését Segítse a felhasználókat munkafolyamataik javításában A munka a lehető legkisebb indokolt költséggel, a lehető legrövidebb idő alatt, "mellékhatások" nélkül készüljön el Együttműködés alakuljon ki a programozókkal Szinte mindent megkérdőjelezzenek, de ne kürtöljenek ki mindent azonnal a külvilágba A sikertelen dolgokra koncentráljanak annak érdekében, hogy a felhasználó a sikert érzékelje Mindent megtegyenek annak érdekében, hogy felhasználók elégedettek legyenek A teszteléssel nem biztosítjuk a minőséget Viszonylag könnyű arra gondolni, hogy a tesztelők a minőség őrei Azonban a minőség a termék készítőitől származik Missziónk nagy része arra irányul, hogy a készítők foglalkozzanak a minőséggel és hatékonyabban, mint egyébként tennék Amennyiben mi végezzük a tesztelést, csoportunk "minőségbiztosítási" csoportnak is nevezhető Teszt eredményeink és hibalistáink valóban elősegítik a termék minőségének javítását, azonban ez a javulás nem csak a tesztelők érdeme, hanem az egész munkacsoport munkájának az eredménye A tesztelők nem kapuőrök Egyes tesztelők azt gondolják, hogy joguk van megakadályozni a termék forgalomba hozatalát, szinte vétójoguk van A probléma az, hogy amennyiben a tesztelők szabják meg a forgalomba hozatal időpontját, nekik kell viselniük a termék minőségéért a felelősséget is Végső soron azok az emberek vezetik a programfejlesztést, akik a felelősséget is vállalják a termék forgalomba hozataláért
Mindazonáltal a legsikeresebb termékfejlesztési munkáknál általában ki szokott alakulni valamilyen konszenzus ebben a tekintetben Amennyiben valaki megszabhatja, hogy mikor lehet a terméket publikálni, célszerű, hogy az illető a munkacsoport összes egyéb jogosítványával is rendelkezzen A "nem a mi problémánk" kérdése a tesztelés során A tesztelés komplex folyamat és tevékenység, amely szorosan kapcsolódik más tevékenységekhez. Ennek ellenére egyesek szívesen leszűkítenék a tesztelés folyamatát a terméknek a tervtől való eltéréseire Érdemes ennél sokkal szélesebb értelemben felfogni a tesztelést A tesztelés valójában foglalkozik a következőkkel használhatóság mi szükséges a programhoz, futtatásához adatok minősége program támogathatósága melyek mind ugyancsak a "mi problémánk" Missziónk a tesztelés során a csoport tájékoztatása, legjobb tudásunk szerint, bármely olyan problémáról, amelyek kedvezőtlen hatással lehetnek a termék minőségére a jó tesztelő csoportok különböző típusú, feladatkörű embereket vonnak be a munkába, akik együttesen megértik, átlátják a termék készítésének lényegét, folyamatát? Hogyan készül a terve, mi módon készítik, hogyan dobják piacra, milyen feltételekkel árusítják, hogyan fogják használni, karbantartani és frissíteni Váljunk folyamatjavító csoporttá Úgy gondolhatjuk, hogy könnyebb a hibák keletkezését megelőzni, mint kijavítani Továbbá úgy gondolhatjuk, hogy kevesebb hiba lenne, ha a programozó körültekintőbben járna el munkája során Ezeknek az elgondolásoknak van értelme, már amennyiben megvalósíthatók Sikeresen részt vehetünk a folyamatjavítási munkában, és sikeresek lehetünk, amennyiben a javítás az egész csoport munkájának a része Jelentésre és kijavításra érdemes programhibák A programhibák megzavarják a felhasználókat és csökkentik a szoftver iránti bizalmukat A gyakori programhibák a következők: Helyesírási hibák Képernyő formázási hibák Egérnyom (kis foltok, nyomok jelennek meg az egér mögött mozgatása során) Számítási hibák Az ábrák, grafikonok nem megfelelő méretűek
Hibák a képernyőre hívható segítségben Menüpontok, amelyek nem szürkülnek el, amikor kellene, illetve elszürkülnek, amikor nem kellene Nem működő billentyűkombinációk Helytelen hibaüzenetek Szélső értékek (túl nagy vagy túl kicsi számok) helytelen kezelése Időbeállítások, időkorlátozások helytelen működése Egyéb hibák Gondolkodjunk tesztelőként A jó tesztelők technikai szempontból, kreatívan, kritikusan és gyakorlatiasan gondolkodnak Valamennyi gondolkodási típusnak jelentősége van a tesztelés során A gondolkodás négy fő típusa Technikai gondolkodás A technikai gondolkodás annak a képessége, hogy magunkban modellezzük a technológiát és megértsük az okokat és következményeket. Ez magában foglalja a fontos technikai tények ismeretét, az eszközök használatát és a rendszer várható működésének ismeretét, előre látását. Kreatív gondolkodás A kreatív gondolkodás révén képesek vagyunk új ötletekre, és a lehetőségek felmérésére. Rendszerint csupán olyan módon tesztelünk, ahogy elképzeljük a tesztelés folyamatát. Csupán olyan problémák után kutatunk, amelyek létezését elképzeljük. Kritikai gondolkodás A kreatív gondolkodás segít abban, hogy az elképzeléseket értékeljük és következtessünk. Ez magában foglalja a gondolkodásunkban jelentkező hibák észlelését és elhárítását, megfigyeléseinknek a minőség szempontokkal való összevetését, és adott elgondolás vagy esemény elbírálását. Gyakorlatias gondolkodás A gyakorlatias gondolkodás az a képesség, hogy az elméletet a gyakorlatba ültessük. Ez magában foglalja a tesztelő eszközök alkalmazásának vagy kifejlesztésének képességét, amelyek a program sikeres teljesítését segítik. Implicit és explicit specifikációk Specifikáció alatt a program működésének és peremfeltételeinek meghatározását értjük Az explicit, kimondott, leírt specifikáció igen hasznos, mert a készítők vagy a felhasználók által elfogadott követelményeket, kritériumokat önt formába egyértelműen Az implicit specifikáció viszont nincs egyértelműen elfogadva vagy leírva a készítők vagy a felhasználók által Az implicit specifikáció gyakran nem annak alapján keletkezik, hogy a program legjobb legyen a felhasználók szempontjából, hanem sokszor a meggyőző ereje vagy a hihetősége
határozza meg. Nemegyszer az implicit specifikációknak alig van közük a kifejlesztendő termékhez. Az implicit specifikációknak számos formája létezik: Hasonlítás versengő termékekhez Hasonlítás kapcsolódó termékekhez Hasonlítás ugyanazon termék korábbi verzióihoz A fejlesztés során váltott e-mailek tartalma A fogyasztók által tett észrevételek, megjegyzések Újságcikkek, folyóiratcikkek (például a korábbi verzióval kapcsolatban) Tankönyvek mondatai a témával kapcsolatban (A program tartalmához hasonló témájú könyv mit ír, melyet összehasonlítanak a program tartalmával) A grafikus felhasználói felületre (GUI) vonatkozó stílus-ajánlások Operációs rendszerrel kapcsolatos kompatibilitási követelmények Saját jól megalapozott tapasztalataink Heurisztikák alkalmazása a tesztelés során A heurisztika lényegében ökölszabály, hüvelykujjszabály Célja, hogy képzett emberek által jóváhagyott módon cselekedjünk új helyzetben Jóllehet a heurisztika nem biztosítja a helyes cselekvést kritikus helyzetekben, mindazonáltal időnként jó szolgálatot tehet Példák heurisztikák alkalmazására Szélső értékek tesztelése A szélső értékek valószínűleg nem egyértelműek a specifikációban Valamennyi hibajelzés tesztelése A hibakezelés általában gyengébben van megírva, mint a főprogram Beállítások tesztelése A különböző programozók beállításai általában eltérőek. Emiatt abban a hamis hitben élnek, hogy a program más beállítás mellett is működni fog Futtatási teszt Ez eléggé gondot szokott okozni. Emiatt a könnyen elvégezhető futtatási tesztek elvégzésének a valószínűsége nagyobb, mint a nehezebben tesztelhető funkcióké Ötszörös tesztelő rendszer Tesztelők Ki végzi a tesztelést Tesztelendő Mit kell tesztelni Potenciális problémák Miért tesztelünk (és mi ellen tesztelünk: például a szélső értékek kezelését stb.) Tevékenységek
Hogyan tesztelünk. Például exploratív, feltáró célzatú tesztelést hajtunk végre Értékelés Hogyan tolmácsoljuk, hogy a teszten a program "átjutott" vagy nem A tesztelés egyéb szempontjai Működés tesztelése Kimerítően teszteljük a program valamennyi funkcióját Szélső értékek tesztelése Teszteljük a program miként kezeli a hibákat, amikor szélső értéket adunk valamelyik változónak (például nagy számot írunk be valamelyik mezőbe) Béta-tesztelés Valamilyen külső fogyasztónk, régi vevőnk, vagy velünk kapcsolatban álló szakember teszteli a szoftvert Emberekre alapozott tesztelési technikák Ezek elsősorban arra irányulnak, hogy ki végzi a tesztelést Felhasználói tesztelés Tesztelés olyan emberek által, akik jellemző módon, tipikusan a mi szoftverünket használják Alfa-tesztelés Házon belüli tesztelés, amelyet a fejlesztő munkacsoport, vagy más éházon belüli érdeklődők végeznek el Béta-tesztelés A tesztelést olyanok végzik, akik nem tagjai a fejlesztő munkacsoportnak, sőt a szervezetnek sem, viszont a termékünk célpiacának tagjai Ilyenkor a termék fejlesztése rendszerint már közel van a befejezéshez A béta-tesztelés típusai Tervezési béta teszt Megkérjük a felhasználókat vagy a témában szakértőket, hogy értékeljék a program külalakját (design) Lehetőleg korán meg kell kezdeni, hogy maradjon idő a változtatások elvégzéséhez Marketing béta-teszt Célja a nagy fogyasztók megnyerése, hogy megvásárolják a termékünket, amint piacra kerül és nagy hálózataikon is helyezzék el A fejlesztés meglehetősen késői fázisában kerül sorra, amikor a termék már eléggé kiforrott
Kompatibilitási béta-teszt A felhasználó olyan hardveren és szoftver platformon teszteli termékünket, amely számunkra nem áll könnyedén rendelkezésre Erre nem túl későn kell sort keríteni, hogy még időben fel lehessen fedezni és megoldani a kompatibilitási problémákat Gyors tesztelés Házon belüli tesztelés, amelyet a titkárnők, programozók, termékmenedzserek és minden más elérhető ember végez. A tipikus gyors tesztelés fél napig tart és akkor végezzük, amikor a szoftver már majdnem kész Adott területre vonatkozó szakértői tesztelés A szoftvert szakértőnek adjuk bizonyos körülírt kérdésekkel, problémákkal kapcsolatban és visszajelzést kérünk, nevezetesen a hibák feltárását, kritikai észrevételeket, javaslatokat, esetleg helyeslést A szakértő nem feltétlenül a programunk későbbi felhasználója, hanem sokkal inkább a szakértelmére építünk Páros tesztelés Két tesztelő együtt dolgozik a hibák megtalálása érdekében Általában egy gépen dolgoznak és megosztják egymással ötleteiket, tapasztalataikat Együk meg, amit főztünk A saját szervezetünk is használja piacra dobás előtt a szoftvert Rendszerint érdemes várni addig, amíg a szoftver elég megbízhatóan működik, mielőtt éles használatba és eladásra kerülne A tesztelés tárgyára irányuló technikák A tesztelés tárgyára irányuló technikák a termékre koncentrálnak Számos technika áll rendelkezése, amelyek különbözőképpen csoportosíthatók attól függően, hogy mire kívánjuk használni ezeket Például a az egyes program tulajdonságok integráltságának tesztelése termék orientált, amennyiben azt vizsgáljuk, hogy minden funkció megfelelően működik-e a többi funkcióval együtt (kombinációban) Ugyanez probléma orientált, amennyiben van valamilyen elképzelésünk arról, hogy miért van valamilyen hiba, és ennek keletkezését nyomon szeretnénk követni. Lehet például, hogy az egyik függvénynek vagy szubrutinnak nem vagy nem jól adjuk át az értékeket Működés tesztelése
Minden egyes működési elem, függvény, szubrutin tesztelése egyenként Az elemek, függvények, szubrutinok lehetőleg teljes körű tesztelése annak megállapítása érdekében, hogy azok valóban jól működnek Fehér doboz függvény tesztelés Ezt rendszerint egység tesztelésnek is nevezik, és rendszerint az egyes, forráskódban megjelenő önálló függvények vagy szubrutinok tesztelését jelenti Fekete doboz függvény tesztelés Ennek során a parancsokra és olyan dolgokra, tulajdonságokra figyelünk elsősorban, amelyeket a felhasználó ki tud választani, vagy amellyel elő tud idézni valamilyen működést Ajánlott a függvény tesztelés elvégzése mielőtt bonyolultabb tesztek során több függvény együttes tesztelését végeznénk el Összetett tesztelés során az első hibás függvény leállítja a program futását, és esetleg nem állapítható meg egykönnyen, hogy melyik függvény volt a hibás Tulajdonságok és függvények integráltságának tesztelése Ennek során elemezzük, hogy a tulajdonságok, függvények megfelelően kapcsolódnak-e egymáshoz, integrált-e a rendszer Menü vizsgálat Végig kell menni valamennyi menüponton a grafikus felhasználói felületen és minden választási lehetőséget kipróbálni Domain tesztelés A domain olyan (matematikai) halmaz, amely magában foglalja egy változó, illetve függvény valamennyi lehetséges értékét A domain tesztelés során azonosítjuk a változókat és függvényeket A változók bemeneti és kimeneti változók egyaránt lehetnek Minden egyes változóhoz a lehetséges változókat ekvivalencia osztályokba soroljuk és kiválasztjuk belőlük kis részhalmazukat, rendszerint a szélső értékek környékén a teszteléshez Ekvivalencia osztály tesztelés Az ekvivalencia osztály a változó azon értékei, amelyeket ekvivalensnek tekintünk A teszt-esetek ekvivalensek, ha úgy gondoljuk, hogy Valamennyien ugyanazt tesztelik Ha az egyikkel kapcsolatban programhiba van, akkor valószínűleg a másikkal kapcsolatban is Ha az egyikkel kapcsolatban nincs programhiba, akkor valószínűleg a másikkal kapcsolatban sincs Határoló érték tesztelés Az ekvivalencia osztály értékek halmazából áll Ha le tudjuk képezni ezeket az értékeket a számegyenesre, akkor a határoló értékek az osztály legkisebb és legnagyobb értékei
A határoló érték tesztelésnél ezeket az értékeket teszteljük, továbbá a közelükben fekvő további értékeket is A legjobb képviselő tesztelése Az ekvivalencia osztály legjobb képviselője a változónak olyan értéke, amely ugyanolyan valószínűséggel okoz programhibát, mint bármely más érték A legjobb képviselő tesztelése során általában a szélső értékeket és a közelükben fekvő értékeket szokták tesztelni elsősorban Beviteli mező tesztelése és az eredmény elhelyezése táblázatban Minden egyes beviteli mező teszteléséhez célszerű kidolgozni standard tesztelési eljárást és ezeket a módszereket kell alkalmazni minden hasonló mező tesztelése során Minden lehetséges módon teszteljük a mező tartalmának módosíthatóságát Adott mező tartalmát rendszerint többféle módon megváltoztathatjuk Például importálhatjuk kívülről, bevihetjük közvetlenül billentyűzetről, a programmal kiszámoltathatjuk és feltölthetjük a mezőt valamilyen számított értékkel, és így tovább. A mező tartalma általában csak bizonyos értékeket vehet fel. Logikai kapcsolatok tesztelése A programban az egyes változók között logikai kapcsolatok lehetnek. Például a programba beépítettek olyan döntést, hogy ha az életkor nagyobb, mint 50, és a dohányzás "igen" értéket kapott, akkor a "felajánlunk-e biztosítást" mező automatikusan "nem"-re állítódik Az ilyen típusú döntési szabályok logikai kapcsolatokat tartalmaznak A logikai kapcsolatok tesztelése során megkísérlik valamennyi lehetséges logikai kapcsolatot egyenként tesztelni Állapot tesztelés A program működése közben egyik állapotából másik állapotába mehet át Adott állapotban bizonyos bemenő értékek elfogadhatóak, míg másik állapotban nem. Például bizonyos mezők akár el is szürkülhetnek, vagy nem lehet oda adatot bevinni, míg máskor igen A helyes érték bevitelekor a program tesz valamit, és nem tesz olyat, amit nem tehet meg Az állapot tesztelés során a tesztelő végigmegy a programon és az ilyen típusú működéseket teszteli körültekintően Út tesztelés Az út tesztelés magában foglalja mindazokat a lépéseket, amelyeken a program végigment, amíg a megadott állapothoz érkezett Az út tesztelés rendszerint számos más útvonal tesztelését magában foglalja Azonban bizonyos bonyolult programok esetében elképzelhető, hogy nem lehet valamennyi utat bejárni Programsorok és elágazások tesztelése Száz százalékos programsor tesztelést lehet végrehajtani abban az esetben, ha a program minden sorát egyenként teszteljük Száz százalékos elágazás tesztelést lehet végrehajtani abban az esetben, ha a program minden elágazását egyenként teszteljük Konfiguráció lefedettség tesztelése
Abban az esetben, ha 100 printeren kell végrehajtanunk a tesztelést, és csak tízen tettük meg, úgy is fogalmazhatunk, hogy 10 százalékos "lefedettséggel" teszteltük a konfigurációs kompatibilitást Specifikáció alapú tesztelés Ebben az esetben a tesztelés azoknak a kívánalmaknak a tesztelésére vonatkozik, amelyeket a programmal szemben támasztottak Ezeknek a kívánalmaknak a tesztelése általában igen/nem típusú válasszal fejeződik be Ezek a kívánalmak rendszerint megjelennek a program dokumentációban, kézikönyvben, a piacra kerülést kísérő egyéb dokumentumokban, hirdetésekben, valamint a technikai támogatásra vonatkozó leírásokban, amelyeket a felhasználókhoz eljuttatnak Követelmény alapú tesztelés A követelmény alapú tesztelés során kitérnek mindazon szempontok ellenőrzésére, amelyek szerepelnek a dokumentumokban Kombináció tesztelés Ez a tesztelés két vagy több változó együttes tesztelésére vonatkozik Probléma alapú tesztelés Ennek a középpontjában az áll, hogy mi a tesztelés célja, illetve milyen veszély elhárítására irányul a tesztelés Kockázat alapú tesztelés Itt a tesztelés irányát a programhiba bekövetkezésének valószínűsége, illetve a hibából származható kár nagysága határozza meg. Minél nagyobb a hiba bekövetkezésének valószínűsége, illetve a hibából származható kár nagysága, annál inkább és annál korábban szükséges a tesztelés végrehajtása Input korlátozások Input korlátozás alatt az értendő, hogy a program bizonyos határok között tud kezelni dolgokat Például ha a program legfeljebb 32-jegyű számokat tud kezelni, a programozónak olyan védő rutinokat kell írnia, amelyek megakadályozzák, hogy 32 bitesnél nagyobb számokat vigyenek be a rendszerbe Amennyiben nincs ilyen védelem, a program általa feldolgozhatatlan adatokat kísérel meg feldolgozni, amely hibához vezet Output korlátozások Előfordulhat, hogy az input adatok megfelelőek voltak, de mégis a feldolgozás során olyan adatok keletkeztek, amelyeket a program nem tud kezelni A program leállhat vagy hibát jelezhet, amikor ezeket az értékeket megpróbálja megjeleníteni a képernyőn, kinyomtatni, vagy lementeni Számítási megszorítások Abban az esetben, ha a bemeneti és kimeneti adatok megfelelőek, a számítások során keletkezhetnek olyan értékek, amelyek programhibához vezetnek Például két nagy szám szorzata túl nagy számot eredményezhet, amelyet a program nem tud kezelni Tárolási kapacitás megszorítások Abban az esetben, ha a bemeneti és kimeneti adatok, és a számítások is megfelelőek, a program számára esetleg időközben elfogyhat a memória vagy a háttértár
Az időfaktor tesztelése Az időfaktor tesztelése magában foglalja a különböző egymás utáni események idejének, illetve az egymásutániságok helyes sorrendjének a vizsgálatát Tevékenységre alapozott tesztelési technikák Ezeknek a technikáknak az alkalmazása során elsősorban a tesztelés módjára figyelnek Regresszió tesztelés A regresszió tesztelés magában foglalja ugyanannak a tesztnek többszöri alkalmazását, különösen a különböző változásokat követően A regressziós tesztelés típusai Régi hibák újratesztelése Akkor kerül sor rá, amikor úgy gondoljuk, hogy a régi hibákat eltávolították A teszt célja annak bizonyítása, hogy a hiba megszüntetése nem tökéletes A régi hibák regressziós tesztelésének célja annak kimutatása, hogy a régi programhiba kiküszöbölése ellenére az újra előkerül Mellékhatás regressziós tesztelés (stabilitás regressziós teszt) Ez magában foglalja a termék lényeges részeinek újratesztelését Célja annak igazolása, hogy ami korábban működött, a program javítása következtében most nem működik Tesztelés forgatókönyv szerint Kézi tesztelés rendszerint kezdő tesztelő által, amelyet tapasztalt tesztelő által megírt lépésről lépésre megírt forgatókönyv szerint végeznek el Smoke tesztelés Ez a mellékhatás regressziós tesztelés azzal a céllal készül, hogy bizonyítsa, hogy a termék valamelyik új modulja még nem elég érett a további tesztelésre sem A smoke tesztelés gyakran automatizált és standardizált, és egyik modulról a másikra haladnak alkalmazása során Azt tesztelik, hogy a modul az elvárások szerint működik-e, és ha nem, feltételezik, hogy esetleg nem a megfelelő fájllal építették össze vagy valami más alapvető probléma van a modullal Exploratív tesztelés Elvárjuk a tesztelőtől, hogy a munka során tanulja meg a terméket, a potenciális piacát, a kockázatait, és emlékezzen arra, hogy a korábbi tesztek során milyen problémák voltak Folyamatosan keletkeznek új tesztek és ezeket alkalmazzák is Az újabb tesztek hatékonyabbak, mert a tesztelő növekvő tapasztalatain alapulnak Gerilla tesztelés Gyors és ártalmas támadás a program ellen Az exploratív tesztelés egyik formája, mely rövid időszakra korlátozódik, és rendszerint tapasztalt tesztelő végzi A tesztelő a leghatékonyabb módszereket veti be a program ellen Amennyiben jelentős problémákat talál, ennek a területnek a költségvetését is újra alakítják, és az egész tesztelési folyamat is módosulhat Amennyiben nem találnak jelentős problémákat, ettől kezdve az adott területet kevésbé intenzíven tesztelik Forgatókönyv tesztelés
A forgatókönyv tesztelés négy tulajdonsággal jellemezhető (1) A teszt legyen valóságszerű. Tükrözze, amit a felhasználó valóban tenne a programmal (2) A teszt legyen összetett, komplex, foglaljon magában számos tulajdonságot, szempontot, amelynek a programnak meg kell felelnie (3) A teszt legyen könnyen és gyorsan végrehajtható, amelyből megállapítható, hogy a program átment-e a vizsgán vagy sem (4) A tulajdonosok, érintett felek bizonyára erőteljesen amellett érvelnek majd, hogy javítsák ki a programhibákat, ha ilyeneket találnak Telepítés tesztelés A tesztelés során a program különböző, megengedett körülmények között és eltérő, megengedett rendszereken telepítésre kerül Ellenőrzésre kerül, hogy a lemezen mely fájlok adódnak hozzá a meglévőkhöz, illetve melyek módosulnak a telepítés során Működik-e a telepített program Mi történik a telepítés megszüntetése (uninstall) után? Betöltődés tesztelés A program vagy rendszer futásának ellenőrzése úgy történik meg, hogy közben több progrtamot is betöltenek, illetve a rendszer erőforrásait erősen igénybe veszik Igen nagy terhelés mellett a rendszer valószínűleg nem működik, azonban ennek a folyamatnak az elemzése rávilágíthat a rendszer sebezhető pontjaira, és ezeket a tapasztalatokat a fejlesztés során hasznosítani lehet Hosszú ideig tartó tesztelés (ellenállóság, megbízhatóság tesztelése) A tesztelést egész éjszaka vagy napokig, hetekig folytatják. Ennek a célja olyan hibák felderítése, amelyek rövid idejű tesztelésnél nem kerülnek napvilágra. Ilyenek például a pointerekkel, memória-kezeléssel, memória szivárgással, túlcsordulással és alulcsordulással, és ezek valamilyen kombinációjával, kölcsönhatásával kapcsolatos vizsgálatok Teljesítmény tesztelés Ezek a tesztek rendszerint arra irányulnak, hogy milyen gyors a program annak megállapításához, hogy szükséges-e valamilyen optimalizálás. Ezek a tesztek azonban végül számos más programhibát is előidézhetnek, kimutathatnak. A programban a fejlesztés különböző szakaszai között tapasztalt jelentős teljesítményváltozás valamilyen programozási hibára hívhatja fel a figyelmet Kiértékelésre alapozott technikák Ezek arra irányulnak, hogy milyen módon közöljék a program helyes vagy hibás működését A kiértékelésre alapozott technikák között leírják azokat a módszereket, amelyek alkalmasak a program helyes vagy hibás működésére vonatkozó megállapítások, következtetések megtételéhez Ugyanakkor nem mondják meg, hogy hogyan kell magát a tesztelést végrehajtani, hogyan kell adatokat gyűjteni a rendszerről Arról tájékoztatnak, hogy amennyiben tudunk adatokat gyűjteni, hogyan vonjuk le ezek alapján a következtéseket Önellenőrző adatok A tesztelés során az általunk használt adatfájlok alkalmasak lehetnek a kimenő adatok helyességének megállapítására
Tesztelés a lementett eredményekkel való összehasonlítás révén A rendszerint, de nem mindig, automatizált regresszió tesztelés során összehasonlításra kerülnek a jelenlegi eredmények a korábbi, akár múlt heti eredményekkel Amennyiben a múlt héten az eredmények jók voltak, viszont most más eredmények jöttek ki, ez új problémára hívhatja fel a figyelmünket Előre megadott specifikációval vagy egyéb mértékadó dokumentummal való összehasonlítás Amennyiben a program működése nem felel meg a specifikációkkal, ez valószínűleg hibára utal Heurisztikus egyezés Az egyezés (konzisztencia) fontos szempont a program kiértékelése során. A meg nem felelés (inkonzisztencia) elegendő indok lehet programhiba jelentésére, de lehet szándékos tervezési variáció eredménye is. Hét fő inkonzisztenciáról, illetve konzisztenciáról szoktak beszélni 1. Konzisztens a régi eseményekkel A jelenlegi működés hasonló, mint korábban volt 2. Konzisztens az általunk alkotott képpel A program működése egyezésben van azzal a képpel, amelyet a szervezet akar önmagáról közölni 3. Konzisztens a hasonló termékekkel A program működése a hasonló termékek működésével nagyjából megegyezik 4. Konzisztens az igényekkel A program működése megfelel az igényeknek, amelyet az emberek feltehetőleg kívánnak 5. Konzisztens a felhasználók várakozásaival A program működése megfelel annak, amit szerintünk a felhasználók akarnak 6. Konzisztencia a terméken belül A program működése belül konzisztens, tehát a működési minták, a grafikus felület és így tovább értelemszerűen megegyezik egymással a lehetőségek határain belül 7. Konzisztens a céllal A program működése megfelel annak a célnak, amelyre nyilvánvalóan kifejlesztették.