Hyväksymistestauslähtöinen kehitys ATDD

Ohjelmistoja, jotka vastaavat käyttäjän tarpeita

Ohjelmistoprojektin onnistumisen perusta on se, että ohjelmisto luodaan oikeaan tarpeeseen. Vain tarpeen ymmärtämisen kautta voidaan toteuttaa ne toiminnallisuudet, joiden avulla liiketoiminta ja käyttäjät saavuttavat tavoitteensa. Kaikilla ohjelmistoa tekevillä on siis oltava yhteinen ymmärrys, miksi toiminnallisuus tarvitaan ja miten ohjelmiston tulisi toimia.

Ketterissä menetelmissä ohjelmisto luodaan iteratiivisesti. Iteratiivisuus mahdollistaa toiminnallisuuksien päivittämisen tai uudelleen tekemisen, mikäli huomataan, että ne eivät vastaakaan käyttäjien tarpeita. Osa uudelleen tekemisestä on luonnollinen ja väistämätön seuraus projektin aikana tapahtuvasta oppimisesta. Monet toiminnallisuudet ovat kuitenkin sellaisia, että ne voitaisiin pienellä suunnittelulla tehdä heti ensimmäisellä kerralla "oikein". Hyvillä suunnittelumenetelmillä turhaa tekemistä voidaan välttää.

Hyväksymistestauslähtöinen kehitys (Acceptance Test Driven Development, ATDD) on menetelmä, jonka avulla ohjelmiston vaatimuksia tai käyttäjätarinoita (user story) määritellään ja tarkennetaan asiakkaan ja toteutustiimin välisellä keskustelulla. Asiakas ja tiimi rakentavat yhdessä hyväksymistestejä, jotka muodostavat yhteisen määritelmän siitä, mitä valmis tarkoittaa. Yhteisen näkemyksen ohjaamana toteutus vastaa todennäköisemmin liiketoiminnan ja käyttäjien tarpeita, jolloin uudelleen tekemistä tarvitaan vähemmän ja kokonaiskustannus laskee.

Määrittelytyöpajat – miksi ollaan tekemässä ja mitä?

Hyväksymistestauslähtöinen kehitys alkaa määrittelytyöpajalla, jossa ovat mukana sekä asiakas (tuoteomistaja, liiketoiminnan edustajia, teknisiä asiantuntijoita) että koko toteutustiimi (suunnittelijat, kehittäjät ja testaajat). Työpaja jakautuu kahteen vaiheeseen, joista ensimmäisessä on tarkoitus löytää vastaukset “miksi?”-kysymyksiin. Miksi tämä ominaisuus on tärkeä? Missä tilanteessa tämä on käyttäjälle tarpeellinen? Kuka käyttäjistä tarvitsee tätä ominaisuutta? Kysymysten ympärille muodostuvan keskustelun avulla luodaan yhteinen kokonaiskäsitys toiminnallisuuden tarkoituksesta.

Toisessa vaiheessa toiminnallisuutta tarkennetaan keskittyen siihen, mitä ohjelmiston pitäisi tehdä ja miten sen pitäisi toimia. Yhdessä luotavat hyväksymistestit toimivat keskustelun runkona. Hyväksymistestien avulla saadaan määriteltyä tarkemmin, miten toiminnallisuuden halutaan toimivan.

Keskustelun aikana tunnistetut avoimet asiat selvitetään työpajan aikana. Tarvittaessa työpajoja järjestetään lisää, kunnes avoimet asiat on käsitelty. Työpajat on syytä toistaa, koska usein yksi avoimen asian päätös avaa useamman uuden huomioonotettavan asian ja listan avoimia kysymyksiä. Näin ollen työpajat on pidettävä riittävän aikaisin. Esimerkiksi käytettäessä Scrum -kehitysprosessia määrittelytyöpaja on luonnollinen osa Backlog Groomingia.

Määrittelytyöpajan lopputuloksena osallistujilla on yhteinen ymmärrys siitä, mitä kyseinen vaatimus tarkoittaa. Luodut hyväksymistestit dokumentoivat yhteisen ymmärryksen halutusta toiminnallisuudesta.

Hyväksymistestit auttavat ohjaamaan kehitystä

Kun yhteisymmärrys on luotu, tiimin tehtävänä on kehittää rinnakkain haluttu toiminnallisuus ja automatisoida määrittelytyöpajoissa luodut hyväksymistestit. Automatisoidut hyväksymistestit ohjaavat kehitystä, ja niiden avulla saadaan palautetta rakennettavan toteutuksen tilasta. Automatisoituja testejä ajetaan aina kun muutoksia tehdään, jolloin ristiriitaisuudet toteutuksen ja dokumentaation eli hyväksymistestien välillä huomataan välittömästi. Testiautomaation ja toiminnallisuuden yhtäaikainen kehittäminen auttavat myös luomaan toteutettavasta järjestelmästä testattavan, mikä on testiautomaation onnistumisen perusedellytys.

Automatisoitujen hyväksymistestien lisäksi testauksen kattavuutta lisätään toteutusvaiheessa tekemällä tutkivaa testausta. Hyväksymistestejä lisätään tarvittaessa, jos kehityksen ja tutkivan testauksen aikana löydetään uutta tietoa. Hyväksymistestit auttavat kehitystiimiä varmentamaan, että toteutus vastaa sovittua ja on valmis.

Toteutettu ja hyväksymistestattu toiminnallisuus esitetään projektin sidosryhmille. Esittelytilaisuuden tarkoituksena on todeta toiminnallisuus julkaisukelpoiseksi tai tunnistaa mahdolliset kehityskohteet.

Regressiotestit säästävät designvelalta

Testien automatisointi mahdollistaa regressiotestauksen suorittamisen, kun testien määrä kasvaa projektin edetessä. Automatisoidut hyväksymistestit varmistavat jo toteutettujen toiminnallisuuksien toimivuuden luotaessa uusia ominaisuuksia. Regressiotestit tukevat myös tiimiä koodin refaktoroinnissa, jolloin vältetään suunnitteluvelan syntyminen. Koska testejä ajetaan jatkuvasti, mahdolliset ongelmat löydetään pikaisesti ja niiden korjaaminen on nopeaa ja kustannustehokasta.

Hyväksymistestauslähtöinen kehitys tuottaa projektin aikana ohjelmistosta toiminnallisen kuvauksen, joka toimii samalla ajantasaisena dokumentaationa. Dokumentaatio pysyy ajan tasalla, koska se muodostuu projektin aikana muodostetuista ajettavista hyväksymistesteistä ja sitä suoritetaan aina viimeisintä ohjelmistoversiota vasten.

Onnistumisen edellytyksenä oikeat osallistujat

Hyväksymistestauslähtöisen kehityksen kulmakivi ovat onnistuneet työpajat, sillä ne luovat perustan koko käytännölle. Oleellisinta määrittelytyöpajojen onnistumiseksi on saada oikeat ihmiset osallistumaan työpajoihin. Työpajoihin tarvitaan ihmisiä, jotka osaavat vastata tarkentaviin kysymyksiin ja pystyvät tarvittaessa tekemään priorisointiin ja toiminnallisuuden rajaukseen liittyviä päätöksiä. Lisäksi on huolehdittava siitä, että työpajoihin osallistuu ihmisiä eri rooleista. Tällöin keskustelussa on riittävästi erilaisia näkökulmia, jolloin toiminnallisuutta saadaan tarkennettua ja rajattua paremmin. Vähimmillään tämä tarkoittaa asiakasta, suunnittelijaa, kehittäjää ja testaajaa. Yleensä paikalla on koko kehitystiimi, jolloin määrittelytyöpaja toimii myös tiedon jakamisen välineenä.

Oikeiden ihmisten lisäksi onnistumiseen vaaditaan riittävästi konkretiaa. Luotavien hyväksymistestien tulee olla riittävän yksityiskohtaisia, sillä usein vasta yksityiskohtaiset esimerkit mahdollistavat määrittelemättömien ja ristiriitaisten toimintojen löytämisen. Jos hyväksymistestit ovat liian abstrakteja, jää suurin osa hyväksymistestauslähtöisen kehityksen hyödyistä saavuttamatta.

Juha Rantanen, laatuasiantuntija

Juhalla on vuosien kokemus ATDD:n käytöstä, ja hän auttanut lukuisia Reaktorin asiakkaita menetelmän käyttöönotossa. Hän on kysytty puhuja alan kansainvälisissä konferensseissa.