Éves rendszerezés és a tanév munkájának értékelése

Az első tanulási egységben a szoftver környezetét, a hibák lehetséges okait, a tesztelés célját és korlátait vizsgáltuk. Megkülönböztettük az emberi tévedést, a munkatermékben lévő hibát és a felhasználó által tapasztalt meghibásodást. Megértettük, miért nem bizonyítja néhány sikeres futás a teljes hibamentességet, és miért lehet egy hibátlanul megvalósított, de rosszul megválasztott cél is gond.

A hét tesztelési alapelv a munkánkat végigkíséri: tudatosan választunk eseteket, korán kérdezünk, a hibásabb részekre figyelünk, frissítjük a tesztkészletet, és a konkrét felhasználási környezethez igazodunk. A tesztelés eredménye döntési információ, nem pusztán sikeres és sikertelen jelzések gyűjteménye. Ez a szemlélet ad közös alapot az év minden további témájához.

A V-modell segített összekapcsolni a követelményt és a hozzá illő ellenőrzést. Iteratív és agilis munkában a fejlesztés és tesztelés rövidebb körökben is párhuzamosan haladhat, az új inkrementumokhoz új és regressziós esetek készülnek. A tesztelési szintek eltérő fókuszt adnak: különálló komponens, részek kapcsolata, teljes rendszer és az átvevő valódi célja.

A szintet nem a hiba helye és nem a tesztelő munkaköre határozza meg, hanem az, milyen bizonyítékot keresünk. Egy rendszerteszt során talált eltérés végül eredhet egyetlen függvényből; a rendszerteszt mégis a teljes folyamatot vizsgálta. Az elfogadáskor a felhasználói és üzemeltetési cél is számít, beleértve az adatátvitel és helyreállítás feltételeit.

A funkcionális teszt azt vizsgálja, mit tesz a termék; a nem funkcionális azt, milyen minőségben végzi; a strukturális a belső felépítés vizsgálatából indul ki. A szint és a típus két egymást keresztező nézőpont: rendszerszinten is mérhetünk válaszidőt, komponenst is vizsgálhatunk a szabályos kimenetre és a kódágakra. A magas lefedettségi szám elvárt eredmény nélkül nem igazol helyességet.

Változás után megerősítő teszttel az eredeti javított hibát ellenőrizzük, regressziós teszttel a kapcsolódó régi működést. A karbantartási tesztet új szabály, hiba javítása, környezetfrissítés, adatátvitel vagy kivezetés is kiválthatja. A hatáselemzés megmutatja, melyik adatot, kapcsolódó részt és felhasználói folyamatot kell a tesztelésben figyelembe venni.

A statikus vizsgálat a munkaterméket futtatás nélkül ellenőrzi; egy követelmény, terv, kód vagy teszteset ugyanúgy tartalmazhat tisztázandó problémát. A dinamikus teszt a futó rendszer viselkedését figyeli. A korai követelmény-felülvizsgálat megelőzheti, hogy a félreértés továbbmenjen a megvalósításba, de a kész rendszer ellenőrzése ettől továbbra is szükséges.

Egy szervezett felülvizsgálatnak célja, anyaga és verziója van; egyéni átnézés, egyeztetés, javítás és utánkövetés követi egymást. A szerző, felülvizsgáló, moderátor, jegyző és vezető feladata különbözik. Informális áttekintés, szerzői bejárás, technikai felülvizsgálat és inspekció más célhoz illik; ad hoc, ellenőrzőlistás, szerep- vagy forgatókönyv-alapú technika pedig az egyéni vizsgálatot segíti.

A tesztvezetés összehangolja a célokat, résztvevőket, erőforrásokat és döntéseket; a tesztelő a követelményekből, kockázatokból és tényleges működésből gyűjt bizonyítékot. A tesztterv rögzíti a vizsgálat területét és korlátait, megközelítését, becsült ráfordítását, belépési és kilépési feltételeit. Felügyelettel követjük az eredményeket, irányítással a megváltozott helyzetre válaszolunk.

A metrikák nevezővel és környezettel együtt értelmezhetők. A termékkockázat például adatvesztés vagy rossz eredmény; a projektkockázat késő környezet vagy hiányzó erőforrás. A konfigurációmenedzsment összerendeli a build, tesztadat, követelmény és teszteset megfelelő változatát. A hibajegy a megfigyelt tényt és újra előidézhető lépéseket tartalmazza, nem a bizonyítatlan okot. Ezek a témák egy döntési lánc elemei: mit vizsgálunk, hogyan tudjuk az eredményt értelmezni, és milyen lépés következik belőle.

Az eszközök támogathatják a tervezést és nyomon követést, a statikus elemzést, a tesztesetek és adatok kialakítását, a végrehajtást, naplózást, teljesítményvizsgálatot és megfigyelést. Az automatizálás ismételhető munkát gyorsíthat, de az eszköz nem dönt helyettünk az elvárásról. A zöld szkript csak akkor hasznos, ha releváns végállapotot ellenőriz a helyes konfigurációban.

Az eszközhasználat előnye mellé oda kell tenni a karbantartás, képzés, instabil jelzések és elavult esetek kockázatát. Szervezeti bevezetéskor valós problémából és mérhető célból indulunk, próbaprojektet futtatunk, majd a bizonyíték alapján döntünk a kiterjesztésről. A szakmai gondolkodás, az együttműködés és a felhasználói cél megértése mindvégig emberi feladat marad.

Az év során az egyszerű „működik-e?” kérdésből több pontos kérdés lett: kinek az igénye szerint, milyen állapotban és verzión, milyen módszerrel, milyen kockázat mellett, és mit bizonyít a megfigyelt eredmény? A tesztelési szemlélet fejlődése abban látszik, hogy a tényt el tudod választani a feltételezett októl, az elvárást konkrétan meg tudod fogalmazni, és a megfigyelést döntéshez használhatóan közlöd.

Ez az oldal fogalmi összefoglaló és visszatekintő útmutató: összekapcsolja a 2–35. órák leckéit, és megmutatja, hol érdemes egy bizonytalan fogalomnak utánanézni. Nem tartalmaz gyakorló feladatokat vagy automatikus pontozást.

Ha a hiba, tévedés és meghibásodás fogalma keveredik, a 2–7. órákat nézd át. A fejlesztési modell és a tesztelési szint kapcsolata a 9–14. óránál található; a funkcionális és nem funkcionális tesztek a 15. órában, a karbantartás a 17. órában. A statikus vizsgálat és a felülvizsgálat folyamata a 19–21. órában épül fel.

A tesztterv, becslés, jelentés, konfiguráció, kockázat és hibajegy a 23–29. órákból kereshető vissza. Az eszközök típusát és bevezetését a 31–34. órák tárgyalják. A 8., 18., 22., 30. és 35. órák felkészülési összefoglalók; itt a kapcsolatok újranézhetők. A jelenlegi, 36. óra az éves munka lezárása, ezért nem tartalmaz új feladatokat vagy pontozást.