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ó