Gyors útmutató az ATDD bevezetéséhez

Ez a cikk gyors útmutatót nyújt mindenkinek, aki az ATDD-t szeretné bevezetni csapataiban és projektjeiben. Egy vállalati szoftverfejlesztő csapatban szerzett első kézből származó tapasztalataim alapján vázolja fel ennek az agilis megközelítésnek az előnyeit.

Az együttműködés az agilis módszertan egyik alapvető értéke. Egyszer, amikor egy nagy projekten dolgoztam, észrevettem a fejlesztők, a tesztelők és az üzleti szemléletű egyének közötti együttműködés hiányát; a követelmények tisztázatlanságát; a követelmények terjedelmének gyakori túllépését; az elvégzett teszteléssel kapcsolatos átláthatóság hiányát; és a hibák azonosítását a projekt életciklusának késői szakaszában. Számomra azonban a legfontosabb az volt, hogy senkinek sem volt fogalma az automatizálási keretrendszerünkről, így az összes automatizálási tesztet azután írták meg, hogy a funkciókat kifejlesztették és készen álltak a tesztelésre. E megfigyelések miatt elkezdtem kutatni, hogyan kezelik az emberek az ilyen jellegű problémákat. Ennek eredményeként találtam rá az elfogadási tesztek által vezérelt fejlesztésre (Acceptance Test Driven Development, ATDD), mint az egyik olyan megközelítésre, amelyet számos ilyen probléma enyhítésére használnak. Gyakran szinonimaként használják a viselkedésvezérelt fejlesztéssel (BDD), a történet tesztvezérelt fejlesztéssel (SDD) és a példa szerinti specifikációval (SBE). Az ATDD fő megkülönböztető jegye a többi agilis megközelítéssel szemben az, hogy a fejlesztők, tesztelők, üzletemberek, terméktulajdonosok és más érdekelt felek egy egységként működnek együtt, és világos képet alkotnak arról, hogy mit kell megvalósítani.

A saját tapasztalataim alapján fogom megosztani az ötleteimet azzal kapcsolatban, hogy a csapatok hogyan valósíthatják meg az ATDD-t a saját projektjeikben.

A kontextus

Egy nagyvállalatnál dolgoztam, amely startup gondolkodásmóddal rendelkezett, így minden innovatív ötletet és visszajelzést bátorított a csapat. Gyorsan építettünk prototípusokat, hogy lássuk, egy ötlet jobbá tenné-e a termékünket, vagy segítené-e az átfogó vállalati célokat. Én voltam a vezető tesztelő egy 25 fős csapatban, amely egy scrum masterből, egy technikai vezetőből, valamint több üzleti elemzőből, tervezőből, fejlesztőből és tesztelőből állt. Az innovációs kultúra eredményeként a csapaton belül gyakran káosz uralkodott, beleértve a funkciókövetelmények gyakori változásait, az egyének silózott környezetben dolgoztak, és a csapat morálja mélyponton volt. Ez aggasztó volt számomra, ezért önként jelentkeztem, hogy segítek megoldást találni ezekre a fájdalmas pontokra, ami elvezetett az ATDD-hez.

Az ATDD-vel kapcsolatos összes tapasztalatom és tanulságom az alábbi 3 lépésbe sorolható.

Az ATDD megvalósítási ciklus

Raj Subramanian

1. lépés – képzés és kísérletezés

A feladatok megközelítésének számos módja létezik, különösen, ha figyelembe vesszük az egyének tapasztalatait, akik különböző agilis csapatokban dolgoznak jelenlegi szervezetükön belül és kívül. A csapat és a szervezet céljainak közös és közös megértéséhez fontos a megfelelő képzés biztosítása. Ami konkrétan az ATDD-t illeti, ennek tartalmaznia kell a célokat, célkitűzéseket, elvárásokat és az e megközelítés alkalmazásából származó eredményekre vonatkozó információkat. A képzés után fontos egy kis léptékű megvalósítással kezdeni, hogy különböző dolgokat próbálhassunk ki, és iteratív visszajelzést kapjunk.

Az ATDD kutatását követően például elmagyaráztam a különböző érdekelt feleknek, hogy miért kell felfedeznünk ezt a megközelítést, és milyen előnyökkel járna számunkra. Kiemeltem néhányat a lehetséges pozitívumok közül, például a csapat fokozott együttműködését, a követelmények jobb tisztázását, a hibák korábbi azonosítását a szoftverfejlesztési életcikluson (SDLC) belül, a nagyobb láthatóságot és az automatizálás korábbi alkalmazását az SDLC-ben, valamint az egész csapat bevonását az egyértelmű elfogadási kritériumok kidolgozásába.

Az érdekeltekkel folytatott megbeszélés során hangsúlyoztam, hogy ez némi kísérletezést igényel, de kipróbálás nélkül sosem tudhatjuk meg az előnyeit. Néhány hosszas megbeszélés után úgy döntöttünk, hogy az eredetileg 25 fős csapatot 2 kisebb csapatra osztjuk: Az A csapat 12 főből állt, és az ATDD-t fogja megvalósítani. A B csapat a fennmaradó 13 főből állt, és folytatni fogja azt, amit eddig is csinált.

Az A csapat számára egy kétnapos képzési workshopot terveztem az ATDD megismerésével, annak meghatározásával, hogy mely fogalmaknak van értelme a projektünk kontextusában, és hogyan használhatnánk ki az automatizálást a folyamat során. A képzésbe elméleti és gyakorlati gyakorlatok keverékét építettem be. A gyakorlatok közül néhány az alábbi:

• Hogyan írjunk Gherkin utasításokat – Given/When/Then (GWT)
• Melyek a jó felhasználói történet legfontosabb jellemzői?
• Az automatizálási keretrendszerünk bemutatása, beleértve mind a működését, mind a felépítését. Voltak gyakorlatok arra vonatkozóan is, hogyan írjunk csapatban egyszerű automatizálási tesztkódot. A workshop előtt egy csapattaggal módosítottuk az automatizálási keretrendszerünket, hogy szinkronban legyen az ATDD megközelítéssel. Az automatizálási keretrendszerünkhöz a Cucumber bővítményt használtuk Javával és Appiummal.

Forrás

2. lépés – A láthatóság növelése

Amikor egy projekt több sprintet él át, könnyű elveszíteni a követendő különböző folyamatok áttekintését. A kulcs tehát az, hogy a célokat, célkitűzéseket és elvárásokat az egész csapat számára láthatóvá tegyük.

Amikor elkezdtük használni az ATDD-t, azzal kezdtem, hogy egyszerűen felírtam az egyes napi követendő folyamatokat egy táblára, amelyet ott helyeztem el, ahol a csapatunk a napi stand-up megbeszéléseket tartotta. Minden egyes felhasználói történethez hozzáadtam egy ellenőrző listát azokról az elemekről, amelyeket el kellett végezni, mielőtt a történet befejezettnek tekinthető. Így nem volt félreérthető, hogy milyen ATDD-folyamatokat kell követni. Az egyik ilyen ellenőrzőlista-elem a kick-off megbeszélés volt, amelyen a fejlesztő, a tesztelő és az üzletemberek csapatként megvitatták a követelményeket, azonosították, hogy mely követelmények automatizálhatók, és felvázolták a történet elfogadási kritériumait GWT-formátumban. Egy másik ellenőrzési listaelem a QA-Dev Handoff volt, ahol a fejlesztő egy gyors bemutató vagy megbeszélés segítségével megmutatta a tesztelőnek, hogyan teljesültek a követelmények, és milyen egységteszteket írtak a történet részeként. Ezen az átadáson keresztül a tesztelő megtudta, hogy mely területekre nem terjedtek ki az egységtesztek, és jobban megértette a megvalósított funkciót, ami jobb tesztlefedettséghez vezetett. Az ellenőrzőlista elemei néha nyilvánvalóak voltak, de jó, ha világosan kimondják őket. Tartalmaztunk egyet annak biztosítására, hogy a történethez kapcsolódó összes hiba lezárásra kerüljön; egy másik a demó megtekintése után az üzletember általi végső jóváhagyás volt, amely biztosítja, hogy a funkció az előzetesen meghatározott követelményeknek és elvárásoknak megfelelően épüljön meg.

Elkezdtünk egy “Process Hawk”-ot is tartani. Ez egy egyéni csapattag volt; lehetett scrum master, projektmenedzser vagy bárki más, aki biztosította, hogy a csapat kövesse a folyamatot. Az én esetemben ez egy másik vezető tesztelő volt a csapaton belül; ő és én rendszeresen emlékeztettünk mindenkit az ATDD-folyamat követésére minden megbeszélésen, beleértve a standupot, a tervezést, a retrospektív és egyéb csapatmegbeszéléseket.

3. lépés Iteratív tanulás és visszacsatolás

A folyamatos visszacsatolási kör létfontosságú bármely agilis megközelítés, így az ATDD megvalósításában is. A heti vagy kétheti retrospektív megbeszélések tartása az egész csapattal fontos módja annak, hogy megtudjuk, a folyamat mely részei valóban hasznára válnak a csapatnak, és melyek azok, amelyek esetleg módosításra szorulnak. Mint már tudjuk, ami nem segíti a csapatot, az idő- és fáradságpazarláshoz vezet. Ahogy Brian Tracy, az Eat That Frog!: 21 Great Ways to Stop Procrastinating and Get More Done in Less Time című könyv szerzője mondja: “Az egyik legrosszabb időfelhasználás az, ha valamit nagyon jól csinálunk, amit egyáltalán nem kell csinálni.”

A jelenlegi informatikai korszakban a szervezetek nem engedhetik meg maguknak, hogy időt és energiát pazaroljanak hatástalan megközelítésekre; inkább karcsú és hatékony folyamatokra van szükségünk. Ez kapcsolódik a lean startupok validált tanulási elvéhez: a Build, Measure, Learn ciklushoz.”

Ezt szem előtt tartva elkezdtem minden csütörtökön 30 perces megbeszéléseket tartani az A csapattal, hogy ellenőrizzem, hogyan halad a csapat az új folyamattal. Ez jó módja volt annak, hogy a csapat reakciói alapján felmérjük, milyen változtatásokra van szükség. Ez a megbeszélés a retrospektív megbeszéléstől függetlenül történt, amely a kéthetes sprintek végén volt. Ez a megközelítés folyamatos visszajelzést hozott a csapattól, ami lehetővé tette, hogy azonnali és hatékony változtatásokat hajtsunk végre. A visszajelzés nem kizárólag a heti folyamat-ellenőrzésekből származott; a napi stand-up megbeszélések is értékes információforrásnak bizonyultak. A csapattagok egyéni frissítései és megbeszélései felfedték a folyamathoz kapcsolódó piros zászlókat, és azonnal tudtunk velük foglalkozni, mielőtt a csapat többi tagjára is hatással lettek volna.

Összefoglaló

Az ATDD bevezetési ciklus követésének eredményeképpen az A csapat jelentős különbségeket kezdett tapasztalni a csapatmorál, az együttműködés és a követelmények terén.

Teammorál

Mindenki csapatként kezdett dolgozni, és felhatalmazva érezte magát. Mindenki birtokolta a történetet az elejétől a végéig. Biztosította, hogy a történet minden szükséges információval rendelkezzen a fejlesztési és tesztelési munka megkezdéséhez. A csapattag gondoskodott arról is, hogy a sztorival kapcsolatos minden nyomon követés megtörténjen. Végül az adott személy volt felelős a történet bemutatásáért az összes érdekelt fél számára a sprint végén. Ez a felelősségérzet jelentősen növelte a csapat morálját.

Kollaboráció

A kezdeti megbeszéléseken az üzletember, a fejlesztő és a tesztelő találkozott egymással, hogy kialakítsák a felhasználói történet közös értelmezését. A QA-Dev Handoff, amely a buildnek a QA-kiszolgálókra való tolása előtt történt, segített a fejlesztőnek és a tesztelőnek is tudni, hogy a történet részeként milyen teszteléseket fognak elvégezni, és jobb megértést hozott a megvalósított funkcióról. Megnövekedett az automatizálás átláthatósága, mivel az egész csapat vállalta a felelősséget, nem csak a tesztelők. Végül a tervezési megbeszéléseken az egész csapat együtt vitatta meg a történetet, így több ötletet, kérdést és megbeszélést generált. A fokozott együttműködés a tanulás fokozódásához is vezetett – a csapat úgy döntött, hogy egymástól való tanulás céljából egymás közötti tréningeket tart, a tesztelők párosított feltáró tesztelésbe kezdtek, és a különböző csapattagok ebéd-tanulási üléseket tartottak, hogy megvitassák a technológiával kapcsolatos különböző témákat. Mindezek a dolgok a csapat általános együttműködésének javulásához vezettek.

Követelmények

A korábbi folyamataink egyik fő problémája a követelmények gyakori változása és a terjedelem növekedése volt. Az ATDD megközelítéssel elengedhetetlen volt, hogy amint a fejlesztő elkezdett dolgozni egy történeten, a követelmények rögzüljenek. Minden változtatást a többi közelgő sztorival együtt kell rangsorolni, és a következő sprintekhez kell hozzáadni. Ez csökkentette mind a fejlesztők, mind a tesztelők munkaterhelését, és megakadályozta, hogy az érdekeltek irreális elvárásokat támasszanak az elkészült funkciókkal szemben.

A fenti fejlesztések láttán a B csapat is ATDD-t kezdett bevezetni. Ennek eredményeképpen a rendszeres kísérletezés és visszajelzés után az egész eredeti csapat ezt a megközelítést alkalmazta.

Következtetés

Az ATDD megközelítését ajánlom, és ez összhangban van a “Shift Left Paradigmával”, amely szerint a fejlesztést és a tesztelést a lehető legkorábban kell elkezdeni az SDLC-ben. Nagyobb átláthatóságot hozott az automatizálásba, mivel már az SDLC elején elkezdtük az automatizált tesztek írását, ami viszont növelte a csapaton belüli együttműködést.

Forrás

Ne feledjük, az ATDD nem egy “egyméretű” megoldás. Ez volt az az agilis megközelítés, amelynek a projektem kontextusában a legtöbb értelme volt, de számos más módja is van a csapatokban zajló folyamatok javításának. Ezt a megközelítést a jobb elfogadási tesztekre való összpontosítás miatt használtam, de ami még fontosabb, az együttműködésre helyezett hangsúly miatt. Az együttműködés szerves részét képezi ennek a megközelítésnek, és szerintem ez a legértékesebb.”

A szerzőről

Raj Subrameyer technológiai karrierstratéga, aki arra összpontosít, hogy segítsen az embereknek megszerezni álmaik állását és sikeres vezetővé válni. Szenvedélyesen vezeti a szakembereket, hogy maximalizálják lehetőségeiket és felfedezzék zsenialitásuk zónáját. A technológiai iparágban szerzett tapasztalatait arra használja fel, hogy kutatásokat végezzen, előadásokat tartson és írjon arról, hogyan tudjuk magunkévá tenni a technológiát, és hogyan válhatunk teljes értékű digitális állampolgárokká. Különböző konferenciák keresett előadója, és számos podcastban és kiadványban szerepelt, többek között a CEOWORLD Magazine, Authority Magazine, Career Addict, Thrive Global, Addicted2Success és The Good Men Project kiadványokban. Ő a szerzője az új könyvnek is – “Skyrocket Your Career”. Szakterületei közé tartozik a karrierépítés, a vezetés, a motiváció, a termelékenység és a vállalkozói szellem. Szabadidejében szeret utazni és kézműves söröket fogyasztani. Weboldalán további információkat találhatsz arról, hogyan szolgálja az embereket.