A legnagyobb mítosz: a tesztelés automatizálása

Az egyik leggyakoribb buzzword vezetői oldalról: automatizáljuk a tesztelést! Mindig, mindenhol hallani ezt, teljesen függetlenül attól, hogy a tesztelési kultúra milyen érettségi szinten van a szervezetben, és hogy technikailag mit lehetne egyáltalán automatizálni.

Kezdjük az alapokkal: mit várunk el a teszteléstől? Még az élesítés előtt vizsgáljuk meg a terméket, találjuk meg a hibákat, csökkentsük az élesítéssel járó kockázatokat. Mit lehet ezen automatizálni?

A tesztelés automatizálásának két szituációban van értelme. Az első a regressziós tesztelés: a rendszeresen, ugyanúgy megismételt tesztelési feladatok. Ezeket manuálisan végrehajtani unalmas, nagyobb a hibalehetőség, illetve a manuális tesztelés lassú, automatizálva gyorsabban, több tesztet lehet lefuttatni.

A probléma, hogy a változásokat és a fejlesztéseket az automata eszköznek egyesével be kell programozni – ez viszont csak lassan megy, tehát adott funkció leteszteléséhez az automata tesztelőnek sokkal több idő kell, mint a manuális tesztelő kollégáknak. Az agilis módszertani elképzeléseknek általában része, hogy az adott sprintben az új fejlesztésekhez tartozó automata tesztek is készüljenek el, de én még soha, sehol nem láttam, hogy ez ténylegesen megtörtént volna, az automata tesztelés általában hónapokkal lemaradva követi csak a fejlesztéseket.

Tisztában kell lenni továbbá a Pesticide paradoxon nevű alapelvvel: ha ugyanazokat a teszteket ismételjük újra és újra, végül ezek a tesztek már nem fognak új hibákat találni. Ezért a teszteseteket rendszeresen felül kell vizsgálni, karbantartani, új teszteket kell hozzáadni, hogy az automata hibákat találjon. A regressziós tesztelést hosszútávon érdemes automatizálni.

A másik szituáció, ahol az automatizálás hasznos lehet a load test, a terhelés szimulálása. Például ha manuális tesztelőből nem tudunk annyit felsorakoztatni, amennyien a végfelhasználók lesznek – a számítógép viszont szimulálni tudja ezt a helyzetet, ahogy a hosszan tartó, folyamatos terhelést és sok más nehezítést is.

Kik azok a tesztautomatizálók? Az automata eszközök programozásához programozói tudás kell. Az automata tesztelők ezért a fejlesztők/tesztelők tengelyén a fejlesztőkhöz állnak közelebb, gyakran fejlesztők specializálódnak automata tesztelésre. Mivel a fejlesztők többet keresnek a tesztelőknél, a „tesztelés automatizálása” viszonylag drága mutatvány, mármint ha a cél simán csak a manuális tesztelők kiváltása.

Hogyan mérhető, hogy megéri-e? Minden automata tesztelő előszeretettel hivatkozik a lefuttatott tesztesetek számára. Száz, ezer, tízezer API hívást indítottunk, jó alaposan leteszteltük tehát a rendszert. Valóban?

Szerintem mindenféle tesztelés értelmét és eredményességét végső soron a riportolt, majd kijavított hibák száma mutatja meg – ennyivel fejlődött ugyanis a szoftver a tesztelő tevékenysége nyomán. Ha egy automata tesztelő évek óta dolgozik a csapattal, de soha, egyetlen hibát sem riportolt (megtörtént), ott el kellene gondolkozni, hogy valóban megérte-e a tesztelés automatizálása…

Priority, Severity – mit jelent ez egyáltalán és hogyan kellene a bugokat helyesen priorizálni

Az a helyzet, hogy mindenki gondol erről valamit – de mindenki valami mást.

Minden teszt adminisztrációs rendszerben van a bugokhoz legalább két mező, általában Priority és Severity néven, amelyekkel elméletileg a hiba súlyosságát, a javítás sürgősségét, valamint az okozott kár nagyságát lehet jelölni. Minden cégnél, minden csapatban van valamilyen definíció arra, hogy ezeknek az értékei, és az értékek kombinációi mit jelentenek: azonnal kell a javítás, sürgősen javítani kell, nagyon fontos, kevésbé sürgős stb.

Ezek a definíciók azonban kissé homályosak, egy idő után összefolyik, hogy a Major és a Critical között mi a különbség. Pontosabban, tapasztalatom szerint mindenki pontosan tudja, hogy mi jelentenek – de mindenki másképp…

A hibát ott követjük el, hogy a definíciókat a saját szempontunkból írjuk meg. Ehelyett arra kellene gondolni, ami a fejlesztők oldalán történik:

  1. Dobjanak el mindent azonnal, javítsák ki a hibát és küldjenek hotfixet
  2. Vegyék előre a hiba javítását, és már a következő sprintben, következő buildben szállítsák is le
  3. Később is ráér a hiba javítása, de az élesítésig legyen készen
  4. A hibával az éles működés során is együtt tudunk élni

A fenti besorolásokat nevezzük el például úgy, hogy Blocking, Critical, Major, Minor, és a szerződésbe írjuk le a vonatkozó határidőket (pl. két munkanap / következő sprint / élesítés dátuma) és kész is vagyunk. Minden más (pl. a Severity mező használata) csak felesleges bonyolítása a csapat életének.

A tesztelés adminisztrációjához miért nem elég az Excel?

Röviden: a bugok miatt.

Hosszabban: a tesztesetek megírására és az eredmények (Passed/Failed) rögzítésére bőven elegendő az Excel. Sőt, az Excel tűnik az ideális megoldásnak: kell néhány oszlop (Chapter, Steps to reproduce, Expected result, Actual result, Notes), és lehet is írni a teszteseteket egymás alá. Az Excel erre tökéletes, volt, ahol még akkor is Excelben írtuk meg a teszteket, ha volt erre bevezetett, specializált eszköz – megírtuk Excelben, aztán betöltöttük őket a rendszerbe.

A probléma a hibáknál kezdődik, amiket riportolni akarunk. Eleve túl sok mező kell egy hibajegy leírásához: ID, title, description, environment, reported by, assigned to, priority, status, comments – és ez csak egy elméleti minimum. Nem fér el szépen se vízszintesen, se függőlegesen. És további problémák is felmerülnek majd, ha mégis Excelt akarsz használni:

  • description: nehéz szép, formázott folyószöveget írni Excelben. El kell férjen a probléma alapvető bemutatása, az indoklás, hogy ez miért probléma, elvárt és aktuális eredmény, workaround – nem egy tipikus Excel cella tartalma
  • attachments: ezt nem is tudod Excelben megoldani (vagy csak nagyon rondán)
  • értesítések: minden teszt admin toolban beállítható, hogy a kiválasztott bugok körében minden változtatásról e-mail értesítést kapj. Bárki bármit matat: tudni fogsz róla. Excelben ez nincs, így észre sem veszed, ha valaki pl. az egyetértésed nélkül megváltoztatja a bugod prioritását (megtörtént) vagy lezárja a hibádat (megtörtént)
  • kommentek: sok hasznos információt, kontextust nyújtanak a kollégák által beírt kommentek. Például: nálam is reprodukálható a hiba, másnál viszont nem, kell-e javítani egyáltalán és hogyan, lezártam ilyen és ilyen okból… Számtalan téma felmerülhet egy bug kapcsán, amit egy kommentfolyamban kényelmesen meg lehet beszélni – Excelben ez szintén lehetséges, de ronda lenne
  • history: amiből látszik, hogy hogy milyen változtatások történtek a bugban, tipikusan: ki és miért módosította a prioritását és a státuszát. Excelben ez az információ elvész (vagy csak bonyolultan elérhető a SharePoint history-n keresztül)

A professzionális teszt adminisztrációs eszközök sok más hasznos funkciót is nyújtanak még: kapcsolatot a specifikációval, Jirával, automatizáló eszközzel, kényelmesen lekérhető riportokat, szabályozható felhasználói jogokat… De ezek nélkül még elkezdhető a tesztelés akár Excelben is – a hibajegyek kulturált kezelése viszont már nem.

A legnagyobb tévedés: a kimerítő tesztelés lehetősége

A tesztelés hét alapelvéből az első: kimerítő tesztelés nem lehetséges. Ennek ellenére jaj, hányszor hallottam: ezt most nagyon alaposan teszteljétek le, és ha bármilyen hiba van benne, azt találjátok meg!

Nagyon vicces volt, hányféle szinonimát találtak a kollégák a „kimerítő” szóra:

  • kívülről-belülről teszteljétek le
  • teszteljétek szét
  • tüzetesen fésüljétek át
  • teszteljétek szénné

Elméletben persze érdekes eljátszani a gondolattal, hogy például egy adott szoftver modul kimerítő tesztelése mit jelentene:

  • minden lehetséges input adatot (minden lehetséges ekvivalens input adatot),
  • minden lehetséges futtatási opciót (összes gomb, összes menüpont, összes opció kipróbálása)
  • minden lehetséges futás közbeni beavatkozási módot (gombok nyomogatása, egér kattintás, környezet módosítása)
  • ezeket az összes lehetséges sorrendben
    • leírni
    • lefuttatni

Végtelen ideig tartana vagy végtelen erőforrást igénybe véve lehetne megvalósítani. Hétfőre kell? Nem probléma!

A valóságban pedig nyilván adott már az ún. regressziós teszt set, amit adott idő alatt le lehet futtatni. Hibákat találni pedig a kollégák tapasztalata, és az új fejlesztésekről megismert információk függvényében lehet. Szerintem a fejlesztő kollégák se örülnének, ha belátható időn belül minden hibát megtalálnánk…

A látássérült emberek számítástechnikai lehetőségei és eszközei (főiskolai jegyzet)

2006-2007 folyamán indult el az ELTE Bárczi Gusztáv Gyógypedagógiai Főiskolai Karon az elemi rehabilitációs tanárképzés, ehhez volt szükség tananyagokra, jegyzetekre. Az egyik, tananyag-készítésre felkért szakértő Fábri Tímea, a Gyengénlátók Általános Iskolájának számítástechnika-tanára, egyben az „Informatika a látássérültekért” Alapítvány kuratóriumi tagja volt. Ő Szuhaj Mihályt, az alapítvány elnökét és engem kért fel a közös munkára, így a jegyzetet végül együtt írtuk meg, ketten mint szerzők és Misi mint szakmai lektor. A tananyag a Bárczi által kiadott Elemi rehabilitáció 3. című tankönyv egyik fejezeteként jelent meg.

Több hasonló témájú szakdolgozat született már korábban, de azok a terület gyors fejlődésének köszönhetően rendkívül elavultak voltak, mi viszont akkor a legfrissebb információkkal tudtunk szolgálni. Természetesen az idővel ez a jegyzet is gyorsan elavul majd: a publikálás időpontjában (2008. augusztus) például nemsokára elkészül a JAWS for Windows program honosított 9-es verziója, a beszélő Ubuntu Linux és így tovább. Mégis, a jegyzet a vakügyi informatika eddigi legátfogóbb bemutatása, egyben a 2003-2008-ban végzett munkám összegzése.

Letöltés: A látássérült emberek számítástechnikai lehetőségei és eszköze (pdf)

A látássérült emberek médiafogyasztási és tájékozódási lehetőségei (szakdolgozat)

Az alábbi szakdolgozatot 2008 első hónapjaiban írtam. Ebben az időszakban ötödik éve dolgoztam az MVGYOSZ, majd az „Informatika a látássérültekért” Alapítvány munkatársaként a vakügyi informatika és kisebb részben a vakügyi közélet területén. A dolgozat elkészítése viszont nem munkahelyi feladatom volt, hanem a 2007-2008-ban elvégzett újságíró-iskolai képzésre írtam szakdolgozatnak.

A dolgozat 2008. elején érvényes információkat tartalmaz, a megállapításaim azóta részben elavulhattak.

Letöltés: A látássérült emberek médiafogyasztási és tájékozódási lehetőségei (pdf)

A vak és gyengénlátó emberek számára alkalmazható hangoskönyv megoldások és szabványok áttekintése (tanulmány)

2007 elején, a DEX projekt előzményeként, mintegy a projekt indoklásaként írtam egy tanulmányt a magyarországi hangoskönyv-helyzet akkori állásáról. Ebben áttekintettem a vonatkozó szabványokat és megoldásokat, a látássérült emberek olvasási lehetőségeit, illetve javaslatot tettem egy újfajta megközelítésű szoftver elkészítésére, amellyel könnyen és gyorsan készíthet bárki hangoskönyveket (ez lett a DEX).

Letöltés: A vak és gyengénlátó emberek számára alkalmazható hangoskönyv megoldások és szabványok áttekintése (tanulmány)

Ajánlás munkaadók számára vak munkavállalók call centerekben történő foglalkoztatásához (tanulmány)

Az alábbi ajánlást 2005-ben, az azóta az FSZEK-be beolvasztott Nemzeti Gyermek- és Ifjúsági Közalapítvány call centeres projektje kapcsán állítottam össze, a témája, hogy miért és hogyan érdemes vak embereket call centeres munkára alkalmazni. A megírása idejében már sokféle információ volt elérhető a látássérült emberek közlekedéséről vagy számítógép-használatáról, ezeket részben fel is használtam, a tanulmány újdonsága a call centeres képességek leírása, illetve a problémának a munkaadók szempontjából való megközelítése: mi a teendőd, ha egy vak embert szeretnél alkalmazni a cégednél?

Az ajánlást a 2005-ben aktuális információkat tartalmazza, azóta informatikai téren jelentős előrehaladás történt, a közlekedési és egyéb információk viszont azóta is érvényesek.

Letöltés: Ajánlás munkaadók számára vak munkavállalók call centerekben történő foglalkoztatásához (pdf)