Hibátlan szoftver: álom vagy valóság? 

Olvasási idő: 3 perc

Adattárház tesztelés, ahogy a projektvezető látja.

Kezdő projektvezetőként még felháborodtam, amikor láttam, hogy „hibás szoftvereket” árulnak a piacon. Még a világ vezető cégeinek termékeiben is vannak hibák: szövegszerkesztőkben, táblázatkezelőkben, fejlesztő eszközökben, nem is beszélve az ERP rendszerekről.

Az évek alatt szembesültem csak azzal a ténnyel, hogy hibátlan szoftver nem létezik: a sok funkció letesztelése, azok különböző együttállásának vizsgálata praktikusan végtelen hosszú ideig tartana és végtelen erőforrásokat égetne el. Ezért a szoftverfejlesztés egyfajta kompromisszumkeresést is jelent.

Az utóbbi években adattárház fejlesztéseken dolgoztam, ahol a tesztelésről alkotott képem kiegészült azzal, hogy a funkciók megfelelő együttállásához még hozzáadhatom – vagy akár fel is szorozhatom – az adatok együttállását, amiből még sokkal több van. És természetesen a tesztelést itt is korlátozott büdzséből kell megvalósítani.

Projektvezetőként fontosnak tartom az adattárház megoldások esetén is, hogy 

  • ismerjük el, hogy a tesztelésre limitált erőforrás / idő / pénz áll rendelkezésre,
  • az ügyfél és a szállító is tudja, hogy az átvett / átadott program tartalmazhat hibás működést, az ezzel kapcsolatos kompromisszumot közösen alakítsák ki,
  • az átadás után mind a vevő, mind a szállító elégedett legyen, tehát ne legyen “vesztese” az átadási folyamatnak.

A Hiflylabs gyakorlatában bevált legjobb megoldás erre az elvárt értékek mentén történő tesztelés. Ilyenkor egy-egy példára előre ki kell számolni, hogy milyen kimentetet adjon az adattárházas számítás és a lefejlesztett eszköz eredményeit majd ezen tesztesetekhez hasonlítani. 

Ennek a módszernek számos előnye van:

  • a projekt scope-ja a tesztesetek kidolgozása során véglegesedik, mert az üzleti felhasználónak tényleg végig kell gondolnia, számolnia, hogy a specifikációban leírtakat hogyan kell megvalósítani üzletileg.
  • a félreértések száma jelentősen csökken, mert a specifikáció pontos értelmezése üzleti emberekre és nem IT-s elemzőkre / fejlesztőkre hárul.
  • a programozásba fektetett idő kevesebb, mert az ügyfeleket arra kérjük, hogy a teszteseteket és elvárt értékeket a programozás megkezdésére állítsák elő, mialatt mi a rendszer architekturális kérdéseit tervezzük. Fejlesztőink nem a specifikáció értelmezésére, egyeztetésére, hanem a programozásra fókuszálhatnak. A tesztesetekkel kapcsolatban is felmerülhetnek kérdések, de azok egyeztetése sokkal kevesebb idő. Ha kiderül, hogy nem jó a teszteset, vagy hibás az elvárt érték, akkor elég, ha azt javítjuk, és nem kell a már megírt programot módosítani.
  • az végső üzleti tesztelőknek átadáskor nem kell nyilvánvaló hibákkal bajlódnia, mert a fejlesztők sokkal könnyebben ellenőrizhetik magukat, így a fejlesztői tesztelés minősége ugrásszerűen jobb lesz és sokkal kevesebb tesztelési iterációra lesz szükség a vevő és a szállító között. 
  • a tesztelés sokkal gyorsabban, tervezhető erőforrás felhasználással zajlik, mert a folyamat során az ügyfeleknek azt kell ellenőrizni, hogy a riportban / dashboard-on / adatbázisban azok a számok jelennek-e meg, amiket ők elvártak. 
  • jól definiálható, hogy mikor van vége a projektnek! A tesztesetek szerinti működést és az elvárt eredményeket produkáló rendszer szállítása egyben az átvétel feltétele is, a terméket az ügyfél átveszi, és a projekt „határidőre” befejezhető. 

A módszer legnagyobb árnyoldala, hogy energiaigényes feladat a teszteseteket teljeskörűen összeállítani és meghatározni hozzájuk az elvárt értéket. Azonban az csak illúzió, hogy ez a munka megspórolható volna — épp ellenkezőleg: ha nem végezzük el strukturáltan, előre, akkor a tesztelés során, határidőnyomás alatt kell majd megcsinálni. Ez pedig rosszabbul tervezhető és összességében több munkát eredményez éppen akkor, amikor már mindenki nagyon várja a projekt eredményét.

Természetesen előfordulhat, hogy a rendszerben ilyen körültekintő tesztelés után is maradnak hibák. Ha ilyen kiderül, azt a specifikációnak megfelelően garancia keretében lehet javítani. De abban legalább biztosak lehetünk, hogy tesztesetekben megfogalmazott leggyakoribb vagy legfontosabb esetekben a rendszer megfelelően működik.

Végezetül álljon itt egy tanulságos példa. Az egyik ügyfelünknél a törvényi változás miatt kellett egy igen összetett számítást elvégezni, ahol a törvény értelmezése nem volt egyértelmű. Azt a megoldást találtuk ki közösen, hogy egy Excel táblában kézzel végigszámítunk néhány jellemző esetet. 

    • az ügyfél megadta a teszteseteket, azt, hogy milyen esetekre kell felkészíteni a programot 
    • mi előállítottuk az egyes tesztesetek számításhoz rendelkezésre álló és az adott esetet jellemző bemeneti adatokat 
    • az ügyfél meghatározta a törvény értelmezése és belső üzleti döntések alapján a kimeneti adatokat 

Az érdekesség, hogy a teljes adatállományra futtatott számok végeredménye üzletileg „nem tetszett” az ügyfélnek, pedig tudták, hogy a számítás helyes. Átvették a projekt által leszállított terméket, majd kicsit másképpen értelmezték a törvényi kiírást, változtattak az Excel-ek számítási módján és megrendelték a módosítást az adattárházban is.

A hibamentes szoftver továbbra is csak álom. Viszont az elvárt esetekre alapozó tesztelés segítségével megvalósítható, hogy a fejlesztési erőforrásokat a lehető legjobban az üzleti felhasználók számára hasznos számítások kidolgozására fordítsuk. 

Így lehet legalább az üzletileg hasznos szoftver álom helyett valóság.

Tüske Zsolt – Projektigazgató

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöljük.