A Given-When-Then tragédia

Mikor csak egy kalapácsod van, hirtelen minden szögnek fog tűnni. Több mint két évtizednyi elemzői tapasztalattal a hátam mögött bizton állíthatom, hogy legalább 3 dolgot kell specifikálni egy tervezett rendszerrel kapcsolatban.

1. A rendszer kinézete
2. Milyen adatokon, milyen számításokat fog kivitelezni
3. A rendszer elvárt viselkedése

A tradicionális eszközök

Az internetet megelőző időkben a felhasználói élményt kevésre tartották; a rendszerek legtöbb felhasználója a vállalatok belső kollégáiból állt. Akiknek nem volt választási lehetőségük, ha napi feladataikat el akarták látni. A használhatósággal kapcsolatos bármilyen gondolkodás az ergonómiára, illetve a zavaros képernyőkön elkövethető veszélyesebb hibák elkerülésére szorítkozott.

Ennek nyomán viszonylag egyszerűen megjelenített prototípusokat használtunk tervezett rendszereink leírásához. Néhányan Visio-t vagy Powerpoint-ot használtak, az én preferenciám az Excel volt, prototípizáláshoz gyorsan használható, illetve kollégáim körében népszerű eszköz volt.

Az adat és a kalkulációk leírására üzleti domain modellt használtunk.

A rendszerünk külső felhasználókkal (emberek és egyéb rendszerek) való kapcsolatait felhasználási esetekkel írtuk le. Erre egységes formátum nem volt, de mindenkin észre lehetett venni Alistair Cockburn hatását. (Alistair Cockburn “Writing Effective Use Cases”)

A rendszerelemzés klasszikus módja szerint az adat, a rajta kivitelezendő transzformáció, illetve az elvárt viselkedés absztrakt leírása nyomán fejlesztették a szoftverterméket.

Valódi felhasználók és példa alapján leírt specifikáció

Az internet elterjedése nyomán valódi felhasználók kezdték a vállalatok rendszereit használni. A valódi felhasználónak viszont lehetősége volt választani. Ennek nyomán a felhasználói élmény kutatása, és az ennek megfelelő tervezés a termékfejlesztés és a rendszertervezés megkerülhetetlen részévé vált.

Az egyszerű prototípusokat, szofisztikált, részletes, a szoftverfejlesztés megkezdése előtt, valódi felhasználókkal tesztelt prototípusok váltották fel. Részletes prototípusok a rendszer specifikáció részévé váltak, nem egyszer pixel pontossággal.

Az internet gyors és rövid átfutású fejlesztési feladatokat hozott. A rövid átfutás automatikus tesztelést igényelt, illetve teszt alapú fejlesztéshez (TDD) vezetett. Példa alapján leírt specifikáció kellett az teszt alapú fejlesztéshez.

Absztrakt domain modellek helyett, adatot, transzformációt példák alapján, táblázatokban specifikálunk, a tranzakciók kapcsolt formális leírásával.  A példákat jellemzően a tesztelővel és az üzleti terület képviselőjével közösen írjuk le; később egyes esetekre JUnit implementáció is készül. „Given-When-Then”-t nem használtunk.

Az absztrakt felhasználási eseteket és állapot átmeneti diagramokat „Given-When-Then” formátumú felhasználási példák váltották fel.

Az egyik hátulütője a felhasználási eseteknek az volt, hogy az üzleti elemzők, használatukkal könnyedén lemondtak az alternatív utak kereséséről, amely csak a „Pozitív út” mentalitásba torkollott.

A „Given-When-Then” formátum viszont elősegíti a „Pozitív út” azonosítását, majd a „három haver” (https://www.softwaretestinghelp.com/3-amigo-principle/) koncepció használatával minőségi és technikai útvonalak felderítése történik meg. Ezek általában elfogadási kritériumként jelennek meg később.

Első felvonás

Ha Shakespeare írt volna egy darabot a „Given-When-Then”-ről, valószínűleg ezzel a sorral kezdődne: „A világ úgy tűnik, szegekből van, és neked egy kalapács van a kezedben”

Bár a „Given-When-Then” remek eszköz leírni az interakciókat, állapotokat, viselkedést; adat és transzformáció leíráshoz kevéssé megfelelő. Alább egy gyakorinak nevezhető rossz példa a „Given-When-Then” használatára adat és transzformáció leíráshoz:

• Given <megfelelő piaci adat létezik egy táblában>
• When <szükséges esemény, ami kiváltja a transzformációt megtörténik>
• Then <a bemenetekből származtatott eredmények megjelennek egy másik táblában>

A fentiekhez hasonló alkalmazása a „Given-When-Then” -nek elősegíti a nagyra becsült automatizálást a Cucumber és társeszközei, pld. a Specflow segítségével, de csökkenti a probléma általános megértését és az olvashatóságot.

Második felvonás

Ugyancsak gyakori rossz példa, a „három haver” együttműködése nyomán azonosított szkenáriókat user story elfogadási kritériumnak tekintjük. A tesztelő ezek után Cucumber formátumú feature file-á alakítja ezeket, párhuzamosan a fejlesztéssel, ahelyett, hogy azt megelőzően tenné. A tesztelő redukálása gépíróvá, magában egy tragédia. A fentiek azt jelentik, hogy az üzleti elemző nem látja a legfrissebb „Given-When-Then” sorokat, ennek nyomán kommunikációs lyuk keletkezik közte és a fejlesztők, tesztelők között. A Cucumber, ahelyett, hogy rendszer specifikációs könyvtár lenne, csak teszt automatizálási eszköz lesz.

Harmadik felvonás

A „Given-When-Then” online közösségben az üzleti elemző és a programozó/tesztelő közötti távolság mindennapi téma. Az üzleti elemzők gyakran nem látják a feature file-okat és és nem értik teljesen a folyamatot. Nem látnak értéket a Cucumber-ben, csak egy teszt automatizálási eszközként tekintenek rá.

Az eredmény a nagy semmi.

Hogy ezt az hiányt kitöltsék, a fejlesztők leírtak pár, a fejlesztőknek kedves folyamatot, mert itt ők mondják el az elemzőknek, hogy a fejlesztők szerint az üzleti elemzőnek hogyan kellene a munkáját csinálnia. Az „Event storming” és az „Example mapping” technikák népszerűek tréningeken és konferenciákon. Vicces, aktív megbeszéléseket lehet ezek alapján szervezni. Egyszerű és egyértelmű megtanulni őket, komplex eredményeket hoznak, és nem felelnek meg az üzleti elemzők igényeinek. Akiknek alapfeladata a komplex rendszerek definiálása és dokumentálása. Az üzleti elemző lét feltételezi a struktúrált tanulási technikák gyakorlati úton való megvalósítását.

A tragédia az. hogy a „Given-When-Then” még nagyobb semmit teremtett.

Az agilis elgondolás eredendően a munkát elvégzők és ebben másokat támogatók elképzelései alapján indult, kivéve az üzleti elemzést, ahol a fejlesztők gondolnak ki üzleti elemzők számára feladatokat. Ahol a figyelő, nem az elvégző definiálja a folyamatot.

Finálé

Remélhetőleg rájövünk majd, hogy a „Given-When-Then” interakciókat, állapototokat, viselkedést leíró módszer, egyúttal arra is, hogy adat és transzformáció leírására nem alkalmas – ezen feladatokra Excel alapokon, megfelelő módszereket és eszközöket kell fejleszteni.

A „Given-When-Then” közösségnek feladata megszólítani az üzleti elemzőket, és figyelni a problémáikra, igényeikre. Előzetes elgondolásokon épül megoldásokat el kell dobni, és olyan lehetőségekben gondolkodni, amelyek az üzleti elemző és a fejlesztői közösség közötti kommunikációs problémákat feloldja.

Mikor majd nem csak kalapács lesz a kezünkben, látni fogjuk, hogy a világ nem csak szögekből áll.

Forrás: https://theitriskmanager.com/2019/04/06/the-tragedy-of-given-when-then/