Acceptance Test-Driven Development

ATDD eli hyväksymistestivetoinen kehitys (engl. Acceptance Test-Driven Development) ohjaa ohjelmistokehitystä järjestelmän todellisten käyttötilanteiden pohjalta.

ATDD:ssä ohjelmiston määrittelyä ja toteutusta ohjataan konkreettisilla esimerkeillä. Todellisten käyttötilanteiden kuvaaminen ajettavina testeinä pakottaa määrittelemään ohjelmiston vaatimukset tarkemmin kuin mitä perinteisellä vaatimusmäärittelydokumentaatiolla on kyetty tekemään. Samalla huomataan mahdolliset ristiriitaiset vaatimukset määrittelyissä. Perinteisessä toimintatavassa hyväksymistestaus ei nouse näin keskeiseen rooliin vaan se tehdään jälkikäteen, jos silloinkaan.

ATDD:n perusajatus on, että jo ennen ohjelmointia tehdään automaattisia hyväksymistestejä, joilla toteutettavan ohjelmiston toimintoja voidaan saman tien testata. Testejä voivat määritellä käyttäjät, asiakkaat tai toiminnallisen määrittelyn asiantuntijat, ja ohjelmoijat tai testaajat automatisoivat ne. Testien määrittelyä kannattaa tehdä jo iteraation tai projektin suunnitteluvaiheessa, mutta luontevinta on automatisoida kunkin ominaisuuden testi vasta juuri ennen ominaisuuden ohjelmointia.

Nämä testit ovat testausguru Brian Marickin terminologialla business-facing eli ne ilmaistaan liiketoiminnan termeillä, toisin kuin ohjelmoinnin apuvälineenä toimivan TDD:n technology-facing-testit. Käytännössä testit ovat esimerkkejä olennaisista työnkuluista tai liiketoimintalogiikan säännöistä. Esimerkiksi "kun ostoskoriin lisätään 100 euroa maksava tuote, laskun loppusumma kasvaa 250 eurosta 350 euroon" tai "alennus yli 100 euron ostoksista on 5 % ja yli 300 euron ostoksista 10 %."

Automaattiset hyväksymistestit kertovat kehitystiimille, milloin kyseinen ominaisuus on toteutettu määrittelyn mukaisesti. Ne eivät poista ihmisten tekemän manuaalisen testauksen tarvetta etenkään käyttöliittymän osalta, mutta vapauttavat ihmistestaajat tekemään sitä, missä he ovat koneisiin verrattuna ylivoimaisia (ks. myös "Testauksen automatisointi" artikkelissa Laadunvarmistus ja testaus). Ilman hyväksymistestien automatisointia testaajien aika menee regressiotestaukseen eli vanhan toiminnallisuuden testaamiseen varmuuden vuoksi. Vastaavasti kehittäjän saama palaute viivästyy, kun manuaalinen testaus kestää jopa useita päiviä.

Liiketoimintalähtöistä ohjelmistosuunnittelua

Etukäteen määritellyt automaattiset hyväksymistestit nopeuttavat ohjelmistokehitystä, sillä ohjelmistokehittäjät saavat niiden avulla nopeasti palautetta työnsä edistymisestä. Perinteinen ongelma ohjelmistokehityksessä on, että toteutetut toiminnot eivät vastaa asiakkaan tarpeita. Kehitystiimin ja asiakkaan etukäteen yhteistyössä määrittelemät hyväksymistestit auttavat varmistamaan, että ohjelmoijat toteuttavat sovitut toiminnot asiakkaan toiveiden mukaisesti.

ATDD:ssä liiketoimintalähtöisyys viedään äärimmilleen eli lähdetään liikkeelle niistä konkreettisista toiminnoista, joihin asiakkaan kannattaa kallisarvoiset kehitysresurssinsa kohdentaa. Tekniset ratkaisut ja yksityiskohdat valitaan suoraan palvelemaan liiketoiminnan tarpeita.

Hyväksymistestien laatu ja tarkoituksenmukaisuus ovat ATDD:ssä ensisijaisen tärkeitä. Ketterässä ohjelmistokehityksessä ongelmaksi voi muodostua se, että määrittelytyötä ja vastuuta sälytetään liiaksi asiakkaalle. Tästä kertoo esimerkiksi The Agile Physician -artikkeli [PDF] (IEEE Software, kesäkuu 2007). Reaktorilla toiminnallisen määrittelyn asiantuntijat keskustelevat asiakkaan ja käyttäjien kanssa, mutta kantavat vastuun käyttöliittymä- tai työnkulkujen suunnittelusta. Asiakkaan tärkein tehtävä tässä prosessissa on auttaa asiantuntijoitamme ymmärtämään liiketoimintaansa ja niitä konkreettisia tavoitteita, joihin pääsemistä ohjelmisto voi auttaa.

Lasse Koskela, menetelmäkonsultti

Lasse on Reaktorin menetelmäspesialisti. Hän kiertää kouluttamassa ja valmentamassa asiakasorganisaatioita ketterien menetelmien ja insinöörikäytäntöjen osalta niin kotimaassa kuin muualla Euroopassa.