Miért zavarunk össze mindenkit a szakszavakkal?

Épp egy olyan könyvön dolgozok, amelyben több mint 50 esettanulmány segítségével mutatom be, hogy egyes csapatok különböző helyzetekben hogyan alkalmazzák az agilis elfogadási tesztet (agile acceptance testing). Mialatt a könyv vázlatán dolgoztam, ugyanabba a problémába ütköztem, amibe az automatizált elfogadási tesztek és specifikációk írásakor szoktunk. A szakszavakat következetesen kell használni, hogy értelmük legyen, de ezt egészen addig nem látjuk, amíg le nem írjuk mindet és aztán egyben meg nem nézzük őket. Ezért mondom mindig, hogy írjuk fel a dolgokat egy táblára, amikor egy elfogadási teszten dolgozunk. Amikor a könyvben szereplő interjúkat szerkesztettem, akkor láttam csak, hogy milyen következetlenül és helytelenül használjuk a folyamatleírásainkat.

Az agilis elfogadási tesztet (vagy bármilyen néven is hívjuk) végzők általában bűnösek abban, hogy összezavarják magukat és mindenki mást is, aki ezen módszerek bevezetésén dolgozik. Természetesen én is felelősnek érzem magam ebben. Sok ember különböző nevet ad ugyanannak a fogalomnak és ugyanolyan néven neveznek más-más dolgokat. Nehéz volt egy egységes történetet összeállítanom, de el se tudom képzelni, milyen nehéz lehet ezt megértenie egy olyan embernek, aki soha nem hallott ezekről a szakmai kifejezésekről.

Ha azt akarjuk, hogy az üzleti felhasználók is jobban be legyenek vonva, ami ezen módszerek egyik fő célja, akkor a megfelelő néven kell nevezni a megfelelő dolgokat és abba kell hagyni az emberek összezavarását. Például amikor az agilis elfogadási tesztben használjuk a folyamatos integrációt (continuous intergation), akkor nem igazán integrációs tesztet akarunk lefuttatni. Szóval miért használjuk ezt a kifejezést, ha tudjuk, hogy utána el kell magyaráznunk, hogy mi a különbség az elfogadási teszt és az integrációs teszt között? Amíg el nem kezdtem használni a „specifikációs műhely” (specification workshop) kifejezést az elfogadási tesztekkel foglalkozó koordinációs megbeszélésekre, addig nehéz volt az üzleti oldal képviselőit rávenni, hogy részt vegyenek rajta. De egy kis egyszerű névváltoztatás megoldotta a helyzetet. Jobb nevek használatával értelmetlen viták sokaságát előzhetjük meg, az érintetteket helyből a jó útra irányítva.

Elterjedt megközelítés a folyamat egy részének azonosítására egy használt technika vagy eszköz nevének átvétele. Jó példa erre a „feature injection”, ahol a projekt hatókörét szélesítjük tovább, az üzleti célokra alapulva. De ez csak egy módszer a sok közül, vannak más megoldások ugyanezen cél elérésére. Azért, hogy a különböző csapatok mit csinálnak más-más helyzetben, egy magasabb szintű fogalomra van szükségünk, ami az összes ilyen célú tevékenységet magába foglalja. Egy jó név leírja a várható eredményt és tisztázza a legfontosabb meghatározó elemeket is.

  A „feature injection” és a hasonló módszerek esetében a kimenet egy projekt, vagy mérföldkő feladatai, de ami megkülönbözteti a hasonló módszerektől, hogy itt az üzleti célokra összpontosítunk. Szóval azt javaslom, hogy nevezzük ezt a folyamatot inkább „projekt feladatkör levezetése a célokból” (deriving scope from goals).

Az egyik legfontosabb probléma az agilis elfogadási tesztben az, hogy kinek, mikor és mit kell írnia. Szóval szükségünk van egy jó névre, mely világosan meghatározza, hogy mindenkit be kell vonni, és ennek a fejlesztés és tesztelés előtt kell történnie, mivel az elfogadási teszteket a fejlesztési munka céljaként akarjuk definiálni. A „teszt először” (test-first) egy jó technikai név, de az üzleti felhasználók nem értik és ez nem foglalja magába az együttműködést. Szerintem beszéljünk inkább „közös pontosítás”-ról (specifying collaboratively) a teszt először vagy az elfogadási tesztek írása nevek helyett.

Sok tesztcsapat másik nagy problémája, hogy mekkora területet fedjenek le a tesztekkel. Ha csak a funkcionális tesztek automatizálásáról beszélünk, teljesen normálisnak tűnik, hogy minden számba jöhető változatot beleteszünk a tesztbe. Miért ne tennénk, ha egyszer a teszt automatizált? Nem kerül semmibe. Az elfogadási teszt egy fontos kommunikációs eszköz, amennyiben ezek nem nagyon összetettek. A funkcionális teszt helyett hívjuk inkább „szemléltetés példákkal”-nak (illustrating using examples), pontosan leírván, hogy itt bemutatjuk, hogyan kellene működnie egy funkciónak és ezt konkrét példával is alátámasztjuk – és ne említsük azt, hogy ezen teszteknek végeredménye bármilyen értéklista lehet, beszéljünk kulcspéldákról, aláhúzván, hogy mi csak annyit szeretnénk, hogy megfelelően el tudjuk magyarázni az összefüggéseket.

Ha csak az elfogadási tesztről beszélünk, akkor igen nehéz elmagyarázni, hogy miért ne ömlesszenek komplikált 50 oszlopos meg 100 soros táblázatokat a tesztbe mindenféle magyarázat nélkül. Ezt úgyis gépek fogják végezni, nem? De ezeket a teszteket nem csak gépeknek, hanem embereknek is írjuk. Tisztáznunk kell, hogy a kulcs példák nyersanyagok, olyanok, mint a nyers gyémánt. Értékesek, de nem annyira, mint azok, melyeket már méretre csiszoltak és kifényesítettek. Van egy lépés a folyamatban, közvetlenül a közös pontosítás után, melyet nem szoktak megvitatni, ahol kiírjuk a minimális attribútumokat és példákat, hogy meghatározzuk az üzleti szabályokat, címet adjunk, leírást készítsünk stb. Szerintem hívjuk ezt „specifikációk finomhangolása” (refining the specification) néven.

A finomhangolás eredménye egy időben specifikáció, „a készen van” definíciója, elfogadási teszt és egy később futtatandó funkcionális regressziós teszt. Én igazából nem akarom ezt elfogadási tesztnek nevezni, mert nagyon nehéz megindokolni azt, hogy miért szaknyelven írjunk, de mégis érthetően és könnyen elérhetően. Van egy teljesen más vita is arról, hogy az ellenőrzéseket automatikusan elfogadja a szoftver, vagy automatikusan visszadobja azokat a kódokat, amik nem felelnek meg az elvárásainknak. (http://www.developsense.com/blog/2010/08/acceptance-tests-lets-change-the-title-too/ )

Azt javaslom, hogy a finomhangolás eredményét nevezzük „specifikáció példákkal” (specification with examples), melyből azonnal látható, hogy példákon kell alapulnia, de többet kell tartalmaznia, mint a nyers adat. Mivel ezt specifikációnak hívjuk, nyilvánvaló, hogy mindenkinek törődnie kell vele, és könnyen érthetőnek kell lennie. Mivel nem tesztnek nevezzük, ezért a megrendelői oldalt is jobban érdekli és elkerüljük a kontextus alapú teszt-megközelítés tesztelés-ellenőrzés problémáját is.

Nem igazán szeretnék tovább vitatkozni azokkal, akik már kifizették a QTP licence-t, ami persze nem használható az elfogadási tesztek esetében. Amíg tesztautomatizálásról beszélünk, addig a menedzserek mindig késztetést éreznek majd, hogy valamiféle szoftvert használjanak erre, hiszen a tesztcsapatok egy eszközt használnak az automatizálásra. Az agilis elfogadási tesztek és a BDD eszközök nem versenyezhetnek a QTP-vel, ezek teljesen más problémát oldanak meg. Ezek az együttműködést segítik. Ahelyett, hogy tesztautomatizálásról beszélnénk, nevezzük inkább a specifikáció automatizálásának , ahol az információ nem torzul, „szó szerinti automatizálás” (automating literally). Az a tény, hogy szó szerint automatizálunk, segít elkerülni a programnyelveket és hogy technikai könyvtárakat használjunk közvetlenül a teszt specifikációban. Ha ez szó szerinti, akkor úgy kell kinéznie, mint ahogy fel volt írva a táblára, nem kell lefordítani Selenium parancsokra.

Miután a specifikációkat automatizáltuk, végrehajthatjuk őket, hogy ellenőrizzük a rendszert. Ennek hatása, hogy „végrehajtható specifikációkat” (executable specifications) kapunk.

Gyakran le kell ellenőrizni minden specifikációt, hogy megbizonyosodjunk, hogy a rendszer azt csinálja, amit kell és hogy a specifikációk azt írják le, amit a rendszer végez. Ha ezt regressziós tesztnek hívjuk, akkor nehéz elmagyarázni, a tesztcsapatnak miért ne adjanak még 5 millió másik tesztesetet a szép kisméretű fókuszált specifikációhoz. Ha folyamatos integrációnak (continuous integration) nevezzük, akkor is bajban leszünk, mert el kell magyarázni, hogy miért nem futtatjuk az egész rendszeren és miért nem tart az elejétől a végéig. Néhány rendszernél le kell futtatni az elfogadási tesztet a már telepített élő környezeten, ami megint csak összezavarja a integrációs teszt elnevezést. A technikai integrációs teszteket a telepítés előtt végzik, de a végrehajtható specifikációt néha utána is lefuttatjuk. Szóval ne beszéljünk regressziós tesztről vagy folyamatos integrációról, nevezzük inkább „gyakori ellenőrzés”-nek (validating frequently).

Az egész folyamatból hosszútávon az a kifizetődő, hogy tudomásunk van arról, hogy mit csinál a rendszer, könnyen olvasható formában, szemben a kódokkal. Ez hosszútávon sokkal hatékonyabbá teszi a fejlesztést és a tesztelést is, megkönnyíti az együttműködést az üzleti felhasználókkal, kapocsként működik a szoftver- és az üzleti tervezés között és mindenki munkáját megkönnyíti. Hogy ezek működjenek, ahhoz az kell, hogy a hivatkozások pontosak legyenek, mindig legyenek karbantartva és következetesen használják. Nincs szükség raktárhelyiségnyi tesztre, ami 3 évvel ezelőtti kifejezéseket használ. Az elfoglalt tesztcsapatok számára elképzelhetetlen, hogy visszamenőleg is frissítsék a teszteket, de egy nagy változtatás után szükséges visszamenőlegesen frissíteni a dokumentációkat. Szóval ne beszéljünk több száz teszttel teli mappákról hanem hívjuk inkább „élő dokumentációs rendszernek” (living documentation system). Ez nyilvánvalóvá teszi, hogy miért kell az üzleti partnereknek is hozzáférést adni és azért kell jól rendezettnek lennie, hogy mindent könnyen megtalálhassunk.

Végül még van egy kérdés, hogy hogyan is nevezzük ezt az egész dolgot. Az elfogadási teszt vagy az elfogadási tesztvezérelt fejlesztés neveknek nincs értelme, ha az elsődleges változtatásokat specifikációknak hívjuk és nem tesztnek. Úgy döntöttem, hogy a „specifikáció példákkal” (specification by example) nevet adom neki a könyvben, és remélem, más is ezt kezdi majd használni. A folyamatok nevei segítenek, hogy fejben egy összkép kialakuljon és kihangsúlyozza a fontos részeket, valamint segít csökkenteni a zavaró kifejezéseket. Az, hogy specifikációnak nevezzük teszt helyett, sokkal kevesebb magyarázatot igényel.

Szerző: Gojko Adzic