Összefoglalás és gyakorlás a számonkéréshez

A szoftver nem elszigetelten működik. Az eredményt a program, a bemenet, a böngésző, a hálózat, az adatbázis és a kapcsolódó szolgáltatások együtt alakítják. Hibát már a követelményben és a tervben is találhatunk, nem csak a kész kódban. A tesztelés a fontos kockázatokat tárja fel: azt vizsgálja, hogy a rendszer a meghatározott helyzetekben hogyan működik, és milyen eltérés maradhat rejtve.

A tesztelés fejlesztés, karbantartás és működtetés közben is szerepet kap. Módosításkor ellenőrizzük az új viselkedést, és azt is, hogy a korábban működő részek nem romlottak-e el. A minőség megítéléséhez a sikeres tesztek száma kevés: figyelnünk kell a fontos felhasználói folyamatokra, a nyitott súlyos hibákra és a fennmaradó kockázatra. A 'mennyi tesztelés elég?' kérdésre a célhoz igazodó, indokolt döntés a válasz.

A tesztelés a szoftverhez kapcsolódó munkatermékek vizsgálata és értékelése. Vizsgálhatunk követelményt vagy tervet futtatás nélkül (statikus vizsgálat), illetve működő alkalmazást meghatározott bemenetekkel (dinamikus tesztelés). A teszt esetén előre rögzítjük a feltételeket és az elvárt eredményt, majd a tényleges eredményt ehhez hasonlítjuk. A tesztelés nem azonos a program véletlenszerű kattintgatásával vagy a talált hiba kijavításával.

A cél lehet hibák feltárása, a követelmények teljesülésének ellenőrzése, a kockázat csökkentése és a döntéshozók tájékoztatása. A forgalmi vizsga hasonlata segít: ott is meghatározott körülményeket és szabályokat vetünk össze a megfigyelt viselkedéssel. A hasonlatnak határa van; egy sikeres vizsga vagy teszt sem bizonyítja minden későbbi helyzet hibátlan kezelését.

A minőségbiztosítás a munkafolyamatok javítására és a hibák megelőzésére összpontosít; a tesztelés a konkrét termékről és munkatermékekről ad visszajelzést. Például az egyértelmű követelményekhez bevezetett ellenőrzőlista megelőző intézkedés. Egy konkrét űrlap 18 éveseket elutasító tesztje ezzel szemben termékszintű eltérést tár fel. Az eredmény mindkét területet segíti: a hibát ki lehet javítani, és a visszatérő kiváltó okot is kezelni lehet.

A lánc tagjai különbözőek. Kiváltó ok lehet az egyértelműtlen szabály; emiatt egy ember tévedhet; a tervben vagy a kódban hiba maradhat; végül bizonyos feltételek mellett a felhasználó meghibásodást tapasztal. Nem minden hiba okoz látható meghibásodást minden futásban. A hibajegyben először a megfigyelt tényt és a reprodukálás lépéseit rögzítsd, a feltételezett okot külön jelöld.

Ha egy rendszerrészben több hibát találunk, azt érdemes alaposabban vizsgálni: új adatokkal, állapotokkal és környezetekkel. A hibák eloszlása közben változhat, mert a termék is változik. A régi tesztkészletet ezért frissíteni kell, ugyanakkor a hasznos regressziós tesztek megmaradnak. A tesztelés megmutatja az eltérést; a hibakeresés az okot azonosítja és javítja; a megerősítő és regressziós teszt utána ismét bizonyítékot ad.

A zöld tesztekből csak a vizsgált esetekre vonatkozó következtetés adódik. A felhasználó még a hibátlanul megvalósított követelményeket is elutasíthatja, ha azok nem oldják meg a valódi problémáját. A teszttervezésnél ezért egyszerre kérdezzük: hol lehet hiba, és valóban a megfelelő célokat ellenőrizzük-e?

A tesztelés kimutathat hibát, de hibamentességet nem bizonyít; minden lehetséges eset kipróbálása általában lehetetlen. A korai ellenőrzés megelőzheti a hibák továbbterjedését, és a hibák gyakran egyes részekben sűrűsödnek. Ha sokszor ugyanazokat a teszteket futtatjuk, az új hibák feltárásához friss esetekre lehet szükség. A megfelelő tesztelési mód a környezettől függ, és a megtalált hibák hiánya nem bizonyítja, hogy a felhasználó számára hasznos a termék.

Számonkéréskor ne pusztán a hét mondatot sorold fel. Ismerd fel az alapelvet egy rövid helyzetleírásból, majd magyarázd el, mit tennél másként a teszttervben. Például az új jogosultsági szabályra írt új esetek a tesztkészlet megújításához kapcsolódnak; a korábban sok hibát adó modul újravizsgálata a hibák csoportosulásához. Egy helyzethez több alapelv is tartozhat, ha mindegyiket külön meg tudod indokolni.

Ha fogalmat kérdeznek, először nevezd meg, majd egy konkrét példában mutasd meg a szerepét. Az 'emberi tévedés', a 'munkatermékben lévő hiba' és a 'megfigyelt meghibásodás' nem felcserélhető. Ha tesztesetet írsz, add meg a kiinduló állapotot, a bemenetet, a lépést és az elvárt eredményt. Ha alapelvet kérdeznek, az elnevezés mellett írd le, milyen tesztelői döntés következik belőle.

Egy jó kifejtős válasz nem attól hosszú, hogy sok kifejezést sorol fel. Attól ellenőrizhető, hogy a helyzet megfigyelhető tényéből indul ki, megkülönbözteti a biztos és a feltételezett állítást, és kimondja a következő vizsgálati lépést. A mintamegoldás egy lehetséges jó megközelítés; más, megfelelően indokolt megoldás is elfogadható lehet.

Ha az emberi tévedést, programhibát és meghibásodást kevered, ismételd a 2. és 5. órát. Ha a tesztelés céljai, a statikus és dinamikus vizsgálat, illetve a forgalmi vizsga hasonlata nem világos, a 4. órához térj vissza. Ha a tesztelés 'elegendő' mértékét kizárólag százalékban fejeznéd ki, olvasd át a 3. óra kockázati példáit.

Ha nem tudod elkülöníteni a tesztelést a hibakereséstől vagy a megerősítő tesztet a regresszióstól, a 6. óra példái segítenek. Ha a hét alapelv közül csak a nevet ismered, nyisd meg a 7. órát, és minden alapelvhez írj saját ellenpéldát is. A feladatsor csoportjai mellett közvetlen hivatkozást találsz a kapcsolódó leckékhez.