Az üzleti tesztelésről tesztelői szemmel

Üzleti tesztelés. Ez a munkám. 8 éve foglalkozom az üzleti fejlesztések tesztelésével különböző rendszerekben, ami alatt rengeteg tapasztalatot, tudást szívhattam magamba és láthattam, hogy ezen idő alatt mekkora fejlődésen haladt végig az IT terület.

S emiatt, a technika csodálatos világában joggal kérdezhetik tőlem, hogy miért is van még mindig szükség manuális tesztelésre? Hiszen olyan ez, mint egy analóg óra a digitális világban.

A válasz végtelenül egyszerű: mert semmi nem képes olyan kifinomult munkát végezni, mint az emberi agy. Az agyunk, amely képes olyan információk befogadására és értelmezésére, amelyet egy számítógép nem feltétlenül tud komplex módon vizsgálni és meglátni benne az üzlet azon elvárásait, amelyek kapcsolódnak a tesztelni kívánt funkcióhoz. Nem, itt nem arról van szó, hogy nincs pontos meghatározás egy-egy fejlesztéshez, hanem arra kell gondolni, hogy az összefüggések nem mindig nyilvánvalóak. Egy számítógép, program számára biztosan nem.

Valóban, sokan gondolják azt, hogy az automatizálás a megoldás az erőforrások és költségek csökkentésére, az idővel is bőven lehet spórolni, de tapasztalataim alapján csak azokat az alapvető követelményeket lehet automatizált módon üzleti szempontból tesztelni, amelyek újra és újra ismétlődnek. Miért is ne lehetne egyszerre automatikus és manuális tesztet végrehajtani, ha ehhez minden eszköz a rendelkezésre áll? Nem csak hogy lehet, hanem kell is. Hiszen a kettő nem üti, hanem kiegészíti egymást. Az eredmények tekintetében a legjobb párosítás.

De hogyan érhetünk el jó eredményeket az üzleti tesztelésben? A legfontosabb, hogy megfelelő szervezeti egységek kialakításával, azok működésének meghatározásával, módszertanok és jól használható teszteszközök segítségével a változás folyamat mindenki számára egyértelmű, pontosan dedikált és „end-to-end” legyen.

Egy üzleti tesztelő korábban a változás folyamat végén kapcsolódott be a munkába. A tesztelési módszertanok megjelenésével és elterjedésével azonban ez a szemlélet szerencsére eltűnni látszik. A következetes fejlesztési tervezésnek köszönhetően már a fejlesztés megvalósításának első szakaszban bevonják az üzleti tesztelőket a folyamatba.

Ennek rengeteg előnye van. A tesztelő már jó előre láthatja a módosítás vagy új igény volumenét, ezáltal következetes becslést tud adni a teszt tervezésének, végrehajtásának idő- erőforrás- és eszköz igényéről. A korai bevonással a tesztelő számára a célok tisztábbak, a szervezeti egysége számára az erőforrásai pedig tervezhetőbbek lesznek. Nagy előnyt jelent az is, ha már a projekt vagy a változásigény elején láthatjuk, hogy kik alkotják a csapatot, akikkel akár hónapokig kell együtt dolgoznunk.

Ezek mentén a teszt tervezése során a legfontosabb feladatok, mérföldkövek:

• Meghatározni az üzleti tesztelés során használandó teszttípusokat (Funkcionális teszt, folyamat szintű teszt – ha szükséges integrációval -, Disaster Recovery teszt, automatikus teszt stb.)
• Ezekhez a teszt tervezési és tesztelési idő becslése
• Minden teszttípushoz meghatározni a teszteszközt, tesztkörnyezetet, erőforrás igényt, 10-15% többlettel kalkulálva az előre nem látható események, valamint a hibák javításának plusz ráfordításai miatt
• Ha szükséges, a tesztmenedzserrel egyeztetni a fejlesztői és üzemeltetési támogatás erőforrás igényéről

A leggyakrabban előforduló teszttervezési hibák:

• Nincs elég tesztesetünk, emiatt nem tudunk teljes lefedettséget biztosítani.
  Ezért mindig jó, ha alapesetben legalább 3 teszteset tartozik egy funkcióhoz
• Nincs negatív teszteset.
  Pl.: Ha egy mezőbe csak pozitív egész szám írható, akkor mindig érdemes olyan esetet írni, ahol a mezőbe megadott értékként negatív és/vagy tört szám kerül.
• A kapcsolódó folyamatokat nem vesszük számításba.
  Érdemes megnézni, hogy az adott funkció milyen egyéb folyamatok részét képezi és megnézni, hogy a változás nincs hatással a másik folyamatra.
• Csak funkcionális tesztelésre készülünk.
  Mindig folyamat szinten szemléljük a változásokat! Akkor is, ha a folyamatnak csak egy részére irányul a módosítás.
• Nem hagyunk elég időt a hibák javítására.
  Érdemes több tesztkörben gondolkodni, mivel a hibák javítása időigényes lehet a fejlesztői csapatnak.
• Hibajavítás esetén szintén fontos az end-to-end szemlélet.
  Ne csak az adott tesztesethez kapcsolódóan teszteljük újra a javított funkciót, hanem szükség esetén nézzük végig újra a folyamatot!
• Nem hagyunk időt oktatóanyag készítésére.
  Főleg a multinacionális cégeknél fontos, hogy a változásokat ne csak az élesítés pillanatában tudatosítsuk a felhasználókban, hanem előre tervezetten, dokumentáltan, rendszer specifikusan be is mutassuk azt nekik. Ha nem triviális elsőre a módosítás, egy néhány oldalas ppt vagy word dokumentumban, képernyőképekkel, azok szöveges magyarázatával kiegészítve készíts oktatóanyagot.

De van, amikor a gondos tervezés sem elég.

A pontos tervezés és végrehajtás sem hozza meg mindig az elvárt eredményt. Rajtunk kívül álló okok miatt bizony megbújhatnak hibák az alkalmazásokban. A legtöbbször olyan triviális problémák adódnak, amelyek a megfelelő emberek bevonásával már a tesztelést megelőzően kiküszöbölhetőek lettek volna. Minden feltétel adott, a szervezeti egységek gördülékenyen viszik hátukon a feladatokat, az üzleti tesztek az elvárásoknak megfelelően működnek, az összes megtalált hibát javították és az újratesztelés is megtörtént, de élesbe állítás után probléma adódik.

Mit tehetnénk még?

A válasz: Több szem, többet lát. Az eddig jó bevált folyamatba beilleszthetünk egy rövid közjátékot, „Szakmai fórum” elnevezéssel. Ide olyan szakembereket hívhatunk meg, akik a változáskezelési folyamatban nem feltétlenül kapnak szerepet, de magához az alkalmazáshoz (vagy annak változásához) jelentős közük van. Ez lehet az alkalmazás üzemeltetői és az operációs támogató terület, mint meghatározó szakgárda, de természetesen a fejlesztőket se hagyjuk le a meghívóról. A szakmai fórumon (a change-ektől függően hetente-kéthetente vagy havonta) megvitathatjuk az aktuális fejlesztéseket és több olyan hibát küszöbölhetünk ki, amelyek jelentős mennyiségű ügyfélpanasztól és plusz munkáktól kímélhetnek meg bennünket. Ezek a hibák általában nem az adott rendszerben, hanem éppen más rendszernek átadott adathalmazban, működésben okozhatnak galibát, amelyet egy adott rendszer vagy alkalmazás üzleti tesztelője nem feltétlenül ismer.

E fontos szerepe mellett a „Szakmai fórum” információval is szolgál az adott felhasználói területeknek minden változásról, még a felkészülési szakaszban. Így nekik is jut idejük a változásokat beilleszteni a napi rutinba, szükség esetén felhasználói kézikönyvbe vagy az utasításba. És ezzel mi is, ők is és a cégünk is csak nyer!

Szerző: Szegedi-Szabó Beáta