Működő szoftver = megfelelő szoftver. Vagy mégsem? 

A matematika definíciója szerint egy szoftver működik, ha azt csinálja, amit kell és nem csinál olyat, amit nem kell. Tapasztalataink alapján azonban az üzleti életben mindez nem elegendő egy üzletileg valóban hasznos szoftvertermék előállításához. Hisz önmagában a működéssel nem, de legalábbis optimálisan nem valósíthatóak meg egy szoftverrel szemben támasztott üzleti igények.  

A modern szoftverfejlesztés világában, a technológiai megoldások komplexebbé válásával a szoftverminőség biztosításának (Quality Assurance, QA) szerepe is egyre kritikusabbá válik. Az up-to-date szoftver ugyanis – legyen szó akár egy belső használatú ügyviteli rendszerről vagy egy márkaidentitást támogató mobil alkalmazásról – több, mint egy funkcionálisan működő program: egy szoftvertermék. Így, a funkcionalitáson túl számos egyéb metrikának kell megfelelnie.

Ezek közül néhány a teljesség igénye nélkül:

• Megbízhatóság: a szoftver az elvárt módon és időben a felhasználók rendelkezésére áll. Az esetleges hibákat a lehető legjobban kezeli: a felhasználói interakciókra visszavezethető hibák esetén támpontot ad a felhasználónak a továbblépéshez, a rendszerszintű hibák esetén pedig a lehető legkisebbre van korlátozva a hiba által okozott szolgáltatás-kiesés. 

• Performancia: a szoftver képes arra, hogy elvárt számú felhasználót üzletileg meghatározott válaszidőkkel, minimalizált felhasználói interakcióval végig vezessen bizonyos üzleti folyamatokon. 

• Adat- és információ biztonság: a rendszerben tárolt adatok védve vannak a külső, ártó szándékú hozzáférésektől; az információkhoz csak az engedélyezett felhasználók férnek hozzá, azokat csak a meghatározott felhasználói kör módosíthatja. 

• Skálázhatóság: a rendszer ellenálló a tervezhető impulzív terhelésekkel szemben, tehát az elvárt performanciáját ilyen esetben sem veszíti el (pl. hó eleji számlafizetés egy szolgáltatónál).  Egy jól skálázható rendszer a megnövekedett kapacitás szükséglet okozta többletköltséget a csúcsterhelés idejére korlátozza és nem 24/7 tartja fenn, ezzel biztosítva az adaptivitást. 

• Karbantarthatóság: a rendszerhibák hatékonyan detektálhatóak, felderíthetőek, javíthatóak. 

Ha azonban mindezeket figyelmen kívül hagyjuk, gyakorlatilag hiába működik jól a szoftverünk, nem fogja azt az eredményt produkálni, amit elvárunk tőle.   

A felsorolt szempontok teljesüléséhez úgy kell megvalósítanunk a szoftvert, hogy a fenti metrikákat mindig szem előtt tartjuk. Már a tervezés első pillanatában ki kell tűzni az ezzel kapcsolatos célokat, majd ezt követően ezek mentén kell dolgozni. 

1. Megfelelő tervezés: architektúra és folyamatmodellezés 

Fontos, hogy olyan tervet készítsünk, amely nemcsak figyelembe veszi a megtérülést, de számol a szoftverrendszer természetes avulásával is (pl. technológiai frissítések lekövetése) és finom-hangolásával (például változó jogszabályi követelmények lekövetése).  

Lehetőségeinkhez mérten a lehető legnagyobb körültekintéssel mérjük fel, hogy a jövőbeli üzleti folyamatok változásai, és a vállalati stratégiából következő újabb üzleti igények milyen várható továbbfejlesztési szükségleteket fognak generálni.  

Az MVP (Minimal Viable Product) szemlélet alkalmazásával a szoftverrendszer magját képező funkcióhalmazt és technológiai alapokat úgy alakítjuk ki, hogy az csak az elengedhetetlenül szükséges elemeket tartalmazza. Így lerövidítjük az első fejlesztési ciklust és gyorsabban produkcióba állíthatjuk a már működő terméket.  

Ezt követik az első ciklusban kimaradt funkciók, illetve az MVP verzió használat során gyűjtött valós tapasztalatokat ötvözve, az üzleti hasznosság maximalizálását szem előtt tartva határozzuk meg a továbbfejlesztési iterációkat. Az iterációk idő- vagy tartalom alapú becslésével előre jelezhetőek a várható továbbfejlesztési költségek, így a bekerülés-megtérülés számításunk korrekt lesz. 

2. Üzleti igényeknek megfelelő technológiai eszköztár / technológiai stack kiválasztása. 

A technológiai stacket a fenti terveknek és a vállalat technológiai stratégiájának megfelelően határozzuk meg. Fontos szempont, hogy a meglevő környezetbe illeszkedjen, legyen költséghatékony, legyen rá megfelelő tudás, valamint skálázható legyen – tehát tudjunk rá építkezni és megfeleljen a vállalat középtávú növekedési vagy fejlesztési céljainak. Figyeljünk arra, hogy olyan software architektúrát alakítsunk ki, amely a céljainkat legjobban szolgálja, ne engedjünk az aktuális trendek csábításának (pl. a microservice architektúra igen népszerű mostanában, azonban nem minden problémára optimális megoldás). Modern, biztonságos és compliant (pl. ha a tárolt adatokat nem vihetem ki az EU határain, akkor a statisztikákra nem használhatom a Google Analytics-et mert a szerverei az USA-ban vannak, hanem egy lokálisan futtathatót választok) 

3. DevOps – a hatékony életciklus menedzsmentért 

A DevOps szemléletmód fókuszában az együttműködés áll – a fejlesztők és az operatív megvalósítók közötti folyamatos kapcsolattartás. Célja, hogy gyorsan és rugalmasan tudjunk minőségi rendszereket fejleszteni. Alkalmazásával a csapatok hatékonyabban tudnak a kitűzött célokhoz és a változó üzleti igényekhez igazodni. 

Legfőbb jellemzői:

• A független fejlesztő csapat és a független üzemeltető csapat között nincs hand over => nincs átadási költség és kockázat (félreértések, idő, extra dokumentációk, felelősséghárítás) 

• Az üzemeltető csapatnak nem kell betanulással a fejlesztések után “loholnia” => költségcsökkentés, kockázatcsökkentés 

• A fejlesztőcsapat jobban érti a terméket, megfelelőbb megoldásokon dolgozik. Nem csak egy specifikációnak megfelelő szoftvert szállítanak, hanem értik a szoftver üzemi környezetét, üzleti célját és működési sajátosságait. 

• A csapattagok kompetencia területtől függetlenül elkötelezettek a szoftvertermék iránt, mert átfogó képük van a célokról és a megoldási lehetőségekről. 

• Nincs szükség külön L2 és L3 supportra => hatékonyabb hibafelderítés és elhárítás 

• Kevesebb admin felület szükséges, mert a konfigurációt az üzemeltető csapat el tudja végezni => költségmegtakarítás, komplexitás csökkentés 

4. Automatizáció, tesztelés, monitoring 

A generálható és ismétlődő feladatok automatával történő kiváltásával értékes emberi erőforrás szabadul fel, mely más, újabb feladatokon használható, a fejlesztési folyamat gyorsabb, a time-to-market rövidebb lesz. Egységnyi idő alatt tehát több értéket teremtünk. 

Hogyan működik mindez a gyakorlatban?

– A projekt környezet és a fejlesztendő szoftvertermék karakterisztikája alapján meghatározzuk a tesztelendő egységeket és osztályozzuk a teszteket – elkülönítve a funkcionalitásra, stabilitásra és a regresszióra használt teszteket.  

– Kialakítunk egy olyan teszt katalógust, amellyel a tesztesetek és teszt futtatások költséghatékonyan adminisztrálhatóak és naprakészen tarthatóak. 

– A tesztelési módszertan – és a tesztelést támogató eszközök kiválasztásakor figyelembe vesszük a projekt platform sajátosságait, illetve az üzleti domain specifikus szükségleteket. 

– Automatizáljuk a tesztelést és biztosítjuk a magas fokú újra felhasználhatóságot.  

– A regressziós tesztek egy részét periodikusan futtatjuk a produkciós környezeten, a futtatási eredményeket pedig becsatornázzuk a logolási és monitorozási keretrendszerekbe. Így a produkciós rendszer megfelelő működése folyamatosan ellenőrizhető, az esetleges hibák gyorsan detektálhatóak. 

A fent felsorolt eszközök csak akkor hozzák az elvárt üzleti hasznot, ha hatékonyan beépítjük őket a szoftverfejlesztési projekt munkamenetébe és a DevOps team hétköznapjaiba. 

Ezért,

1. A teszt automatizálási, -fejlesztési, -futtatási és verifikálási feladatokat már a tervezés fázisában vegyük figyelembe és allokáljunk rá erőforrást. 

2. A fejlesztés során válasszunk olyan módszertant, amely az adott szoftver termék és a rendelkezésre álló projekt csapat számára a lehető leghatékonyabban biztosítja a teszt menedzsmentet.  

3. Folyamatainkba építsük be az automata tesztek futtatását és az eredmények kiértékelését. Ideális esetben a CI / CD folyamatba akár automatikus döntéshozatal is beépíthető, amely a kitelepített szoftver nem megfelelő minősége esetén automatikusan és beavatkozás nélkül visszavonja a kitelepítést. 

4. Bátran használjuk automata tesztjeinket a produkciós környezet üzemeltetésére! Az éles rendszerek esetén az automata tesztek ismételt futtatása és a hiba esetekre épített riasztási logika által egy hatékony monitoring valósítható meg, mely lehetővé teszi az éles rendszerben bekövetkező hibák gyors detektálását és kezelését. 

A felsorolt eszközökkel hatékonyan csökkenthetjük az esetleges adat hibák, hibás viselkedések okozta károkat, és minimalizálhatjuk rendszerünk leállási idejét. A szoftverminőség biztosításhoz használt eszközök és megoldások eredményesen építhetők be a projektmenedzsmentbe, mivel az automatizált ellenőrzéseknek és riportoknak köszönhetően valós képet kaphatunk a szoftverminőség állapotáról.  

A megfelelő szoftvertermék előállításának megvannak tehát a kritériumai. Azonban nem mindegy, hogy mindezt szükséges rosszként kezeljük, vagy perspektívát váltunk és a kezdetektől fogva befektetésként tekintünk rá.

Szoftverminőség biztosítás, mint hosszútávú stratégiai befektetés

Mivel minden szoftverfejlesztési projekt egy üzleti célú beruházás, megvalósítása és produkcióba állítása önmagában is egy nagyobb költségtétel, fontos, hogy hosszútávú befektetésként tekintsünk rá. Tehát a fejlesztés során elvárás, hogy a befektetésünk belátható időn belül, előre meghatározott valószínűség szerint megtérüljön. Egy működő, de nem megfelelő szoftver jelentősen növeli annak kockázatát, hogy az előzetesen kiszámolt több éves megtérülési időszak alatt olyan nem várt költségek jelennek meg, amelyek elnyújtják, rosszabb esetben ellehetetlenítik a megtérülést. Így a korábban tervezett beruházásunk egy végtelen költségnyelvvé nyúlik. Azonban, ha a fent felsoroltak megvalósítás megfelelő megközelítéssel párosul, a szoftverminőség biztosítás hosszútávú befektetéssé válik. 

A fentieket összefoglalva jól látható tehát, hogy a szoftverminőség a fejlesztési folyamat egyik legfontosabb tényezője, melyet nem hagyhatunk figyelmen kívül és mindenképpen áldoznunk kell rá. Azonban sokkal több, mint egy költségtétel – egy hosszú távú befektetés, mely hosszú távon jelentős üzleti előnyökhöz juttathatja vállalatunkat.  

Amennyiben nem rendelkezünk elegendő belső erőforrással vagy szakértelemmel ezen a területen, forduljunk tanácsadó céghez. A 4DSoftnál elkötelezettek vagyunk a megfelelő szoftvertermékek fejlesztése iránt. Magasan képzett szakembereink, naprakész ismereteik a szoftverminőség biztosítás legújabb módszereiről, a területen szerzett tapasztalatuk lehetővé teszi a felmerülő kockázatok minimalizálását és a lehetséges üzleti megtérülés maximalizálását.