Szoftvert fejlesztünk vagy hibákat javítunk?

Szoftvert fejlesztünk vagy hibákat javítunk?

Egy – sajnos - nagyon széles körben elterjedt antipatternről szeretnék ma írni. Szoftverfejlesztési szerződésekben szokott lenni egy rész, ami a szoftver elfogadását definiálja – azaz mikor mondható az, hogy a szoftver kész, lehet küldeni a számlát, és mindenki elmegy jól megérdemelt nyaralására a Bahamákra.

Tipikusan ezek a bekezdések a hibák számával definiálják a minőséget. Itt van például ez a szerződés, tessék megnézni a 2. oldal 12-es pontot:

Az elfogadási teszt akkor sikeres, ha a tesztelés során kritikus hiba nem merül fel, és a súlyos (de a rendszer működését alapvetően nem gátló) hibák száma nem haladja meg a 3 darabot, valamint a kis hibák száma a 10 darabot.

Első ránézésre jónak tűnik, mi ezzel a baj?

Hát az, hogy tönkreteszi a projektet, több módon is:

1) Értelmetlen teniszezés: A stabilizációs fázis stabilizálása cikkben már említettem, hogy amikor átadjuk a szoftvert, akkor az ügyfél és a beszállító teniszezni kezd: az ügyfél megnézi a szoftvert, talál benne egy csomó hibát, visszadobja, a programozók kijavítják a hibákat és küldenek egy új verziót, amit az ügyfél újra megnéz, talál benne egy csomó hibát, visszadobja… és ez megy a végtelenségig. Közben mindenki egyre idegesebb lesz, újabb és újabb határidők dőlnek meg, a vezetőség egyre hangosabban kiabál, a beosztottak stresszelnek, egymást követik az értelmetlen meeting-ek.

2) Az ügyfél és a beszállító ellenséggé válnak: A szoftverfejlesztés csak úgy tud működni, ha az ügyfél és a beszállító is közösen dolgozik a közös cél érdekében. Viszont ha az elfogadást a hibák számához kötjük, akkor a közös célból hirtelen ellentétes cél lesz: az egyik fél minél több hibát akar megtalálni, a másik minél kevesebbet. Megbomlik az együttműködés.

3) Mikor lesz valóban kész a szoftver? A szoftver akkor van valóban kész, ha teljesíti az eredeti célt. Például egy értékesítési szoftver akkor kész, ha lehet vele értékesíteni. Ez teljesen független dolog attól, hány és milyen hiba van benne. A szoftvert akkor kellene elfogadni, amikor a célját ellátja. Ezt igazából jól megtervezett teszt esetekkel lehet ellenőrizni.

4) Az ügyfél felelőtlensége: Az elfogadási teszt fenti definíciója azt sugallja, hogy az ügyfélnek nincs feladata és felelőssége az elfogadási teszt során, az teljes mértékben a beszállító ellenőrzése. Márpedig ennek az ellenkezője igaz: ahhoz, hogy az ügyféle valóban meggyőződhessen a szoftver megfelelőségéről, ahhoz sokat kell dolgoznia. Megfelelő teszt esetekkel készíteni, kompetens szakértőket hoznia, teszt környezetet előállítani, és azokat a teszt eseteket valakinek végre is kell hajtani. Ez munka, sok munka. Ha az ügyfél nem így tesz, akkor nem fog tudni meggyőződni a szoftver „jóságáról”.

5) Pánik: Talán meglepő lesz, de ha a minőséget a hibák számával definiáljuk, akkor az pánikot okoz. Ugyanis az teljesen normális, hogy egy szoftver az átadás előtt még tele van hibával. Az átadás előtti időszak stabilizációval telik, nagyon intenzív hibajavítás. Egy kezdeti szoftververzió – ahol már a funkciók megvannak, csak nem stabil - sok súlyos hibát tartalmaz. Ezen megijedni annyira jogos, mint azon, hogy este lemegy a nap és sötét lesz. Az ügyfél viszont tipikusan nem IT-s, ők megijednek attól ha kiderül, hogy van még 10 súlyos hiba a szoftverben. Pedig ez lényegtelen, hiszen az átadásra majd ki lesznek javítva. Az efféle információk csak arra jók, hogy mindenki jól megijed. Főleg a felsővezetés.

6) Hibamentes szoftver nincs: Klasszikus IT-s mondás, és igaz. Bármilyen tetszőleges szoftverben van hiba, legfeljebb nem tudunk róla, vagy nem volt elég időnk tesztelni, hogy megtaláljuk. Ilyen értelemben a 3 súlyos hiba relatív: ha akarom, keresek a szoftverben 3 súlyos hibát, ha akarom, akkor nem keresek és elfogadom.

7) Nem objektív: Hiába tűnik objektívnak a definíció, valójában objektív. Ahogyan az előbb írtam, a 3 súlyos hiba relatív. Ha az ügyfél akarja, addig keres hibákat, amíg talál. És az is előbb-utóbb szubjektív lesz, hogy mi a súlyos hiba. (pl súlyos hiba-e, ha a nyitóképernyő nem követi a cég vizuális megjelenését?) És innentől kezdve csak a jóindulatán múlik, hogy a szoftvert átveszi-e vagy sem.

Hogyan lehet ezt jól csinálni?

A megrendelő kötelezettségei közé fel kell venni a tesztesetek készítését. A szoftver minőségét a tesztek lefutásához kötni. Az elfogadási kritérium az legyen, hogy a tesztesetek hiba nélkül végrehajthatóak legyenek, vagy legalábbis bizonyos mennyiségű hibával (pl. fontos tesztek súlyos hiba nélkül, a nem fontosak közül max 3 lehet failed).

Most valaki mondhatja azt, hogy ha egy teszt eset nem hajtható végre, az ott súlyos hiba, tehát a két definíció ugyanaz: a szoftver akkor fogadható el, ha nincsenek benne hibák.

Ez a gyakorlatban nagyon nem igaz! És csak amatőrök gondolhatják azt, hogy ugyanaz!

A legfőbb különbség a két definíció között az, hogy a tesztgyűjtemény objektívan leírja, mit várunk el a szoftvertől, miközben hiba bármi lehet. Ha a szoftverrel kapcsolatos elvárások megfoghatóak, akkor azoknak sok munka árán eleget lehet tenni. Nem fog előfordulni, hogy a programozó kijavítja az összes megtalált hibát, mire az ügyfél küld egy új hibalistát.

A másik nagy különbség, hogy az ügyfél rá van kényszerítve az elfogadási teszt előkészítésére, és ezáltal arra, hogy átgondolja az elvárásait és formalizálja azokat. Lesz egy közös nevező (a teszteset gyűjtemény), ami alapján mind a két oldal tud dolgozni. A közös nevező közös munkát és együttműködést eredményez.

A harmadik érv pedig az, hogy míg a hibák száma egy aktuális információ és relatív, addig a sikeresen lefutott tesztesetek száma pontosabban megmondja, milyen messze vagyunk a kész szoftvertől. Például ha 100 tesztesetből 90 lefutott és 10 nem, akkor tudjuk, hogy azzal a 10-zel kell valamit csinálni, de amúgy közel vagyunk a célhoz. De ha a szoftverről azt tudjuk, hogy 30 hibát találtak benne, akkor most az messze van-e a késztől vagy közel?

Ha a végén a megrendelő a hibák ellenére is átveszi a szoftvert, akkor pontosan tudni fogja, hol kell megalkudnia és mi az, amit a szoftver biztosan tudni fog.

Miért írnak ilyen szerződéseket, ha ez ennyire rossz?

Mert kicsiben még működik. Amíg a szoftver kicsi és egy ember átlátja, addig nincs feltétlenül szükség tesztesetekre és addig elég jól lehet dolgozni a hibaszámmal. És mert a hibákon lehet vitatkozni – meggyőzni az ügyfelet, hogy az úgy jó. Az ügyfél is inkább a hibák számával definiálja a minőséget, hiszen így nem kell teszteseteket készítenie.

Az ügyvédek is örülnek ennek a definíciónak, hiszen könnyen leírható és könnyen számonkérhető. Ha fel akarunk mondani egy beszállítónak, elég lesz 4 súlyos hibát összegyűjteni.

Egy gondolat a végére: itt gyakorlatilag szemléletmódról van szó. Ha hibákat számolunk és hibajavítások után futunk, akkor a jelenre összpontosítunk és csak reagálunk az eseményekre. Ha tesztesetek, használati esetek alapján mérünk, akkor ott a specifikáció kerül fókuszba és a végső elfogadásra készülünk fel, tehát  jövőre összpontosítunk a jelen helyett. Reaktív helyett proaktív hozzáállás.