Asiakaslähtöisen testausautomaation toteutus

Ohjelmistojen kehitysmenetelmät ja testausautomaatio ovat kehittyneet vauhdilla viimeisen vuosikymmenen aikana. Ketterien menetelmien käytäntöjen myötä testauslähtöinen ohjelmistokehitys (Test-Driven Development, TDD) ja jatkuva integraatio (Continuous Integration, CI) ovat tulleet osaksi ohjelmistokehityksen ja laadunvarmistuksen perusmenetelmiä. Näiden avulla mahdolliset virheet ohjelmistossa voidaan havaita nopeasti ja kustannustehokkaasti – parhaimmillaan jo ennen kuin virheellinen koodi pääsee edes tuotteen versionhallintaan.

Perinteisessä testauslähtöisessä ohjelmistokehityksessä on kuitenkin myös haasteensa. Yhtenä haasteena on automatisoidun testiaineiston painottuminen yksikkötason testeihin ja sen myötä yksittäisten tuoteominaisuuksien varmistamiseen. Laadunvarmistuksen tuleekin huomioida lisäksi laajemmat koko järjestelmän kattavat käyttötapaukset, sekä ei-toiminnalliset vaatimukset, joilla varmistetaan, että ohjelmisto kokonaisuutena täyttää asiakkaan sille asettamat odotukset.

Toisena haasteena on riittävän kommunikaation mahdollistaminen asiakkaan, kehitystiimin ja muiden projektin teknisten ja ei-teknisten sidosryhmien välillä. Mikäli testausautomaatio on toteutettu ilman riittävää dokumentaatiota ja testien analysointi vaatii ymmärrystä projektikohtaisista ohjelmointikielistä ja teknologioista, vaarana on, että laadunvarmistuksen näkyvyys ja kommunikaatio rajoittuvat vain kehitystiimin teknisten asiantuntijoiden vastuulle. Loppukädessä kuitenkin asiakkaalla on paras näkemys tuotteen tulevasta käyttöympäristöstä, siihen liittyvistä lainalaisuuksista ja liiketoiminnan vaatimuksista, joten laadunvarmistuksen onnistumisen kannalta on oleellista, että tämä tieto saadaan projektin hyödynnettäväksi.

Laadunvarmistuksen tuleekin olla läpinäkyvä prosessi, johon kaikilla sidosryhmillä on näkyvyys ja jossa kaikilla on mahdollisuus avoimeen keskusteluun. Vain tällöin voidaan varmistaa, että kehitetty ohjelmisto on suunniteltu vastaamaan asiakkaan tarpeita ja että myös ohjelmiston tekninen toteutus vastaa näitä vaatimuksia.

Käyttäytymislähtöinen ohjelmistokehitys avuksi

Yhtenä ratkaisuna tämän läpinäkyvyyden ja vuorovaikutuksen lisäämiseksi on siirtyminen käyttäytymislähtöiseen ohjelmistokehitykseen (Behavior-Driven Development, BDD). BDD-pohjainen kehitys pohjautuu selkokielellä määriteltyihin tarinoihin (story), joissa kuvataan tuotteen toiminnallisuus esimerkin mukaisissa käyttötapauksissa (scenario). Nämä tarinat dokumentoidaan hyödyntäen ennalta määrättyä “Oletetaan – Kun – Niin” (engl. “Given – When- Then”) -formaattia, joka mahdollistaa tarinoiden hyödyntämisen automatisoituina testitapauksina. Esimerkki tällaisesta tarinan käyttötapauksesta nettisivuston uutiskirjeen tilaamiseksi on esitetty alla.

BDD tarina ja käyttötapaus

Yllä kuvattu esimerkki lähtee oletuksesta (given), että käyttäjä on sivuston etusivulla. Kun (when) käyttäjä painaa uutiskirjeen tilausta, niin (then) hänelle aukeaa tilauslomake. Kun käyttäjä syöttää sähköpostiosoitteen john@doe.com, niin tilauksen vahvistuksen näyttävä sivu aukeaa ja (and) vahvistusviesti tilauksesta lähetetään sähköpostiosoitteeseen john@doe.com.

Yksikkötesteihin pohjautuvaan testauslähtöiseen kehitykseen verrattuna BDD:n tarinoiden etuna on projektin kaikkien sidosryhmien ymmärtämä selkokielinen formaatti tuotteen toiminnallisuuksien ja käyttäytymisen kuvaamiseksi. Esimerkissä kuvatusta käyttötapauksesta voidaan käydä sellaisenaan avointa keskustelua asiakkaan ja muiden sidosryhmien kanssa, toisin kuin jos sama toiminnallisuus olisi kuvattu ohjelmointikielellä yksikkötestinä. Tällöin keskusteluun osallistuminen vaatisi osallistujilta ymmärrystä käytetystä ohjelmointikielestä ja teknologioista.

Vaikka BDD:tä pidetään usein pelkästään menetelmänä testitapausten kuvaamiseen, on kyseessä koko kehitysprosessia ja tuotteen määrittelyä tukeva menetelmä. Selkokieliset tarinat tukevat ohjelmistokehitystä aina tuotteen toiminnallisuuksien määrittelystä sen toteutukseen ja testaukseen mahdollistaen avoimen kommunikaation eri sidosryhmien välillä, sekä yhteisen ymmärryksen luomisen tuotteelle asetetuista vaatimuksista.

Kun tarinat määritellään yhdessä asiakkaan (tai product ownerin), liiketoiminnan asiantuntijoiden, kehittäjien ja testaajien vuorovaikutuksena, saadaan käyttötapauksiin kiteytettyä tuotteelle oleelliset toiminnallisuudet ja vaatimukset. Myös tuotteen hyväksynnälle asetettavat vaatimukset voidaan kuvata käyttötapauksina, jolloin BDD mahdollistaa samalla automatisoidun hyväksyntätestauksen toteuttamisen.

Selkeät testiraportit

Laadunvarmistuksen kannalta BDD:n etuna on, että tarinat ja niiden käyttötapaukset toimivat sellaisenaan automatisoitavina testitapauksina. Nämä voidaan suoraviivaisesti automatisoida hyödyntäen avoimia BDD-testausympäristöjä, kuten Cucumber tai JBehave. Työkalut tarjoavat valmiin rungon testausautomaation toteutukselle, sekä testiajojen raportointiin. Myös tuotetut testiraportit ovat selkokielisiä, jolloin tulosten analysointi on suoraviivaista ja havaitut virheet ovat helposti raportoitavissa. Esimerkkinä alla on esitetty JBehave -ympäristön tarjoama testiraportti sekä onnistuneesta että epäonnistuneesta testiajosta.

Selkeistä testiraporteista virheet ovat helposti havaittavissa.

Kuten kuvasta nähdään, vasemmassa testiajossa vihreä väri kertoo käyttötapauksen kaikkien vaiheiden onnistuneen. Vastaavasti oikeanpuoleisessa testiajossa käyttötapauksen viimeinen vaihe (sähköpostivahvistuksen lähettäminen) on epäonnistunut. Virheanalyysin tueksi raportti tarjoaa lisäksi kuvakaappauksen tuotteen käyttöliittymästä virheen tapahtumisen hetkellä.

BDD-pohjaisten tarinoiden ja käyttötapausten yhdistäminen osaksi jatkuvaa integraatiota ja muita ketterän kehityksen menetelmiä mahdollistaa jatkuvan testausautomaation rakentamisen, mikä tarjoaa selkeän ja ajantasaisen testiraportoinnin toteuttamisen vaivattomasti koko projektin käyttöön.