A Quick Guide to Implementing ATDD

Tämässä artikkelissa on pikaopas kaikille niille, jotka ovat kiinnostuneita ATDD:n käyttöönotosta tiimeissään ja projekteissaan. Siinä hahmotellaan tämän ketterän lähestymistavan noudattamisen etuja, jotka perustuvat omakohtaiseen kokemukseeni yrityksen ohjelmistokehitystiimissä.

Yhteistyö on yksi ketterän metodologian keskeisistä arvoista. Kerran työskennellessäni suuren projektin parissa huomasin, että kehittäjien, testaajien ja liiketaloudellisesti ajattelevien henkilöiden välinen yhteistyö oli puutteellista, vaatimukset olivat epäselviä, vaatimukset laajenivat usein, toteutettuun testaukseen ei ollut näkyvyyttä ja virheet havaittiin myöhään projektin elinkaaren aikana. Tärkeintä minulle oli kuitenkin se, että kenelläkään ei ollut aavistustakaan automaatiokehyksestä, joten kaikki automaatiotestit kirjoitettiin sen jälkeen, kun ominaisuudet oli kehitetty ja valmiina testausta varten. Näiden havaintojen vuoksi aloin tutkia, miten ihmiset ratkaisevat tämäntyyppisiä ongelmia. Tuloksena löysin ATDD:n (Acceptance Test Driven Development) yhtenä lähestymistapana, jota käytetään monien näiden ongelmien lieventämiseen. Sitä käytetään usein synonyyminä Behavior Driven Development (BDD), Story Test Driven Development (SDD) ja Specification By Example (SBE) -menetelmien kanssa. ATDD:n tärkein ero muihin ketteriin lähestymistapoihin verrattuna on se, että siinä keskitytään siihen, että kehittäjät, testaajat, liikemiehet, tuoteomistajat ja muut sidosryhmät tekevät yhteistyötä yhtenä yksikkönä ja luovat selkeän käsityksen siitä, mitä on toteutettava.

Oman kokemukseni perusteella jaan ajatuksiani siitä, miten tiimit voivat toteuttaa ATDD:tä omissa projekteissaan.

Ympäristö

Työskentelin suuressa yrityksessä, jolla oli startup-ajattelu, joten tiimi kannusti kaikkia innovatiivisia ideoita ja palautetta. Rakensimme nopeasti prototyyppejä nähdaksemme, tekisikö idea tuotteestamme paremman tai auttaisiko se yrityksen yleisten tavoitteiden saavuttamisessa. Olin johtava testaaja 25-henkisessä tiimissä, johon kuului yksi scrum master, yksi tekninen johtaja sekä useita liiketoiminta-analyytikkoja, suunnittelijoita, kehittäjiä ja testaajia. Innovaatiokulttuurin seurauksena tiimissä vallitsi usein kaaos, johon kuului usein tapahtuvia muutoksia ominaisuusvaatimuksissa, yksilöiden työskentely siiloutuneissa ympäristöissä ja tiimin työmoraali oli kaikkien aikojen alhaisimmillaan. Tämä huolestutti minua, joten ilmoittauduin vapaaehtoiseksi auttamaan ratkaisun löytämisessä näihin ongelmakohtiin, mikä johti minut ATDD:hen.

Kaikki ATDD:stä saamani opit ja kokemukseni voidaan kategorisoida alla oleviin kolmeen vaiheeseen.

AtDD:n toteutussykli

Luonut Raj Subramanian

Vaihe 1 – Koulutus ja kokeilu

Tehtäviä voidaan lähestyä monin eri tavoin, varsinkin kun otetaan huomioon yksittäisten henkilöiden kokemukset työskentelystä erilaisissa ketterissä tiimeissä nykyisessä organisaatiossaan ja sen ulkopuolella. Jotta saadaan aikaan jaettu ja yhteinen ymmärrys tiimin ja organisaation tavoitteista, on tärkeää tarjota asianmukaista koulutusta. Erityisesti ATDD:n osalta sen tulisi sisältää päämäärät, tavoitteet, odotukset ja tiedot tuloksista, jotka saadaan tämän lähestymistavan käytöstä. Koulutuksen jälkeen on tärkeää aloittaa pienimuotoinen toteutus, jotta voidaan kokeilla erilaisia asioita ja saada iteratiivista palautetta.

Esimerkiksi ATDD:tä tutkittuani selitin eri sidosryhmille, miksi meidän oli tutkittava tätä lähestymistapaa ja mitä hyötyjä saisimme siitä. Korostin muutamia mahdollisia myönteisiä puolia, kuten tiimin yhteistyön lisääntymistä, vaatimusten parempaa selventämistä, virheiden varhaisempaa tunnistamista ohjelmistokehityksen elinkaaren (SDLC) aikana, näkyvyyden lisääntymistä ja automaation varhaisempaa käyttöä SDLC:ssä sekä koko tiimin osallistumista selkeiden hyväksymiskriteerien laatimiseen.

Keskustellessani sidosryhmien kanssa painotin, että tämä vaatisi jonkin verran kokeilua, mutta kokeilematta emme voisi koskaan saada selville, mitä hyötyjä siitä olisi. Muutaman pitkän keskustelun jälkeen päätimme jakaa alkuperäisen 25 hengen tiimin kahteen pienempään tiimiin: Tiimi A koostui 12 henkilöstä, ja se toteuttaisi ATDD:n. Tiimiin B kuului loput 13 henkilöä, ja se jatkaisi sitä, mitä se jo teki.

Suunnittelin tiimille A kaksipäiväisen koulutustyöpajan tutustumalla ATDD:hen, määrittelemällä, mitkä käsitteet olivat mielekkäitä projektimme kannalta, ja miten voisimme hyödyntää automaatiota koko prosessin ajan. Sisällytin koulutukseen sekoituksen teoreettisia ja käytännön harjoituksia. Osa harjoituksista on alla:

• Miten kirjoitetaan Gherkin-lauseet – Given/When/Then (GWT)
• Mitkä ovat hyvän käyttäjätarinan tärkeimmät ominaisuudet?
• Automaatiokehyksemme esittely, mukaan lukien sekä sen toiminta että rakenne. Lisäksi tehtiin harjoituksia yksinkertaisen automaatiotestauskoodin kirjoittamisesta tiiminä. Ennen työpajaa muutimme erään tiimin jäsenen kanssa automaatiokehystämme ATDD-lähestymistavan mukaiseksi. Käytimme automaatiokehyksessämme Cucumber-lisäosaa Javalla ja Appiumia.

Lähde

Vaihe 2 – Näkyvyyden lisääminen

Kun projekti elää useiden sprinttien läpi, on helppo hukata silmäys erilaisiin prosesseihin, joita on noudatettava. Keskeistä on siis tehdä päämäärät, tavoitteet ja odotukset näkyviksi koko tiimille.

Kun aloimme käyttää ATDD:tä, aloitin yksinkertaisesti kirjoittamalla jokaisen päivittäin noudatettavan prosessin taululle, jonka sijoitin sinne, missä tiimimme piti päivittäiset stand-up-kokoukset. Jokaiseen käyttäjätarinaan lisäsin tarkistuslistan asioista, jotka oli tehtävä ennen kuin tarina katsottaisiin valmiiksi. Näin ei jäänyt epäselvyyttä siitä, mitä ATDD-prosesseja on noudatettava. Yksi tällainen tarkistuslistan kohta oli aloituskokous, jossa kehittäjä, testaaja ja liiketoimintahenkilöt keskustelivat tiiminä vaatimuksista, määrittelivät, mitkä vaatimukset voitaisiin automatisoida, ja hahmottelivat tarinan hyväksymiskriteerit GWT-muodossa. Toinen tarkistuslistan kohta oli QA-Dev Handoff, jossa kehittäjä näytti testaajalle nopean demon tai keskustelun avulla, miten vaatimukset oli täytetty ja mitä yksikkötestejä oli kirjoitettu osana tarinaa. Tämän luovutuksen avulla testaaja oppi, mitä alueita yksikkötestit eivät kattaneet, ja sai paremman käsityksen toteutetusta ominaisuudesta, mikä johti parempaan testien kattavuuteen. Tarkistuslistan kohdat olivat joskus itsestään selviä, mutta ne oli hyvä ilmaista selkeästi. Sisällytimme yhden, jolla varmistettiin, että kaikki tarinaan liittyvät viat oli suljettu; toinen oli liiketoimintahenkilön lopullinen hyväksyntä demon katsomisen jälkeen, jolla varmistettiin, että ominaisuus oli rakennettu aiemmin asetettujen vaatimusten ja odotusten mukaisesti.

Aloimme myös ottaa käyttöön ”prosessihaukan”. Tämä oli yksittäinen tiimin jäsen; se saattoi olla scrum master, projektipäällikkö tai kuka tahansa, joka varmisti, että tiimi noudatti prosessia. Minun tapauksessani se oli tiimin toinen vanhempi testaaja; hän ja minä muistutimme säännöllisesti kaikkia noudattamaan ATDD-prosessia kaikissa kokouksissa, kuten standup-, suunnittelu-, retrospektiivi- ja muissa tiimipalavereissa.

Vaihe 3 – Iteratiivinen oppiminen ja palaute

Jatkuvan palautesilmukan pitäminen on ratkaisevan tärkeää minkä tahansa ketterän lähestymistavan, mukaan lukien ATDD:n, toteuttamisessa. Viikoittaiset tai kahden viikon välein pidettävät retrospektiiviset kokoukset koko tiimin kanssa ovat tärkeä tapa tietää, mitkä prosessin osat todella hyödyttävät tiimiä ja mitä osia on ehkä muutettava. Kuten jo tiedämme, mikä ei auta tiimiä, johtaa ajan ja vaivannäön tuhlaamiseen. Kuten Brian Tracy, Eat That Frog!: 21 Great Ways to Stop Procrastinating and Get More Done in Less Time -kirjan kirjoittaja, toteaa: ”Yksi pahimmista ajankäytön muodoista on tehdä jotain erittäin hyvin, mitä ei tarvitse tehdä lainkaan.”

Nykyisenä tietotekniikan aikakautena organisaatioilla ei ole varaa tuhlata aikaa ja energiaa tehottomiin toimintatapoihin, vaan tarvitsemme pikemminkin kevyitä ja tehokkaita prosesseja. Tämä liittyy Lean Startupin validoidun oppimisen periaatteeseen: Build, Measure, Learn -sykliin.

Tässä mielessä aloin pitää joka torstai 30 minuutin kokouksia tiimi A:n kanssa tarkistaakseni, miten tiimi pärjää uuden prosessin kanssa. Tämä oli hyvä tapa arvioida, mitä muutoksia oli tehtävä tiimin reaktioiden perusteella. Tämä kokous pidettiin erillään retrospektiivisestä kokouksesta, joka pidettiin kahden viikon sprinttien lopussa. Tämä lähestymistapa toi tiimiltä jatkuvaa palautetta, minkä ansiosta pystyimme tekemään välittömiä ja tehokkaita muutoksia. Palaute ei tullut pelkästään viikoittaisista prosessin tarkistuksista, vaan myös päivittäiset stand-up-kokoukset osoittautuivat arvokkaaksi tietolähteeksi. Tiimin yksittäisten jäsenten päivitykset ja keskustelut paljastivat prosessiin liittyviä punaisia lippuja, ja pystyimme puuttumaan niihin välittömästi, ennen kuin ne vaikuttivat muuhun tiimiin.

Yhteenveto

Tuloksena ATDD:n käyttöönottosyklin noudattamisesta tiimi A alkoi havaita huomattavia eroja tiimimoraalissa, yhteistyöhön liittyvissä asioissa ja vaatimuksiin liittyvissä asioissa.

Tiimimoraali

Kaikki alkoivat työskentelemään tiiminä, ja he tunsivat olevansa vahvempia. Jokainen henkilö omisti tarinan alusta loppuun asti. Hän varmisti, että tarinassa oli kaikki tarvittavat tiedot kehitys- ja testaustyön aloittamiseksi. Tiimin jäsen varmisti myös, että kaikki tarinaan liittyvät jatkotoimenpiteet tehtiin. Lopuksi kyseinen henkilö vastasi tarinan esittelystä kaikille sidosryhmille sprintin lopussa. Tämä omistajuuden tunne kohotti tiimin moraalia merkittävästi.

Yhteistyö

Aloituskokoukset kokosivat liiketoimintahenkilön, kehittäjän ja testaajan yhteen, jotta käyttäjätarinasta saatiin yhteinen käsitys. QA-Dev Handoff, joka tapahtui ennen buildin työntämistä QA-palvelimille, auttoi sekä kehittäjää että testaajaa tietämään, mitä testausta suoritettaisiin osana tarinaa, ja toi paremman ymmärryksen toteutetusta ominaisuudesta. Automaation näkyvyys lisääntyi, koska koko tiimi otti vastuun, eikä vain testaajat. Lopuksi suunnittelupalavereissa koko tiimi keskusteli tarinasta yhdessä, mikä synnytti lisää ideoita, kysymyksiä ja keskusteluja. Lisääntynyt yhteistyö johti myös lisääntyneeseen oppimiseen – tiimi päätti pitää vertaisvalmennustilaisuuksia oppiakseen toisiltaan, testaajat alkoivat tehdä pareittain tutkivaa testausta ja tiimin eri jäsenet järjestivät lounas- ja oppimistilaisuuksia keskustellakseen erilaisista teknologiaan liittyvistä aiheista. Kaikki nämä asiat johtivat siihen, että tiimin yleinen yhteistyö parani.

Tarpeet

Yksi aiempien prosessiemme suurimmista ongelmista oli vaatimukset muuttuivat usein ja niiden laajuus kasvoi. ATDD-lähestymistavan myötä oli välttämätöntä, että kun kehittäjä aloitti tarinan työstämisen, vaatimukset lyötiin lukkoon. Kaikki muutokset on priorisoitava muiden tulevien tarinoiden rinnalle ja lisättävä tuleviin sprintteihin. Tämä vähensi sekä kehittäjien että testaajien työtaakkaa ja esti sidosryhmiä asettamasta epärealistisia odotuksia valmiiden ominaisuuksien suhteen.

Havaittuaan kaikki edellä mainitut parannukset myös tiimi B alkoi toteuttaa ATDD:tä. Tämän seurauksena koko alkuperäinen tiimi käytti tätä lähestymistapaa säännöllisten kokeilujen ja palautteen antamisen jälkeen.

Johtopäätös

Suosittelen ATDD-lähestymistapaa, ja se on linjassa ”Shift Left Paradigm” -ajattelun kanssa, jonka mukaan kehittäminen ja testaaminen olisi aloitettava mahdollisimman varhaisessa vaiheessa SDLC:tä. Se toi lisää näkyvyyttä automatisointiin, kun aloimme kirjoittaa automatisoituja testejä SDLC:n alussa, mikä puolestaan lisäsi yhteistyötä tiimin sisällä.

Lähde

Muista, että ATDD ei ole ”yhden koon ratkaisu”. Se oli ketterä lähestymistapa, joka oli järkevin projektini yhteydessä, mutta on olemassa monia muitakin tapoja parantaa tiimien prosesseja. Käytin tätä lähestymistapaa, koska siinä keskityttiin parempiin hyväksymistesteihin, mutta mikä tärkeämpää, koska siinä painotetaan yhteistyötä. Yhteistyön osuus on olennainen osa tätä lähestymistapaa, ja uskon sen olevan kaikkein arvokkain.

Tietoa kirjoittajasta

Raj Subrameyer on teknisen alan urastrategi, joka keskittyy auttamaan ihmisiä saamaan unelmiensa työpaikan ja tulemaan menestyviksi johtajiksi. Hän opastaa intohimoisesti ammattilaisia maksimoimaan mahdollisuutensa ja löytämään nerokkuusalueensa. Hän käyttää kokemustaan teknologiateollisuudesta tutkiessaan, puhuessaan ja kirjoittaessaan siitä, miten voimme omaksua teknologian ja tulla täysivaltaisiksi digikansalaisiksi. Hän on kysytty puhuja erilaisissa konferensseissa, ja häntä on esitelty lukuisissa podcasteissa ja julkaisuissa, kuten CEOWORLD Magazine, Authority Magazine, Career Addict, Thrive Global, Addicted2Success ja The Good Men Project. Hän on myös uuden kirjan ”Skyrocket Your Career” kirjoittaja. Hänen erikoisalaansa ovat urakehitys, johtaminen, motivaatio, tuottavuus ja yrittäjyys. Vapaa-ajallaan hän rakastaa matkustamista ja käsityöoluen nauttimista. Lisätietoa siitä, miten hän palvelee ihmisiä, löydät hänen verkkosivustoltaan.