Trompler Tamás írása. Köszi Tamás ?
Az eseménynek ezúttal a Corner Six irodaház adott otthont, ahol több, mint negyvenen gyűltünk össze.
Első alkalmas résztvevőként már a liftből kiszállva egyértelművé vált, hogy jó helyen vagyok, rögtön a találkozó helyszíne fogadott illatos pogácsával és szimpatikus hangzavarral. A szoba méretét meghazudtolóan sokan voltunk, mégis egyfajta megérkezés-élményem volt a sok ismerős arcnak és a pozitív energiának köszönhetően.
Házigazdánk, Gintl-Reszegi Marcsi felvezetője, mint mindig, most is emlékezetes – mi más lehetne a kezdés, mint egy esküvő üzleti elemzői szemmel? Néhány hónapos projekt, melynek kimondottan vagy kimondatlanul, de egyértelműen a menyasszonyi ruha (és persze annak viselése) a csúcspontja a mi kontextusunkban is. Elvégre megfogalmazódnak követelmények, elfogadási kritériumok, ahogy közelít a nagy nap, megjelenik a scope creep és vele együtt a change requestek is, de a sok (ruha)próbával szinte garantálható a siker és a boldogság.
Mielőtt mindenki elkezdi a saját megtörtént vagy jövőbeni esküvőjét ilyen nézőpontból kielemezni, visszatérünk a jelenbe, mert azért mégis arról lesz szó, hogyan kerülhet közelebb egymáshoz az üzleti elemző és tesztelő gondolkodása.
De miért is van erre szükség? Hiszen készek a követelmények, most már hátra lehet dőlni, elvégre üzleti elemző nem tesztel, majd az élesítést követően biztos megkapjuk a visszaigazolást, hogy mi mindent jól csináltunk. Persze a valóság nem ilyen, minden erőfeszítésünk ellenére is előfordulnak csúszások, de jellemzően tesztelés közben. Általában itt kezdenek a projektek „optimalizálni”, rövidíteni a tesztelést, pedig éppen a teszteléssel lehetne kockázatot csökkenteni. Mindez pedig oda vezet, hogy megrendül a bizalom mind a projektet, mind a terméket illetően.
Az üzleti elemzés, ha megadják neki a teret, ezt a bizalmat tudja megteremteni, mivel az ötlettől az élesítésig végig kíséri a megoldást.
De hogyan lehetne ezt tényleg jobban csinálni, mit tudnánk tenni a hatékonyság és tudatosság érdekében, hogy mindez könnyebb legyen? Erről fognak előadóink beszélni.
Sándor Zsolt (Modeldriven.hu) esettanulmányán keresztül bepillantást szerezhetünk családja működésébe: egy hétköznapi esetet mutat be, hogy is lehet a követelmények rögzítésének időszakában a tesztelés gondolkodást behozni egy ellentmondásoktól mentes és jó minőségű követelmény halmaz érdekében.
Forgács István, aki eddig sikeresen titkolta életkorát, a Harmony-t fogja bemutatni, mely nem csak tesztet támogató megoldás, de egyben gondolkodásmód is, nem csak a tesztelőnek fontos és értékes, hanem már követelmények megfogalmazásakor, tesztesetek és elfogadási kritériumok definiálásakor is támogatni képes bárkit, aki üzleti elemzéssel foglalkozik.
Gyakorlott meetuposok itt már sejthették, hogy dolgozni is fogunk. Miután tisztáztuk a business és a solution architektúra közti határvonalat és a kettő kapcsolatát, Marcsi közös gondolkodásra hívott minket. Nem kettő, nem is négy, hanem három gondolatot kért, hogy vessünk postitre, melyeket természetesen páros megvitatást követően a bátrak a meetup végén közkinccsé tehettek.
Zsolt bemutatója következett, aki saját életből hozta nekünk az előszobabútor esetét, hogy egy kicsit más is legyen, elvégre nem csak szoftverfejlesztéssel foglalkozunk, mással is lehet szemléltetni ezt a tevékenységet.
Helyzetük ismerős lehet: az előző projekt go-live, avagy a lakodalom megtörtént, közös lakásba költöztek és szépen berendezték, de mégis maradt egy kihasználatlan sarok, ahova kellene valamilyen bútor. Zsoltban felmerült a kérdés, hogy ne inkább optimalizáljunk és csak a szükséges dolgokat tartsuk-e meg, de sejthető a döntéshozói nyomás: itt bizony előszobabútor lesz.
Megbeszélték az alapvető elvárásokat, megkerestek számos szakembert, de a legbuzgóbbtól is csak egy Móricka-ábrát kaptak terv gyanánt.
A kapott eredményeket, tapasztalatokat beépítették a követelményekbe. Mindezzel karöltve sikerült a kivitelezővel közös nyelvet kialakítaniuk, aki ennek alapján további javaslatokkal élt. A környezeti adottságokra már ő hívta fel a figyelmet: a biztosíték tábla, konnektorok mind fixek, ezeknek elérhetőknek kell lenniük? Lesz-e szőnyeg, mert egy túl alacsony egy fiók kihúzását megakadályozhatja. Kiderült, hogy a választott anyagok, színek nem mind elérhetők, alternatívákat kellett választani helyettük.
Annak köszönhetően, hogy mindezekre rászánták az időt, kockázatot csökkentettek, megnőtt a bizalmuk a kivitelezőt illetően, és általában maximalizálták az esélyét, hogy olyan lesz a termék, amire vágynak. A végeredményre még sajnos várni kell, de Zsolt ígérte, hogy meg fogja osztani, ha elkészült.
A gondolkodásmódot a magánéletbe is érdemes tehát tudatosan beépíteni, hosszú távon megkönnyítheti az életünket.
István bemutatójával folytattuk, megismerhettük a Harmony-t, mely egy modell alapú no-code teszt design automatizálást támogató megoldás.
Azt, hogy érdemes automatizálni a tesztelést, tudjuk – a manuális tesztelés idő és költség igénye, illetve az egyre sűrűbb release-k miatt sem reális manuálisan végig tesztelni egy megoldást. A teszt automatizáló mérnök a tesztek végrehajtását felel, de a designt is lehet automatizálni. A hagyományos kódolás alapú módszerek lassúak, ráadásul implementációtól függenek, pedig a tesztek definiálásakor még függetlenek az esetek.
A teszt design gondolkodásmód és módszertan. Hogyan készítjük el a teszteket, ami megtalálja a hibákat. Honnan tudjuk, hogy már nem kell további teszteket létrehozni. Mindezeket aszerint lehet meghatározni, hogy a szoftver milyen kockázatok mentén működik.
Erre kínál megoldást a double MBT, avagy model based testing, melyet a Harmony megvalósít.
A követelmények és az implementáció közé épülve a modellek adják ennek a módszertannak alapját.
A követelmények, user storyk alapján elkészített magas szintű modellekból absztrakt tesztek generálhatók, melyek gyakorlatilag élő kapcsolatot reprezentálnak a specifikáció és a program között. Persze tökéletes specifikáció nincs, de bármilyen eltérés a modell alapján a tesztek által kimutatható akár a követelmény, akár a tesztek vonatkozásában. Ezek a tesztek még csak ember által értelmezhetők, azonban gép számára nem futtathatók.
A modell gyakorlatilag a teszt első manuális végrehajtásával jön létre, és ebből kigenerálható és ismételhető bármilyen futtatható teszt.
A módszer előnye, hogy nagyon gyors, nem kell kódolni és nem szükséges előre tudni az elvárt eredményt, a kattintgatás mentén történik az ellenőrzés, továbbá minimális kódolással további tesztek is létrehozhatók vagy kombinálhatók. Amennyiben a követelményekben vagy a programban változás következik be, csak kézzel újra kell futtatni a releváns esetet, és kész is a karbantartása.
A Harmony célja a teszt design és a kód generálása, viszont teszt végrehajtásra nem alkalmas.
Számos, üzleti elemzők számára is releváns előnye van, ráadásul pl. JIRA-val is integrálható. Használatával megvalósul az action-state modellezés, azaz követelmények és modell lépések kötése, ami véleményem szerint az üzleti elemző számára a traceability során nagyon értékes lehet. A modellekből pedig generálhatók gráfok, ún. statechartok, melyek kiválóan alkalmasak a teljesség ellenőrzésére.
Egy példán keresztül is megnéztük a teljes design folyamatot, az ATM-ek kártya PIN ellenőrzését vettük célba. Végig vettük a műveletek lehetséges kimeneteit, a követelményeket és a folyamatot. Az ezekből létrehozott modellek és statechart alapján finomított és javított verziókat megnéztük, és eljutottunk a teljes követelményhalmazig. Nagyon tanulságos volt főként az utóbbi, azaz hogyan tudják a tesztek befolyásolni, kiegészíteni a követelményeket.
Az előadás során számos kérdés felmerült a jelenlévőkben. Érdekes volt látni, hogy az automatizált teszt végrehajtás mennyire nem elterjedt, és a kérdésekből kiindulva magát az automatizálást is fontos kontextusban értelmezni.
Az automatizált teszt végrehajtás alapja, hogy a tesztesetek futtatása egymástól független és megismételhető.
Ebből következik, hogy azokat vagy mindig friss környezeten hajtjuk végre például a kiinduló állapot visszaállításával minden futtatást megelőzően, vagy eleve olyan esetekkel dolgozunk, melyek futtatását követően törlésre kerülnek az általuk létrehozott adatok. További alternatíva az esetek oly módon történő kialakítása, hogy azok a kiinduló állapottól függetlenek, de ez esetben számolni kell a létrehozott adattömeggel.
A legtöbb kérdés arra irányult, hogyan automatizálható a teszt akkor, ha a fentiek nem lehetségesek. Például perzisztens környezetben, ahol nem megoldható rendszeres visszaállás annak integrált jellege miatt, vagy nemkívánatos bizonyos tesztesetek (pl. havonta futó folyamatok ellenőrzése) miatt. A beszélgetés során arra jutottunk, hogy ezeket másképp kell tesztelni, elkülönítve az automatizált eseteket a manuálisan végrehajtottaktól. Ez történhet akár több környezet használatával is: esténként futnak az automatikus esetek az egyik környezeten, napközben pedig egy másik környezeten tesztelnek a felhasználók.
A tesztkörnyezetek kialakítása külön tudomány. A Harmony számára, de általában az ilyen fajta automatizált tesztekhez sem kell nagy adatbázis, a lényeg a sokféle eset korlátlan ismételhetősége. Emiatt tehát kontextusban értendő ez a fajta tevékenység, mindig célhoz kötötten kell a rendelkezésünkre álló eszközöket használni és a teszteket végrehajtani. Fontos megjegyezni, hogy egyetlen módszerrel sem lehet 100%-ban automatizálni a végrehajtást, a 60-70% már nagyon jó arány, a fennmaradó esetek manuális végrehajtással fedhetők le.
Mivel a kód és a teszt is a követelményekből adódik, akár a követelmények változásból fakadóan lehet, hogy változtatni kell a teszteken is, de a változó kód is okozhat ilyet, ha pl. felület viselkedését érinti. Ha már kódnál tartunk: a statikus kód analízis is külön tudományág, mivel a módosuló kód hatását nem tudhatjuk előre.
Felmerült kérdésként a Harmony különböző eszközökön történő használata. Bár a modellezés korlátozás nélkül lehetséges, a Harmony fókusza egyértelműen a Cypress és maga a kód generálás is webes megoldásokra való. Az alacsony szintű modellek Gherkin nyelven vannak, ebből generálható kód mobileszközre is.
Azután, hogy István előadásával betekintést kaptunk a teszt automatizálásba, Marcsi újra megmozgatta a társaságot, kollaboráció következett.
Akár a tesztelés világából érkeztünk, akár üzleti elemzéssel foglalkozunk, kicsit a Harmony szakértő csapata lettünk és csoportosan megbeszéltük, hogy mi segítené a munkánkat, hogyan lehetne még tovább fejleszteni, javítani a Harmony-t.
A témában rengeteg energia volt, sok ötlet született, és azt is megtudtuk, hogy a pogácsa remek katalizátor és beszélgetést is lehet vele kezdeményezni.
A zárszót követően néhányan még maradtunk és folytattuk a brainstormingot, először a témánál maradva, majd attól egészen eltávolodva születtek ötletek, kíváncsian várom, lesz-e bármelyikből kezdeményezés. Másnap reggel munkába menet átható nyugalom érzése fogott el, mintha már megérkeztem volna. Gondolatban visszarepültem a meetup végére, felidézni a beszélgetéseket, közös ötletelést, mielőtt elbúcsúztunk egymástól. Megerősítette bennem, hogy mennyire fantasztikus ez a közösség, melyhez öröm és megtiszteltetés tartozni. Már várom a következő találkozót.
Köszönjük Tamásnak a remek összefoglalót, az előadóknak pedig a közreműködésüket a meetupon. Köszönöm!
