Társkiadványunk, az infoworld.com szerzőjének, John Ferguson Smartnak „A better approach to software testing: Do it before you code" című cikke alapján a magyar változatot írta: Odrovics Szonja
A módszertan neve acceptance-test-driven development (ATDD), azaz magyarítva kb. átvételi vizsgálatokon alapuló fejlesztés. Az acceptance testek, vagyis az átvételi vizsgálatok koncepciója természetesen nem újdonság; a hagyományos minőségbiztosítási eljárások is azon alapulnak, hogy mielőtt a terméket késznek nyilvánítanánk, tesztekkel ellenőrizzük, vajon megfelel-e bizonyos minőségi követelményeknek. A módszer újdonsága abban rejlik, hogy ezekre a tesztekre és megtervezésükre nem a tervezési, majd a fejlesztési folyamatok lezárulta után, azoktól szinte függetlenül kerül sor, hanem e folyamatok szerves részeként, a kezdetektől végigkísérve azokat.
A hagyományos waterfall-modell egyik legnagyobb hátránya, hogy ha egy hibára ilyen kései fázisban derül fény, az nagymértékben megnehezíti a kijavítását még akkor is, ha a probléma viszonylag könnyen javítható, kisebb kódrészletet érint. Ennek eredményeképpen növekednek a javítás költségei, a fejlesztőcsapat elvesztegetett ideje, és csúszik a leadás határideje.
Az ATDD teljesen más megközelítésből indul ki: ennek megfelelően az átvételi vizsgálatokat közös munka eredményeképpen, még a fejlesztési munkák megkezdése előtt határozzák meg. A tesztelés így már nem a QA (Quality Assurance, minőségbiztosítás) csapat belügye, hanem olyan közös feladat, amely a tesztelőkön kívül nemcsak a fejlesztőket, de a termékmenedzsereket és az üzleti elemzőket is bevonja. Ez lehetővé teszi, hogy már a tervezési fázisban is minden résztvevő átlássa és megértse a tesztelés problémáinak jelentőségét.
Emellett az átvételi tesztek nem szeparálódnak és nem száműzetnek a fejlesztést követő időszakra, hanem automatikusan és a teljes fejlesztési folyamatba integrálva, azt végigkísérve valósulnak meg. Ennek következtében a hibák gyorsan a felszínre kerülnek, olcsóbban és gyorsabban javíthatók, a tesztelők munkaterhelése pedig egyenletesebben oszlik el, nem koncentrálódik a munkafolyamat végére. Összességében a csapat gyorsabb és jóval hatékonyabb reakciókra képes, ami különösen a kezdeti specifikációk változása esetén jelenthet óriási versenyelőnyt.
ATDD a gyakorlatban
Érdemes közelebbről is megnézni, hogyan működhet az ATDD egy agilis fejlesztési projektben. Egy szoftverprojekt alapvető célja, hogy bizonyos számú kiemelt feature-t (funkcionalitást, képességet) kínáljon a felhasználóknak. A feature arra vonatkozóan képvisel értéket, amit az applikáció a felhasználónak nyújt, méghozzá oly módon, hogy ez az érték szórólapon vagy sajtóközlemény formájában kommunikálható. Ilyen lehet például egy ingatlanlízing-menedzsment applikáció esetében a karbantartásmenedzsment.
A feature-ök általában túl nagyok ahhoz, hogy egyszerre implementáljuk őket, ezért általában kisebb, kezelhetőbb egységekre bontjuk azokat. Agilis körökben ezeket az egységeket általában ún. user storyk formájában írjuk le, megfogalmazzuk egy-két rövid mondatban, hogy egy funkcionalitás egy bizonyos elemétől mit vár a felhasználó. A karbantartásmenedzsment feature esetében ilyen lehet például a munkarend felállítása vagy a számla jóváhagyása.
Ezek a user storyk adják azoknak a beszélgetéseknek az alapját, amelyek segítenek tisztázni az igényeket, majd megszülethet belőlük az, amit végül implementálni kell. Ezeket a követelményeket végül célok és számon kérhető átvételi kritériumok formájában fogalmazzák meg, például így: „A felhasználó abban az esetben hagyhatja jóvá a számlát, ha annak összege megegyezik vagy kisebb a megállapodott maximum árnál." Vagy: „A felhasználó nem hagyhatja jóvá a számlát, ha annak összege túllépi a megállapodott maximum árat."
Az átvételi kritérium meghatározza, hogy egy bizonyos user stroy mikor áll készen a forgalomba helyezésre, de ez nem csak annyit jelent, hogy rögzíti, mit kell tesztelni az iteráció végén. Az átvételi kritérium közös feladatként jelenik meg már az iteráció kezdetén, a fejlesztők, a tesztelők és a termékmenedzserek bevonásával. Ennek eredményeképpen elősegíti azt is, hogy a csapat minden tagja konkrét és részletes vízióval rendelkezzen a megvalósítandó feature-ről, így csökkentve a félreértésekből, illetve az igények, a rossz vagy hiányos errőforrás-felmérésből adódóan rosszul kijelölt határidők és a megvalósíthatóság közötti konfliktusokból eredő kisebb katasztrófák számát.
Fontos, hogy az átvételi kritériumoknak nem kell kimerítőnek lenniük; ez a technikai tesztek feladata. Az átvételi kritériumokat legalább annyira használjuk kommunikációs, mint verifikációs célokra: működő példák formáját öltik magukra, ezért is hivatkozunk gyakran mind az ATDD-re, mind a példákon keresztül való specifikációra.
Persze az ATDD-t nem csak agilis módszertant használó projektek esetében vethetjük be. Azok a csapatok is profitálhatnak belőle, amelyek formálisabb és részletesebb use case-ekkel vagy olyan tradicionálisabb megközelítésekkel dolgoznak, mint például az SRS (szoftverkövetelmény-specifikáció), hiszen a lehető legkorábban juthatnak általa ellenőrizhető, automatizált átvételi kritériumokhoz.
Az átvételi vizsgálatok automatizálása
Az átvételi kritériumok kulcseleme, hogy automatizáltan képesek működni. Nem egyszerűen egy Word vagy Excel fájlban tároljuk őket: élő, végrehajtható tesztek. Az ATDD akkor igazán hatékony, ha az automatizált átvételi vizsgálatok lefutnak minden alkalommal, amikor változtatunk a forráskódon. Éppen ezért nagyon fontos, hogy rendelkezésünkre álljon egy eszköz, amely könnyen integrálható fejlesztési folyamatainkba, és emberi beavatkozás nélkül fut build servereinken.
Az automatizált átvételi vizsgálatok nem csupán azt a célt szolgálják, hogy teszteljék az applikációt, egyben egy objektív mérőeszközt is adnak a kezünkbe a projekt előrehaladásának felméréséhez (az agilis projektekben például nem is fogadunk el mást az előrehaladás mércéjeként, csak a működő szoftvert). A vizsgálatok ráadásul képet adhatnak az egyes feature-ök és storyk viszonylagos komplexitásáról is: azokat a funkciókat, amelyeket bonyolult és sokáig tart tesztelni, jó eséllyel bonyolult és hosszadalmas fejleszteni is. Ez fontos segítség lehet a termékmenedzserek számára a prioritások felmérésében.
Bár természetesen a hagyományos teszteszközök - mint például a TestNG - is alkalmasak arra, hogy automatizált átvételi vizsgálatokat írjunk bennük, van néhány eszköz, amelyet kifejezetten az ATDD módszertan támogatására hoztak létre.
ATDD-eszközök
Az egyik legkorábbi ATDD-teszteszköz a FitNesse. Ebben a felhasználók táblázatos formában vihetik fel a követelményeket egy wikibe, majd a fejlesztők a kulisszák mögött írják meg a kódot, mely a wikiben tárolt tesztadatokkal lefuttatja a teszteket az applikáción. A tesztek végrehajtása után a táblázat színekkel jelzi, hogy melyek zárultak sikerrel, és melyeken nem ment át az applikáció. A FitNess nagyon hasznos eszköz lehet, ha átvételi vizsgálatunk követelményei kifejezhetők adattáblákkal és elvárt eredményekkel, illetve használják még lépéssorozatokban kifejezhető átvételi kritériumok esetében is.
Újabban több olyan eszköz is napvilágot látott, amely a BDD (behavior-driven development, azaz viselkedésvezérelt vagy viselkedésalapú szoftverfejlesztés) módszertant támogatja. Ez a technika arra sarkallja a fejlesztőket, hogy az applikációt annak viselkedése felől közelítsék meg, és az alacsony szintű technikai követelményeket is narratívába helyezve fogalmazzák meg. A Cucumber a Ruby közösség népszerű eszköze, amely lehetővé teszi, hogy az átvételi követelményeinket az agilis projektekben gyakran használt given-when-then (adva-amikor-akkor) struktúrában fogalmazzuk meg. A Cucumbert Javával kompatibilis.
A JBehave hasonló megközelítést használ: a sztorikat szövegfájlokban fejezi ki, a tesztek pedig Java osztályokban írhatók meg. Hasonló eszköz még a Groovy nyelven alapuló Easyb is.
Még frissebb ATDD-eszköz a Concordion, amelyben az átvételi vizsgálatok táblázatokat és szövegeket is tartalmazó HTML-oldalak formájában fejeződnek ki. Az eszköz Java osztályokat használ az oldalakon elhelyezett tagek (címkék) analizálására, az eredményeket pedig HTML-ben jelzi ki.
Ezek az eszközök mind nagy hangsúlyt fektetnek az olvashatóságra és a kommunikációra. Az alábbi kód jól illusztrálja, hogyan fejezhetünk ki egy átvételi kritériumot Easyb segítségével:
scenario User can approve an invoice for an amount less than the agreed maximum"
{
given "the User has selected an open invoice",
and "the User has chosen to approve the invoice",
and "the invoice amount is less than the agreed maximum amount",
when "the User completes the action",
then "the invoice should be successfully approved",
}
Amint ily módon meghatároztuk az átvételi kritériumot, a hozzá tartozó teszkód már megírható a hagyományosabb programnyelvek valamelyikén, pl. Javában, Groovy-ban vagy Ruby-ban.
Az Easyb bemutatása mellett ez a kódrészlet azt is jól megvilágítja, hogy mekkora mértékben helyezik a hangsúlyt a kommunikációra az ATDD-eszközök. Az automatizált átvételi kritériumokat olyan magas szintű kifejezésekkel fogalmazzák meg, amelyek az üzleti vezetők számára éppoly érthetők, mint a szoftvermérnökök és a programozók számára. A legtöbb ATDD-eszköz még arra is alkalmas, hogy a teszteredményekből hétköznapi üzleti kifejezésekben megfogalmazott jelentéseket generáljon.
A még nem lekódolt, de ily módon már megfogalmazott átvételi kritériumokat az eszköz a „pending" (folyamatban) címkével látja el: egy iteráció kezdetekor minden teszt állapota ez, a következő lépés pedig a tesztek implementálása. Így a riportok nem csupán a teszteredményekről, de a projekt, illetve az egyes részfeladatok állapotáról is tájékoztatnak.
Kicsit nagyobb perspektívából nézve az automatizált átvételi vizsgálatok olyanok, mint bármely más automatizált tesztek: el kell tárolnunk őket a verziókontrollt biztosító rendszerünkben, és időről időre lefuttatni őket a CI- (continouous-integration, folyamatos integráció) szerverünkön (legalább minden éjjel, de lehetőleg minden alkalommal, amikor változtatunk a forráskódon). A gyors visszajelzés egy sikertelen átvételi vizsgálatról kritikus lehet. A CI-szerveren érdemes azt is beállítani, hogy az eredményeket olyan helyre is publikálja, ahol a nem fejlesztő munkatársak is könnyen elérhetik. Szerencsére az újabb CI-eszközök, mint például a Jenkins, nagyon könnyen integrálhatók szinte mindegyik BDD-eszközzel.
