Fedezzünk fel képességeket, ne tulajdonságokat

A jó felfedező tesztelés nem csak a szoftver tulajdonságaira koncentrál, hanem az előre nem látható kockázatokkal is számol. A tesztelés folyamán sokszor ezért a dolgok mögé kell néznünk és az előre nem láthatóval, váratlan esetekkel kell dolgoznunk, hogy hasznos szoftver képességeket fedezzünk fel.

A felfedező tesztelés világos elképzelést követel meg. Nagyfokú koncentrációt igényel, a csapatnak el kell tudnia dönteni, hogy mi az, ami fontos, és mi az, amivel nem kell foglalkozni. A tiszta elgondolás segít megelőzni a későbbi strukturálatlan lépéseket a rendszerben. Ahogy a szoftver bizonyos részei implementálásra kerülnek és a felhasználói sztorik rendelkezésre állnak a felfedező tesztelésre, logikusan fel lehet építeni az új teszt feladatokat, lépéseket a változásokra. Ez az egész nem hangzik túl intuitívnek, mivel a sztori alapú tesztelés csőlátáshoz vezethet és akadályozhatja a csapatot a hatékony tesztelésben.

A sztorik és a funkciók szilárd startkövei a determinisztikus ellenőrzéseknek, de nem annyira használhatóak a felfedező tesztelésben. Amikor a felfedező tesztelés a funkciókra és a változásokra összpontosít, amelyeket a sztorik futtatása eredményez, a tesztelők megunják azokat a funkciókat tesztelni, amelyek továbbra is jól működnek és néhányszor el is térnek a meghatározott folyamattól. Beleunnak annak a taglalásába, hogy mit is kellene tapasztalniuk a tesztek során. A felfedező tesztelés akkor a legjobb, amikor az előre láthatatlannal és a váratlannal dolgozunk. Ennek érdekében megállapításokat kell tennünk, valamint teszteket kell kidolgoznunk az előre nem látható eredményekre. Ennek az elérése érdekében a felfedező csapat nem csupán a szoftver tulajdonságaira koncentrál.

A jó felfedező teszt az előre nem látható kockázatokkal is számol, ezért a dolgok mögé kell nézni. Egy másik értelemben, nem dobhatjuk a tesztelés hálóját túl nagy területre, mert azzal elvesztjük a fókuszt. A jó megközelítés, hogy megtaláljuk az egyensúlyt a tesztelési határok szélesítése mellet a fókusz megtartására, hogy mire is képes a felhasználó a rendszerben. A rendszer tulajdonságai képessé teszik a felhasználókat arra, hogy valami hasznosat csináljanak, illetve elveszi a képességüket attól, hogy valami veszélyeset tegyenek. Az a jó módszer a nem várt veszélyek felderítésére, ha nem a szoftver tulajdonságaira, hanem a képességeire koncentrálunk.

Legfontosabb előnyök

A felfedező tesztelésben a képességekre koncentrálni, jobb megértést eredményez és elkerülhető a csőlátás.

Jó példa erre egy kapcsolat felvételi űrlap, amit a MindMup-nak készítettünk a tavalyi évben. Az űrlap felhasználói kéréseket küldött, amennyiben azt a felhasználó kitöltötte. Felfedezhettük volna rengeteg dolgot, mint mezőhosszak, e-mail formátumok, karakterkészletek, üzenetek, de ez csak arra lett volna jó, hogy elmondhassuk, az űrlap működik. A háló kicsit messzebbre dobása, két űrlapképességre hívta fel a figyelmet. A felhasználóknak képeseknek kell kapcsolatba lépni velünk, amennyiben valamilyen hibába ütköznek és nekünk egyszerűen kell tudnunk kezeli ezeket a felhasználói kéréséket és megoldani a felmerült problémákat. Így van egy dolog, amit mindenképpen meg kell előznünk, mégpedig azt, hogy ezt a csatornát senki sem blokkolhatja, a felhasználói problémáknak minden esetben célba kell érniük. Ezt a képességet vizsgáltuk a felfedező tesztelésben, megnéztük egy elérhetőségi probléma alatt a kapcsolati űrlap működését, valamint azt, hogy mennyire egyszerű egy tipikus probléma felmerülése esetén a riportolás. Kettő kritikus dologra hívtuk fel a figyelmet.

Az első az volt, hogy a fő okát a problémának nem kezelték az eredeti megoldásban. A megbízhatatlan hálózati csatlakozás még rengeteg egyéb bejövő kérést is kezelt. De amikor az internetkapcsolat véletlenszerűen leállt, függetlenül attól, hogy az űrlap ki lett töltve vagy sem, a böngésző megszakította a kapcsolatát a szerverrel. Ha valaki hirtelen leszakad az internetről, a kapcsolati űrlap teljes mértékben használhatatlanná válik. Lehet, hogy a felhasználó kitöltötte az űrlapot a kérésével, de a rengeteg hálózati akadály miatt sohasem fog velünk kapcsolatba lépni. Ugyanez történik amikor a mi szerverünk egyszer csak megáll. Egyiknek sem kellene megtörténnie egy ideális világban, de amikor megtörténnek, akkor van a felhasználónak igazából szüksége a segítségre. Végül a tulajdonság ki lett fejlesztve tökéletesen, de még mindig volt egy nagy hiányosság a képességben. Ennek érdekében egy alternatív kommunikációs csatornát alakítottunk ki, ami akkor is elérhető, ha a hálózati kapcsolat nem működik. Megjelenítettünk egy e-mail címet az űrlapon, ahol jelezni lehet a hibát, illetve az űrlapra is kitettünk egy üzenetet, hogy az űrlap nem lett elküldve.

A másik nagy gond az volt, hogy a felhasználók bár kapcsolatba tudtak lépni velünk, az alkalmazás mélyének ismerete nélkül nem tudtak elég információt adni a hiba javításához, ha adatvesztésről, vagy szoftverhibáról volt szó. Ez először a teljes sötétségbe taszított minket, és megzavarta a kollégákat, hogy segítséget tudjon nyújtani a felhasználóknak. A megoldás az lett, hogy a hiba elküldésével a háttérben elküldtük az operációs rendszer verzióját, a böngésző típusát, valamint az utolsó 1000 felhasználói tevékenységet a logból, ami segített reprodukálni a hibát.

Hogyan tud ez működni

Hasznos képességeket úgy találhatunk a felfedező teszteléshez, ha feltérképezzük, hogy a szoftver meglévő tulajdonságaival mire képes, illetve mire nem képes a felhasználó. Amikor a felhasználói sztorikat tervezzük, fókuszáljunk inkább a felhasználói oldal értékeire az „annak érdekében, hogy…” típusú mondatokra, ne pediglen az „én azt akarom csinálni, hogy…” kezdetűekre.

Akár impact map-et, akár user story map-et használunk a tervezéskor, mindkét esetben jó kiindulási pontunk van a felhasználói képességek megvitatására, átbeszélésére.

Szerző: Gojko Adzic