Jos TDD on sinulle tuttu, niin ATDD on jollain tapaa TDD:tä, jossa testauksen taso on korkeampi ja johon osallistuu enemmän sidosryhmiä, toisin sanoen se on enemmän hyväksymistestausta kuin yksikkötestausta. Jos haluat tietää lisää TDD:stä niin katso seuraava viesti:
Acceptance test-driven development (ATDD) on kehitysmenetelmä, joka perustuu liiketoiminta-asiakkaiden, kehittäjien ja testaajien väliseen kommunikointiin. ATDD käsittää monia samoja käytäntöjä kuin esimerkkien avulla tapahtuva määrittely (specification by example), käyttäytymislähtöinen kehitys (behavior-driven development, BDD), esimerkkilähtöinen kehitys (example-driven development, EDD) ja tukilähtöinen kehitys (support-driven development), jota kutsutaan myös nimellä tarinatestilähtöinen kehitys (story test-driven development, SDD). Kaikki nämä prosessit auttavat kehittäjiä ja testaajia ymmärtämään asiakkaan tarpeita ennen toteutusta ja antavat asiakkaille mahdollisuuden keskustella omalla toimialansa kielellä.
Ketterissä tiimeissä laajalti käytössä oleva ATDD on käytäntö, jossa liiketoiminta-analyytikot, kehittäjät ,testaajat ja käyttäjät työskentelevät yhdessä määritelläkseen kunkin tarinan (tai ominaisuuden) hyväksymiskriteerit kehitysprosessin varhaisessa vaiheessa (ennen koodauksen aloittamista). Tämä lähestymistapa antaa kaikille sidosryhmille mahdollisuuden saada ja ylläpitää samaa tasoa odotetuista tuloksista ennen kuin kehittäjät aloittavat koodauksen.
Tiedän, että olemme kaikki kuulleet stereotyypin ”Kehittäjät eivät välitä määrittelystä ja testaajat eivät halua tehdä automatisointia”, mutta ATDD:n avulla säästetään paljon hukkaan heitettyä aikaa ja rahaa varmistamalla, että kehittäjät osallistuvat enemmän määrittelyn varhaisvaiheeseen ja testaajat automatisoivat hyväksymistestit.
Miten ATDD toteutetaan ”tosielämässä”?
Käytätkö SCRUMia? Jos kyllä, niin teet jo suurimman osan työstä ATDD:ssä. jos et, niin seuraavan esimerkin täytyy ruokkia uteliaisuuttasi :
Esimerkki
Asettakaamme, että tuoteomistaja tai asiakas pyysi mobiilisovellukseemme seuraavaa ominaisuutta: ”Käyttäjänä haluan ohittaa kirjautumisnäytön, jotta voin käyttää sovellusta nimettömänä.” Tarkasteltuamme tätä pyyntöä koko tiimin kanssa (liiketoiminta-analyytikko, kehittäjät, testaajat…) ja kun tarinaan tai ominaisuuteen on lisätty lisää yksityiskohtia, meillä on joitakin tämän kaltaisia ”hyväksymistestejä” tai ”toiminnallisia” testejä (Huomaa, että tämä on vain esimerkki, monet hyväksymistestit puuttuvat tästä ominaisuudesta):
- Acceptance Criteria 1: Sovellus hyväksyy valinnaisesti käyttäjätunnuksen/salasanan kirjautumista varten
- Acceptance Criteria 2: Painikkeen ohitus antaa käyttäjälle mahdollisuuden selata sovelluksessa ilman kirjautumista.
- Hyväksymiskriteerit 3: Kun painikkeen ohitus on valittuna, sovellus ei tallenna tai näytä mitään käyttäjäkohtaisia tietoja.
- Hyväksymiskriteerit 4: Kun kirjautumista/salasanaa käytetään, sovelluksen graafinen käyttöliittymä on mukautettava käyttäjän asetusten mukaiseksi.
Hyödyt
1- Asiakas-myyjä-yhdenmukaisuus : Kun edellä mainitut hyväksymiskriteerit ovat syöttötietona, olemme (jokainen tiimin jäsen) nyt varmoja siitä, että sovellus säilyttää kirjautumis-/salasanatoiminnallisuuden ja lisää vain painikkeen, jonka avulla käyttäjä voi ohittaa kirjautumisnäytön.
2- Laatu ja kustannustehokkuus: Edellä mainitut testit voidaan helposti automatisoida jo ennen kuin kehittäjät aloittavat koodaamisen.
3- Time to Market: Kun testit on toteutettu, kehittäjät voivat validoida vaaditut tehtävät ennen kuin he ilmoittavat, että ne ovat valmiit.
ATDD ei vaadi mitään erityisiä työkaluja. On tärkeää tietää, että kaikkia hyväksymistestejä EI tarvitse automatisoida. Testien automatisointi riippuu useista seikoista, kuten: teknisistä haasteista, määräajasta ja kustannuksista.
Suositeltavia työkaluja?
ATDD ei vaadi mitään erityisiä työkaluja. On tärkeää tietää, että kaikkia hyväksymistestejä EI tarvitse automatisoida. Testien automatisointi riippuu useista seikoista, kuten: teknisistä haasteista, määräajasta ja kustannuksista.
Tässä osiossa annan vain yleiskatsauksen ATDD:ssä eniten käytetyistä automatisointityökaluista:
FitNess: Täysin integroitu itsenäinen wiki- ja hyväksymistestauskehys
Robot-kehys: Geneerinen testiautomaatiokehys hyväksymistestaukseen ja hyväksymistestilähtöiseen kehitykseen (ATDD)
Calabash: Automatisoitu hyväksymistestaus mobiilisovelluksille – Huomaa, että tämä kehys ei välttämättä tue uusinta käyttöjärjestelmäversiota (yli Android O )