Az életünket átszövik a különböző számítógépes alkalmazások. A vállalkozások digitális transzformációjának nélkülözhetetlen összetevőire gondolunk, mint például a webáruházak, az időpontfoglaló rendszerek, az ügyviteli rendszerek, a rendelések felvételére használatos programok, vagy épp a flottakövető rendszerek. Amellett, hogy ezek nagyon hasznosak tudnak lenni, elkerülhetetlen, hogy hibákat is tartalmazzanak. Az újonnan készülő egyedi és a folyamatos fejlesztés alatt álló szoftverekre mindez különösen igaz.
A hibák kezelése nem a fejlesztőcégek magánügye. Ha megrendelőként nem készülünk fel legalább alapszinten arra, hogy az elkészült alkalmazást tesztelni is kell, kellemetlen meglepetések érhetnek minket. Jól példázza ezt az alábbi, megtörtént eset.
Egy balsorsú netes vásárlás története
A fekete péntek okozta vásárlási láztól elcsábulva a neten rendeltem egy könyvet, amit már régen el szerettem volna olvasni. Mivel még nem jártam a kiválasztott áruházban, a megrendeléssel együtt egy felhasználói regisztrációt is megejtettem. Kaptam róla egy emailt, aminek annyira megörültem, hogy a dologról azon nyomban el is feledkeztem. Hamarosan megjön a csomag, gondoltam.
Ám a csomag nem jött. Két hét múlva valahogy kezembe került a megrendelés nyugtája, eszembe jutott a könyv, és nyugtalan lettem. Írtam egy emailt az áruháznak. Néhány levélváltás után kaptam egy telefonhívást. A webáruház tulajdonosa hívott fel, sűrű bocsánatkérések közepette. Miközben beszélgettünk, szép lassan körvonalazódott, hogy mi is történt.
Kiderült, hogy a bolt nem kapta meg a megrendelésemet. Vevői oldalról minden rendben lévőnek tűnt, de az adataim nem kerültek bele a megfelelő adatbázisba. Az áruház munkatársai csak annyi információt kaptak a rendszertől, hogy valaki megrendelt egy könyvet, de hogy ki és milyen elérhetőséggel, azt már nem látták. Nem lettem volna a helyükben…
Az egész egy programhibának volt köszönhető. A webáruház szoftvere a megrendelésem előtt frissült, és a program fejlesztői nem vették észre azt, hogy bizonyos dolgok nem működnek benne rendesen. A program nem mentette el az új megrendelők adatait. Mint említettem, épp fekete péntek volt, sok új megrendelővel. Meg merném kockáztatni, hogy ezen az egy napon több hónapnyi forgalom lezajlik. Ezek nagy részét az áruház elvesztette. A tulajdonos hangjából érezhető volt, hogy ez nagyon fáj neki. Az eset sajnos nem egyedülálló. Bárkivel előfordulhat, aki a vállalkozásában szoftver használatára szánja rá magát. Szerencsére a problémára létezik ellenszer.
Szoftverhibák kiszűrése teszteléssel
A kellemetlenséget okozó hibákat leghatékonyabban teszteléssel lehet megtalálni. Amikor felhasználóként beleakadunk egy ilyen hibába, mi is pontosan ezt csináljuk. Éppen kipróbáljuk a szoftvert, és megtapasztaljuk, hogy hol nem működik jól. A felhasználó tehát mindig tesztel is – ám ezt nem jókedvében teszi. Ha egy szoftver hibáktól hemzsegve kerül a nagyközönség elé, akkor nagyon valószínű, hogy nem nyeri el az emberek tetszését. Ez pedig pont az ellenkezője annak, amit a szoftverek tulajdonosai el szeretnének érni.
Mit lehet tenni? Egy dolgot biztosan: tervezetten ki kell próbálni a szoftvert, még azelőtt, hogy azt a felhasználók rendelkezésére bocsátanánk. Ha találunk benne hibát, azt kijavíttatjuk a fejlesztőkkel. Ennek persze van némi költsége – de még mindig nagyságrendekkel kisebb annál, amit egy hiba éles üzemben okoz.
Amikor valaki – akár megrendelőként, akár kivitelezőként – valamilyen szoftver elkészítésére szánja rá magát, jól teszi, ha már a folyamat elején felkészül a tesztelésre. Autót sem szoktunk venni anélkül, hogy előtte ki ne próbálnánk, hogy megy. Talán ritkán tudatosítjuk magunkban, hogy egy próbavezetés nincs ingyen – gondoljunk csak az eladó idejére, a mi időnkre, az elfogyasztott üzemanyagra. Hasonlóképp, a büdzsébe a tesztelés költségét is bele kell tervezni.
Sokféle módon lehet szoftvert tesztelni. Az alábbiakban – különféle felosztások szerint – áttekintjük a lehetőségeket.
Milyen tesztelési módok vannak?
Tesztelni lehet manuálisan és automatizált módon is.
Az előbbi az, amit a legtöbben tesztelés alatt értenek. A felhasználók is pont így tesztelnek. A manuális tesztelés azt jelenti, hogy egy ember ül a számítógép előtt, nyomkodja a gombokat, szöveget ír a különböző mezőkbe, és nézi, hogy mi történik.
Az automatizált tesztelés trükkösebb. Ennek során egy ahhoz értő szaki kis programot ír, ami emberi beavatkozás nélkül nyomkodja a gombokat, beírja a mezőkbe a szöveget, és figyeli, mi történik.
Az automatizált tesztelés a folyamat elején beruházást igényel, mert meg kell írni a tesztprogramot. Ha ugyanazokat a teszteket többször is végre kell hajtani, akkor viszont behozza az árát, mert azt már minimális költséggel el lehet végezni.
Ökölszabályként el lehet mondani, hogy az automatizált tesztelés akkor éri meg leginkább, ha a szoftver fejlesztése elhúzódik, és rendszeresen változtatnak valamit a működésén. Ilyenkor ugyanis az újabb változtatások elronthatnak korábban már jól működő funkciókat. Hogy ezt elkerüljük, a korábbi funkciókat is újra meg újra ellenőrizni kell. Manuálisan ez sok időt igényel, az automata tesztek meg éjszaka is futhatnak, amikor mindenki alszik.
Amikor a szoftver fejlesztője tesztel
A szoftver elkészítésének folyamatában több résztvevő működik együtt. Érdemes megvizsgálni, hogy ők mikor és milyen céllal tesztelnek.
A leginkább magától értetődő eset az, amikor a szoftver fejlesztője tesztel. A fejlesztő ellenőrizni szeretné, hogy a program valóban azt csinálja, amiről ő gondolja, hogy csinálnia kell. Ez nem feltétlenül egyenlő azzal, hogy a szoftver “jól működik”. A “jól” jelző eléggé viszonylagos. Ha a fejlesztő és a megrendelő nem ugyanazt értik alatta, akkor az egész folyamat végén “hibás” eredményt kaphatunk – még akkor is, ha elviekben mindenki mindent “jól” csinált. Jegyezzük meg: általában nem elég, ha a tesztelést teljes egészében a fejlesztőcégre hagyjuk. (Erre később még visszatérünk.)
A szoftverek összetett dolgok. Az előállításuk során a készítők kisebb egységből építenek fel nagyobbakat. A fejlesztő által végzett tesztelés is ezt a mintát követi. A tesztjei részletesek, elsősorban az egységek (komponensek) működésére koncentrálnak. A helyzet az, hogy a különféle részegységek szisztematikus ellenőrzésére leginkább a gyártó képes. Ő az, aki egyáltalán tisztában van ezeknek a részegységeknek a létezésével.
Nézzük a korábbi autós példát! Az autókat alkatrészekből építik össze. Az alkatrészek integritását, teherbíró-képességét is – még az összeszerelés előtt – külön-külön ellenőrzik. Hibás alkatrészekből nem lehet jó autót összerakni. Ez a szoftverekre is igaz. Az alkatrészek ellenőrzése hasonlít a fejlesztő által végzett szoftverteszteléshez.
A netes vásárlásom fiaskója egy olyan hiba miatt történt, ami a szoftver belső működésével volt kapcsolatos. Ezt leghatékonyabban a szoftver fejlesztője tudta volna ellenőrizni. Egy ilyen hiba felszínre kerülése rávilágít arra, hogy a fejlesztő tesztelési folyamatai kiegészítésre szorulnak.
Mivel a fejlesztők amúgy is programoznak, ezért ők tudnak legkönnyebben automatizált teszteket készíteni. Ha fel szeretnénk mérni, hogy egy fejlesztőcégtől milyen minőséget várhatunk el, kérjük meg, hogy mutassa be nekünk a tesztelési folyamatát! Ha nem használ automatizált teszteket, akkor valószínűleg nem érdekli túlságosan a szoftverhibák kizárása.
Mik azok az integrációs tesztek?
Előfordul, hogy egy szoftver igazából több szoftver. Pontosabban több szoftver együttműködésének az eredménye. Ez persze nem mindig nyilvánvaló, és a szoftverek nem is mindig árulják el ezt magukról. Egy ilyen integrált szoftver tesztelésének tartalmaznia kell egy plusz elemet. Nézzük, mi az!
Az egyes összetevőket más-más fejlesztőcsapatok készíthetik. Meglehet, hogy ezek a csapatok a saját részüket aprólékosan letesztelik és jónak találják. Ettől a végső termék még lehet hibás – például úgy, hogy a részek nem jól kommunikálnak egymással.
Netes vásárlásnál ilyen az online bankkártyás fizetés. A webáruház önmagában egy szoftver, ami az egyes árucikkek listázásáért, a vásárlási kosár kezeléséért és egyéb hasonló dolgokért felel. A bankkártya-kibocsátó cég is elkészíti a saját szoftverét, amivel ellenőrizni tudja, hogy valóban a kártya tulajdonosa ül a gép előtt, és rendelkezik a szükséges fedezettel. Maga a vásárlás ennek a két szoftvernek az együttműködéséből keletkezik. Ha ez sérül, akkor a vásárlás sikertelen lesz.
Találkoztunk már olyan hibával, ami megakadályozta egy vásárlásunk befejezését? Én már többször átestem ezen. Fél óra termékválogatás után nagyon kiábrándító tud lenni, ha a fizetés nem működik. Mennyi kidobott idő! Az ilyen negatív élmények rombolják leginkább egy áruház márkáját.
A fentiek miatt a szoftverrendszerek ellenőrzésére integrációs tesztelést is használni szoktak. Az autós hasonlattal élve olyan ez, mint az ütközéses tesztek. Még nincsenek valódi felhasználók, de a teljes rendszer rendelkezésre áll. Nem az egyes alegységek működése a vizsgálat tárgya, hanem azok együttműködésének minősége.
Ebben a szakaszban kifejezetten bosszantó, ha egy alegység önmagában hibás. Az alacsonyabb szintű problémákat már az előzetes fejlesztői tesztek során fel kell tárni és ki kell javítani. Ha ez elmarad, akkor az integrációs tesztelés nagyon elhúzódhat.
Amikor az átvevő tesztel
Mielőtt egy szoftver a felhasználókhoz kerülne, a megrendelő átveszi azt. Az átvétel során ellenőrzi, hogy azt kapta-e meg, amit szeretett volna. A terméket ilyenkor szokás kipróbálni – mint ahogyan azt egy felhasználó is tenné. Ez a szoftverek “próbavezetése”.
Az átvevő célja ilyenkor nem az alapvető hibák kiszűrése, vagy az integrációs problémák feltárása. Mindezeknek eddigre már meg kellett történniük. A teszteléssel ilyenkor azt ellenőrzik, hogy az összkép jó-e, a szoftver alkalmas-e a vágyott célok elérésére. A kinézet, stílus, a hordozott üzenet előtérbe kerülnek. Az egész folyamat lehet kevésbé szisztematikus, hiszen fontosak a használat során megjelenő érzések is. Röviden úgy fogalmaznék, hogy a felhasználói élmény van terítéken.
Elméletileg ennek a szakasznak kellene a legrövidebbnek lennie. A gyakorlat viszont erre sokszor szomorúan rácáfol. Egy külön-külön működő és jól összekapcsolt részekből álló szoftver már nem dob váratlan hibákat, így lehetőséget ad arra, hogy az átvevő a saját szempontjai szerint vizsgálja. Ha azonban valamelyik korábbi tesztelési szint kimaradt vagy nem volt elég hatékony, a tesztelésre szánt idő nagyságrendekkel megnövekedhet.
Miért is? A különböző típusú hibákat legolcsóbban a nekik megfelelő tesztelési szakaszban lehet kiszűrni. Ha a problémát egy apró komponens működési hiányossága okozza, az a fejlesztési szakaszban jól lokalizálható. Az egész folyamat végén, az átvételi szakaszban viszont már nagy fejtörést tud okozni, mert akkor már komponensek ezrei működnek egyszerre. Ilyenkor még a fejlesztőknek is hosszadalmas lehet eldönteni, hogy melyik is a hibás.
Ha az átvételkor “esnek ki” a rendszerből a működési hibák, akkor azok az átvételi tesztelés eredeti célját is meghiúsíthatják. Egész egyszerűen nem marad idő az üzleti folyamatok és a felhasználói élmény ellenőrzésére. Ez a hatékony tesztelés elmulasztásának másik bosszantó következménye.
És végül a legrosszabb: a szoftverhibák ebben a szakaszban szűrhetők ki a legkisebb hatékonysággal. Ez azt is jelenti, hogy nagyobb számban fognak átkerülni az “éles” rendszerbe, ahol a felhasználók azokat meg is fogják találni.
Mindent a maga idejében
Írásommal arra szerettem volna rámutatni, hogy a szoftverfejlesztési projektek kivitelezésénél a megfelelő szakaszban végzett tesztelés mennyire fontos lehet. Az ezzel kapcsolatos költségeket és feladatokat már az egész elején érdemes tisztázni. A hibák megjelenését nem lehet megakadályozni – hiszen a programokat emberi lények írják. A felismerésük és javításuk viszont már tervezhető.
Ha valaki szoftverfejlesztésre adja a fejét, jó, ha tisztában van a tesztelés szerepével. És most nemcsak a fejlesztőcégekről beszélek. A megrendelők kérhetik az átvett termék megfelelő módon és megfelelő időben történő tesztelését.
Mi történik, ha sem a fejlesztő, sem a megrendelő nem kezeli kiemelten a tesztelést? A gyakran előforduló módosítások és projekt csúszások miatt épp a tesztelésre fordított időből vágnak le. Ennek egyenes következményeként a felhasználók fogják tesztelni a szoftvert.
Azt pedig igazából senki sem szeretné.
Mit vigyél magaddal?
- Szoftverigény esetén érdemes számolni a tesztelésre fordított idővel és pénzzel is.
- A tesztelést lehet manuálisan és automatizáltan is végezni.
- A tesztelést a projekt különböző szakaszaiban különböző céllal és részletességgel végezzük.
- Megrendelőként bátran rákérdezhetünk a szoftvert fejlesztő cég tesztelési stratégiájára.
Amennyiben részletesebben is érdekelnek a tesztautomatizálásban rejlő lehetőségek, akkor böngéssz weboldalunkon vagy keress minket!
Szerző:
Simon Kornél – Alapító, ibello.hu
