Kivel teszteljünk és hogyan állítsuk össze a tesztelői csapatot?

Sokszor elszomorít, hogy funkciók fejlesztés, de még annak előzetes követelmény elemzése során sem vonják be az érintetteket, akik később azt használni fogják. Egy-egy bonyolultabb folyamat során lehetetlen, hogy összeszedjük és rendelkezzünk mindazzal a tudással, tapasztalattal, ami a teljes és pontos definiáláshoz szükséges, nem ismerhetjük a negatív ágakat és kivételeket sem, vagy olyan idő befektetéssel járna, amely nem fog megtérülni.

A funkció tesztelés során is érdemes olyan résztvevőkkel, csapattal elvégeztetni a tesztelést, amely pontosan ismeri a funkciót és a hozzá kapcsolódó folyamatokat, bemenő és elvárt kimeneti adatokat. Ahogy a követelmény elemzésnél, úgy a funkció tesztelésénél is úgy szoktam a résztvevőket összeválogtani, hogy legyen benne pozitív szemléletű egyén, és nagyon kritikus, mindenben hibát kereső ember is. Így szélesebb visszajelzést kapunk, és csökkenthetjük a megerősítési torzítás hatását.

Gyakori az a hiba is, hogy egy feladat definiálásakor a tesztelő csak az elvárt eredmény szerinti utakat járja be, a hétköznapi felhasználáskor felmerülő utakkal, lehetőségekkel nem számol, hiszen nem feltétlenül ismeri azt. Emiatt is fontos, hogy kritikus folyamatokat érintő funkcióknál ne csak a fejlesztő csapat tesztelője ellenőrizze a megvalósított feladatot, hanem a rendszert majd napi szinten használó munkavállalót is bevonjuk a tesztelésbe.

Ahogy írtam a korábbi posztban, a külső rendszereken átívelő folyamatok esetében pedig a különböző fejlesztő csapatok tesztelőinek kell(ene) összedolgoznia, ha lehetséges, vagy ilyen esetben is a megrendelő munkavállalóját kell bevonni a tesztelésbe.

Kapcsolódó szolgáltatások avagy mi alapján fejlesszünk folyamatokat, válasszunk 3rd party beszállítókat

Az elmúlt pár hónapban áttértem vonatra a Veszprém Budapest távolság megtételéhez. Egyrészt környezetvédelmi okokból, de a dugóban való araszolás is nehezen megszokható, főleg stresszesebb időszakban. Másrészt az utazással járó kétszer másfél órát sokkal hatékonyabban lehet eltölteni például olvasással, önfejlesztéssel, ha nem kell a volán mögött ülni. Mióta forgalomba állították ezen a vonalon is a FLIRT vonatokat, mindezt teljesen kultúrált környezetben lehet végezni. A jegyeket automatából lehet megvenni, kártyával fizetve. Sajnos anno az applikáció nem érte el az általam elvárt minőségi szintet, így nem is használom, de ha fejlesztenek rajta, akkor majd újra megpróbálkozunk vele. Tehát teljesen rendben van a szolgáltatás színvonala a MÁV oldaláról, semmi ok panaszra.

Akkor miért is született meg ez a poszt? Probléma út közben szokott felmerülni, amikor netezni lenne kedve az embernek, vagy valaminek utána nézne vagy épp dolgozna. Ugyanis az út nagy részén semmilyen vagy nagyon gyenge adatkapcsolat érhető csak el. Ennek sok esetben földrajzi okai vannak és hiába van WI-FI elérés a MÁV vonatokon, mivel az is 4G-s routeren kommunikál, így azon sem lesz bizonyos helyeken semmilyen használható adat kapcsolat. És ilyenkor, még ha tévesen is, a vasút társaságot fogja szidni az ember, hiszen ott egy szolgáltatás, ami nem használható, hiába egy harmadik fél, külső szolgáltató hibájából. A szép, tiszta, gyors vonatok által nyújtott élmény nem lesz 100 százalékos, mivel az idő eltöltése sok esetben gondot, akár bosszúságot is okoz.

Ugyanígy egy vállalkozás életében is fel kell mérni, hogy melyik folyamatok függnek külső szolgáltatótól vagy beszállítótól és biztosítani kell, hogy a belső folyamatok a lehető legfüggetlenebbek legyenek tőlük. Az alkalmazottak elégedettségét is növeli, ha olyan rendszerekkel kell dolgozniuk, amelyek hiba tűrők és az általuk elvégzendő munka gördülékenyen elvégezhető, nem kell megszakítaniuk különböző hibák miatt, nem lassítják a belső folyamatokat. Ha fejlesztünk egy belső rendszert, amely kapcsolatban áll akár másik belső vagy külső rendszerrel, akkor mérjük fel a teljes folyamatot, az adat átviteli pontokat és ha szükséges, akkor a másik rendszert is fejleszzük párhuzamosan vagy jelezzük a beszállító felé a problémát.

Sajnos találkoztam már olyan problémával, hogy egy ERP rendszerrel összekötött webshop esetében nem lehetett az új webes funkciókat kiélesíteni, mert az összekapcsolt ERP rendszer nem tudta időben feldolgozni az adatokat vagy hibásan adott vissza adatokat. Itt ugye egy belső rendszer volt a szűk keresztmetszet és előbb azon kellett javítani, hogy a rendszereken átívelő folyamat a megfelelően működjön.

Ugyanígy egy webshop esetében is a végfelhasználó sok esetben találkozik külső szolgáltatókkal (fizetés, szállítás), ahol hiába egy 3rd party szolgáltatást veszünk igénybe, a végfelhasználók nagy része ezeket egyként kezeli a webshoppal, így ha ezek használata során problémával vagy kellemetlenséggel találkozik, akkor magát a webshopot fogja szidni, azzal köti össze a kellemetlen élményt és legközelebb valószínűleg másik webáruházban fog vásárolni. El kell fogadnunk, hogy ezekben az esetekben a beszállító cég képvisel minket  így meg kell követelnünk a megfelelő szolgáltatási színvonalat, vissza kell mérnünk azt és ha szükséges, javítani rajta, rosszabb esetben szolgáltatót váltani.