Teszt dokumentáció

2014. június 5-én, a budapesti Teszt & Tea rendezvényen elhangzott előadásom dokumentációval, dokumentációs szabványokkal foglalkozó részének bővített változata.

A legtöbb mérnök a teszt dokumentáció készítése alatt unalmas, szükségtelennek tűnő irodai munkát ért, amely megszakítja az egyébként produktív, érdekes, intellektuális tesztelői tevékenységet. Nem véletlenül. A szövegek jelentős része jellemzően "másol-beilleszt" módon keletkezik, nem informatív, nem segíti elő a hatékonyabb tesztelést. Az emberek érzik, hogy a készülő dokumentumokat senki sem fogja olvasni, létrehozásuk csak a munkájukat szabályozó folyamatok kielégítése miatt történik.

Miért támasztanak értelmetlen dokumentációs elvárásokat a munkafolyamat leírások?

Véleményem szerint részben a teszt dokumentációs "szabványok" (pl. IEEE 829, ISO 9000-3, CMM) erőltetett követése, részben a dokumentációt körülölelő alaptalan hiedelmek miatt. (A két tényező sajnos egymást is erősíti.)

Tipikus mítoszok például:

• professzionális tesztelés nem létezik nagy mennyiségű, jellemzően prózai formában írott dokumentáció nélkül (ld. teszt terv, teszt eset leírások stb.)
• ezeknek a dokumentumoknak a fejlesztés minél korábbi szakaszában meg kell születnie és formális felülvizsgálaton átesnie
• egy adott környezetben, projektben működő dokumentációs gyakorlat jól működik majd egy másik környezetben is
• a szabványok dokumentációs ajánlásainak követése megfelelő lépés bárhol és bármikor
• egy tapasztalatlan tesztmérnök fejlődését az segíti elő (akkor tanul gyorsan), ha terjedelmes dokumentációt kap a kezébe
• a részletesen dokumentált teszt esetek garantálják a megismételhetőséget, könnyen végrehajthatók tapasztalan tesztelők által is és védenek a munkaerő-vándorlással szemben (a dokumentáció helyben marad).

A dokumentáció szerves része a formalizált teszt folyamatoknak. A dokumentációs szabványok valamiféle keretrendszert, struktúrát és egy definícióhalmazt próbálnak nyújtani, teszik mindezt az ajánlott dokumentumok leírásával, az egyes dokumentumok közötti kapcsolatok ismertetésével ill. a munkafolyamatokban betöltött szerepük meghatározásával.
A szabványok nem kötelező erejűek. Születésüket a tesztelői közösség a '90-es években kezdetben izgatottan fogadta. A gyakorlatban viszont az alkalmazásuk komoly problémákhoz vezetett - olyan problémákhoz, amelyeket nem lehetett a szabványok inkompetenciából adódó helytelen használatának a számlájára írni.

A tapasztalatokra építve a szakterület több nagyágyúja is megkérdőjelezte a szabványok szükségességet. Az IEEE 829-ről Cem Kaner 2003-ban úgy nyilatkozott, valószínűleg több kárt okozott, mint hasznot ("has probably done more harm than good" [1]), James Bach egyértelműen ártalmasnak ("harmful document") nevezte. Liberalizációs szándékkal mindketten tagjai voltak ekkor a IEEE 829 frissítését célzó munkacsoportnak, sikertelenül. (A viták később sem szűntek meg, a most születő IEEE 29119 szabványt is komoly ellenérzések övezik a tesztelői közösségen belül.)


Tekintsük át a dokumentációs szabványok jellemző problémáit!

Arra a beágyazott feltételezésre épülnek, hogy a fejlesztés szigorúan fázisos életciklusban zajlik (ld. V- ill. vízesés modellek). Ennek megfelelően a teszteket a fejlesztés korai fázisban, részletesen dokumentáltan létre kell hozni, majd ezek a későbbiekben nem változnak.

A tesztelés egyik alapvető problémája az, hogy végtelen számú lehetséges tesztet hajthatnánk végre, de csak egy nagyon kis részhalmaz végrehajtására van lehetőség. A teszt tervezés többek között arról szól, mi kerüljön ebbe a részhalmazba. Nyilván minél jobban ismerjük ill. értjük a készülő terméket, annál okosabban tudunk válogatni a tesztek között. A projekt korai szakaszában pedig értelemszerűen kevesebb információval rendelkezünk.
A jó tesztelő folyamatosan tanul. Ahogy a projekt előrehalad egyre mélyebben lát bele a rendszerbe, fokozatosan fejlődnek azok az érzékei, képességei, amelyek fontosak az adott projektben. Újabb és újabb részleteket tud meg például a leendő a felhasználókról, az applikációról, ennek különböző felhasználási módjairól, az esetleges kockázatokról, a tesztek kivitelezésével kapcsolatos problémákról. Ahogy a tudása nő, más szemmel látja majd a korán megtervezett tesztjeit, vagy azokat a teszteket, amelyeket éppen érdemes lenne végrehajtani. Magának a programnak az érettsége is változni fog az idő előrehaladtával: más jellegű tesztekre van szükség a fejlesztés korai szakaszában, mint később, amikor már elért valamilyen érettségi fokot a program.
(Az IEEE 29199 már próbálja figyelembe venni az agilis fejlesztés eltérő igényeit.)

Nagy mennyiségű információ formális, prózai szöveges rögzítését igénylik, tekintet nélkül az ehhez kapcsolódó munkamennyiségre ill. költségekre.

A szabványok teljesen figyelmen kívül hagyják azt a tényt, a rendelkezésünkre álló idő korlátos (a munka pedig mint fentebb jeleztem, végtelen), azaz mérlegelni kell a dokumentálás ill. azon tevékenységek között, amelyet egy tesztelőnek érdemes vagy kell elvégeznie. (A dokumentációra fordított idő másra már nem fordítható.) Nem írnak az ajánlott struktúrában megszülető dokumentumok jellemzően óriási költségéről sem (létrehozás, karbantartás).

Elterelik a figyelmet a tényleges célokról.

Túlságosan csábító a különböző típusú, terjedelmes, komplex dokumentumok elkészítésére koncentrálni a tervezés során, ahelyett hogy minél jobb elképzeléseket próbálnánk létrehozni azzal kapcsolatban, hogyan is teszteljük az adott rendszert. (ld. goal displacement)

Univerzális, kulcsrakész megoldást próbálnak nyújtani.

A szabványok teljesen figyelmen kívül hagyják a projektek környezeti jellemzőit, illetve azokat az összefüggéseket, hogy ezek a jellemzők hogyan befolyásolják a projekt tényleges dokumentációs igényeit. Nem nyújtanak semmilyen iránymutatást az igények feltérképezésével, analízisével kapcsolatban. Felelőtlenség egy javaslatlistát kőbe vésni és „ipari szabvány”-nak nevezni, amikor a tényleges dokumentációs igények projektről projektre, cégről cégre, területről területre változnak.

A hangsúly jellemzően a dokumentumok terjedelmén és a formalizmuson van.

Ez ágyaz meg annak a hitnek, hogy professzionális tesztelés nem létezik nagy mennyiségű dokumentáció nélkül. A több, terjedelmesebb dokumentum alaposabb tesztelést sugall. (Egy külső szemlélőt -pl. menedzsert, auditort- meggyőzhet a teszt terv terjedeleme arról, hogy a tervezéssel tényleg eltöltött annyi időt a tesztelő, mint amennyit állít, viszont nem szolgáltat információt arról, hogy a megfelelő módon töltötte -e el ezt az időt.)

Azt vizionálják, hogy a tesztelés jól körülhatárolható, absztrakt egységekből áll (teszt esetek) és minden egyes teszt esetre külön dokumentációt kell készíteni. 

Ez végtelenül ostoba dolog, sajnos a teszt eset menedzsment eszközök többségét már ez alapján a feltételezés alapján készítették. Ha van 50 teszt esetünk, amelyek mindegyike tartalmaz egy bizonyos dolgot, és ezt a dolgot mi megváltoztatjuk, akkor minden egyes teszt esetet meg kell változtatnunk. Ha az egyes teszt esetek dokumentációja teljesen független egymástól, akkor változtathatjuk meg az összes dokumentumot. Mondanak -e a valamit a modularizáció, komponens, metódus szavak a programozásban?

Egyes tesztelési paradigmák, módszerek ismeretlenek a szabvány készítői előtt.

Bizonyos eszközök képesek nagy mennyiségű tesztet végrehajtani és kiértékelni, például bemenő adatok millióinak, vagy tetszőlegesen hosszú eseménysorozatnak a véletlenszerű létrehozásával. Ezeknek a teszteknek a dokumentálása egyszerűen nem illik bele a szabványok által vázolt világképbe. A dokumentáció ilyenkor elmarad, vagy vagy más módon történik. Szélsőséges esetben akár tesztek létrehozása is elmaradhat a kapcsolódó dokumentációs nehézségek miatt.

A szabványok által javasolt sablonok használata kétélű fegyver.

A sablonok segíthetik a kevésbé gyakorlottakat az információ struktúrálásában és prezentációjában, de súlyos tévedés azt hinni, hogy kiküszöbölik majd a kompetencia hiányából fakadó problémákat, vagy helyettesítik a teszteléshez (vagy teszt dokumentáció írásához) szükséges készségeket. Elősegíthetik egységes dokumentációs kép kialakítását a külvilág számára, de komolyan korlátozhatják az emberi gondolkodást.
Paradox módon a sablonok akkor segíthetnek nekünk, amikor igazából nincs rájuk szükség. Értenünk kell, milyen információt hordoznak az egyes fejezetek, miért szerepel ott ez az információ, mikor hagyhatók ezek adott esetben el. Amennyiben mindezekkel tisztában van a tesztelő, nincs szüksége a sablonra. Aki önállóan is képes hatékony teszt dokumentáció írására, annak a sablon felgyorsíthatja a munkáját. Ha viszont valaki nem képes sablon nélkül dolgozni, akkor számára nem sablon kell, hanem egy tanár, mert ez annak a jele, hogy önállóan még nem tudja végezni az adott feladatot.


Hogyan döntsük el, hogy érdemes -e a szabványok által megfogalmazott ajánlásokat figyelembe venni?
Milyen projektek esetén érdemes ill. nem érdemes ezeket követni?

A megoldás a már említett dokumentációs követelmények analízise. Azaz annak eldöntése, hogy milyen dokumentumokra, pontosabban (mivel maga a dokumentum csak információhordozó, közvetítő közeg) milyen információ rögzítésére és milyen célból van szükségünk - még mielőtt azzal foglalkozunk, hogy hogyan hozzuk létre ezeket.

Gause és Weinberg Exploring Requirements c. könyve remek bevezető a követelmények analízisébe ill. ezek felderítéséhez környezetfüggetlen kérdések megfogalmazására és használatára. A dokumentációval kapcsolatos, tipikus kérdések lehetnek például:

• Milyen információs céljai vannaka teszt csoportunknak?

• Eszköz vagy termék a teszt dokumentáció? 
• Kik a célközönség, a leendő olvasók?
• Milyen tudást feltételezünk róluk?
• Milyen információt szeretnénk közölni velük?
• Milyen hosszú ideig  lesz szükség a dokumentumra? 
• Meddig lesz érvényes a dokumentált információ, mennyire valószínű, hogy változni fog?
• Hogyan osszuk fel időben a dokumentált munkamennyiséget (tudván azt, hogy pl. egy hónap múlva többet tudunk, mint most)?
• A teszt stratégiánk a felfedezésre épül inkább, vagy előregyártott tesztek végrehajtására?
• stb.

Mindezek mellett tartsd még szem előtt a következő irányelveket:

• A terjedelem nem jelent minőséget, vagy alaposságot.
• A próza helyett használhatsz tömörebb, alternatív módszereket, pl. vizuális formátumok (mindmap), ellenőrző listák (checklist). 
• Kerüld el a túlságosan korai, vagy túlságosan formális dokumentáció okozta csapdákat! A terveid menet közben változnak majd. Törekedj retrospektivitásra! Kevésbé érdemes azt nagy részletességgel rögzíteni, hogy "mit akarok majd hetekkel később csinálni?", mint azt, hogy "mit csináltam ma? mit láttam, tapasztaltam? mi és hogyan hasznosítható mindezekből?"

Illetve tedd fel a legfontosabb kérdést: Mi az a létező legolcsóbb dokumentáció, ami még elegendő?

Források, ajánlott olvasnivaló

[1] C Kaner, J Bach, B Petticord: Lessons Learned in Software Testing
     Chapter 6: Documenting Testing
[2] C Kaner: Requirements for test documentation
[3] J Bach: Fighting Bad Test Documentation
[4] J Christie: When Documentation is a Waste of Time
[5] M Bolton: Worthwhile Documentation
[6] F Charles: Unburdening Testing. Finding the balance point for test documentation
     EuroSTAR Conference presentation (2012)
[7] A Hodder: Using Mind Mapping Software as Visual Test Management Tool