Számítógépes tesztek, legjobb gyakorlatok

Bármely informatikai fejlesztés lényeges lépése, a tesztfázis célja annak ellenőrzése, hogy a teljesítés megfelel-e a felhasználó által kifejezett igényeknek. Különös figyelmet kell fordítani annak biztosítására, hogy a rendelkezésre álló eszköz használható, könnyen, fenntartható módon, hibák nélkül, és elfogadható válaszidő alatt elkészítse azt, amire készült. Bár hasznossága elengedhetetlen, a tesztelési fázist sajnos gyakran túszul ejtik a projekt által felhalmozott késések, és ez a határidők betartására szolgáló beállítási változó. A gyakorlatban tehát nem arról lesz szó, hogy a rendszer minden esetben megfelelően működik, hanem annak észleléséről, hogy egy adott elem bizonyos körülmények között nem a várt módon működik. A lehetséges tesztek fő típusainak és fázisainak áttekintése után a második részt a bevált gyakorlatok megosztására fordítjuk, hogy a lehető leghatékonyabban kivitelezhessük ezt a hibajavadást.

Egy kis kitérő az elméleten keresztül

Először meg kell különböztetni a tesztszintek és a típusú vizsgálatok. A lehetőségek területére támaszkodva már megkapjuk az elemeket a tesztek megfelelő felépítésére és azok teljességének biztosítására, a projekt kontextusától függően.

A tesztelés négy fő szintje törölhető:

  • Egységvizsgálatok: célja egy adott kódrész működésének ellenőrzése egymástól függetlenül. Ezért potenciálisan azonosíthatunk egy hibát egy adott helyen.
  • Integrációs tesztek: Miután elvégezték az egység teszteket, ez magában foglalja a rendszer egészének tesztelését, vagyis az összes elem integrálásával. Két változat lehetséges, komponensenként, vagy "nagy durranás" módban.
  • Rendszertesztek: ennek a szakasznak a célja annak ellenőrzése, hogy a fejlesztés elméletben, de a felhasználó által adott kontextusban is megfelelően működik-e.
  • Elfogadási tesztek akik különböző projektcsoportok (MOE => MOA) közötti fejlesztést akarják érvényesíteni, majd a felhasználókkal.

Ezen a különböző szinteken belül vannak a különböző típusú vizsgálatok. Idézhetjük a leggyakoribbakat:

És a gyakorlatban mit ad ?

Stratégia és tesztterv szükségessége a fejlesztési fázistól kezdve

Ideális esetben a funkcionális teszteseteket a specifikációknak megfelelően kell elkészítenünk. Ez lehetővé teszi például erősítse meg a felhasználó által elvárt viselkedést reflektálva a több lehetséges esetre. A tesztesetek a specifikációk szemléltetésére is használhatók, példákkal szolgálva, amelyek hasznosak mind a fejlesztő, mind a felhasználó számára. Mivel a hibák jelentős részét félreértések okozzák (Felhasználók/MOA vagy MOA/MOE), helytelen lenne az első fázisban nem a jó kommunikációt támogatni.

Még inkább, számszerűsített tesztek lehetővé teszik a szélsőséges vagy határesetek azonosítását. Ha egy számításhoz például a végrehajtási árra van szükség, mi van, ha negatív? Biztosítsak védőkorlátot, ha megszívja? Így elkerülhetjük a kérdések feltevésének kockázatát a következő fázisokban, ahol a hibák kijavításának költségei magasabbak lehetnek (különösen az V-ciklus kezelésében, kevésbé az agilisban).

Ebben az értelemben az úgynevezett „folyamatos tesztelési” módszerek (Test Driven Development, Behavior Driven Development), amelyek a kódolást és az automatikus teszteket egyaránt ötvözik az építési folyamatban, nagy előnyt nyújtanak: a hibák azonnali észlelése a műszaki és funkcionális részek egyidejű tesztelésével. Az idő megtakarított, az idő pedig pénz.

A tervezés fontossága

Van értelme a tesztfázisokat kettős szempont szerint koordinálni: a csökkentés és költségvetés-tervezés a különböző tesztek egyrészt az erőforrás-tervezés.

A különböző tesztfázisok átfedik egymást, így nem mehetünk el egy szakaszba anélkül, hogy az előzőt validáltuk volna, ez magától értetődik. Nincs end-to-end teszt a füstvizsgálatok előtt, - kiáltotta La Palice marsall! Pontosabban, különös figyelmet kell azonban fordítani a vizsgálatok sorrendjére, valamint azok időtartamára. Mennyire nehéz egy feladat, olyan nehéz a terhelés becslése, az egyes projektekre jellemzően. Előre nem látható esemény, amelyet soha nem lehet kizárni, a probléma felismerése időnként sok más, számtalan és komolyabban kijavítandó probléma megjelenéséhez vezethet. A kis poloskából aztán hirtelen hangyaboly válik, ahol sok más kis vadállat vár csendesen, az árnyékban kuporogva, készen arra, hogy előbújjon, amint felfedezik egyiküket. Annak elkerülése érdekében, hogy a következő fázisokra és a gyártási dátumra gyakorolt ​​hatások elkerülhetők legyenek, erősen ajánlott 10% körüli tartalékot adni magának a teljes várható terhelésről, csak azért, hogy kényelmesen érje magát egy váratlan elem előfordulása esetén.