Kuka vastaa testiautomaatiostasi pitkällä aikavälillä?

Uskomme kuitenkin, että sen taustalla piilee syvempi kysymys:

"Kenen pitäisi vastata testiautomaatiosta?"

Ja vielä tarkemmin:

"Mistä testiautomaation eri osa-alueista voidaan olla vastuussa?"

Testiautomaation kaksi osa-aluetta: Test Harness ja loppukäyttäjätyönkulut

Me Eficodella jaamme testiautomaation mielellämme kahteen erilliseen osa-alueeseen:

Test Harness

Test Harness voidaan määritellä monella tavalla, mutta me määrittelemme sen "kaikeksi, mitä testitapauksen suorittamiseen tarvitaan". Sen tärkeimmät osat ovat:

• valitut testaustyökalut

• ympäristöt

• testidata

• Continuous Delivery -ratkaisu

• muut tukityökalut (esim. Docker)

Loppukäyttäjätyönkulut

Testiautomaation toinen osa-alue liittyy testitapauksen sisältöön. Mitä se tekee ja miksi? Tämä kytkeytyy vahvasti itse ohjelmiston vaatimuksiin ja liiketoimintaongelmiin, joita se ratkaisee.

Oletko koskaan miettinyt, miksi testivirheitä ratkaistaessa vastuuta niin usein siirrellään? Saatat kuulla esimerkiksi: "Testitapauksemme epäonnistuivat pipelinessa – kuka voisi korjata ne?" Tästä se johtuu. Testi voi epäonnistua Test Harnessin virheen vuoksi, tai siksi, että testitapauksen liiketoimintasisältö ei vastaa testattavaa sovellusta.

Vastuuongelmat projektin aikana

Kun testaus ei pysy ominaisuuksien kehityksen tahdissa

Projektin alkuvaiheessa ominaisuuksien kehityksen ja Test Harnessin kehityksen välillä käydään jatkuvaa kilpajuoksua. Jotta voit testata kehitettyjä ominaisuuksia, Test Harnessiin on lisättävä uusia kyvykkyyksiä. Saatat houkutella valita Test Harnessin kohdalla helpoimman tien ja "vain saada sen valmiiksi".

Kun ominaisuusjoukko kasvaa ja uusia testitapauksia automatisoidaan, kokemuksemme mukaan suurin osa ajasta kuluu olemassa olevien testitapausten epäonnistumisten selvittämiseen. Näin uusien testitapausten kirjoittamiseen jää yhä vähemmän aikaa. Kuulostaako tutulta?

Kun kukaan ei ota vastuuta

Ongelmia syntyy, jos kukaan ei ota vastuuta testiautomaation loppukäyttäjätyönkulkujen osuudesta. Pahimmassa näkemässämme tapauksessa QA-asiantuntijat eivät pystyneet tai halunneet edes keskustella ominaisuuskehittäjien kanssa: "En kirjoittanut näitä testejä, joten en ole vastuussa niiden epäonnistumisista."

Tällaiset tilanteet vaikeuttavat testitapausten analysointia entisestään ja voivat aiheuttaa tiimille vakavia ongelmia, koska uusia ominaisuuksia ei välttämättä testata lainkaan – ainakaan automaation avulla.

Vastuuongelmien ratkaiseminen

Näihin kahteen ongelmaan voi tarttua monella tavalla. Esimerkiksi:

• tiimin oma QA-asiantuntija tai SDET voi vastata molempiin haasteisiin muun tiimin tuella. 

• testaaja voi vastata loppukäyttäjätyönkuluista, kun kehitystiimi vastaa Test Harnessista. Tämä toimii erinomaisesti, sillä se edistää luontevasti moniosaavia tiimejä. 

• ehkä tuotteen omistaja tai muu liiketoimintavastuullinen voi QA-asiantuntijan ja muun kehitystiimin tuella tehdä yhteistyötä ATDD:tä hyödyntäen – liiketoimintapuoli määrittelee loppukäyttäjätyönkulut, ja kehitystiimi automatisoi ne.

• yksi parhaista tavoista siirtää testausongelmien havaitsemista vasemmalle on ottaa asiantuntijat mukaan jo uusia ominaisuuksia määriteltäessä muiden sidosryhmien, kuten tietoturvaedustajien, rinnalle. Näin Test Harnessin testaaminen ja kehittäminen on osa ominaisuuden suunnittelua.

Yhtä kaikille sopivaa ratkaisua ei ole. Ratkaisun on sovittava omaan toimintaympäristöösi. Toimintatavoista keskusteltaessa on kuitenkin sovittava seuraavista asioista: 

• Miten luomme laadukkaan Test Harnessin? 

• Miten varmistamme, että loppukäyttäjätyönkulut vastaavat sitä, mitä todella haluamme?

Testiautomaation omistajuus ylläpitovaiheessa

Jos testitapauksesi epäonnistuvat jatkuvasti turhaan, testien virheiden analysointi kestää ikuisuuden tai jopa testitapauksen toteuttaminen vie liian kauan, kärsit todennäköisesti merkittävästä teknisestä velasta.  

Koodin laadun mittaaminen on kehittynyt perinteisestä kirosanojen määrästä minuutissa siihen, kuinka helposti ja vaivattomasti sovelluksiisi voi lisätä ja ylläpitää automatisoituja testitapauksia. Jatkuva turhautuminen on merkki siitä, että teknistä velkaa on aika maksaa pois. Se kannattaa pitkällä aikavälillä, sillä 60 % ohjelmiston elinkaaresta kuluu ylläpitoon. 

Kun ohjelmistoprojektisi on ylläpitovaiheessa, suuria muutoksia ei pitäisi enää olla odotettavissa. Kuten itse ohjelmisto, myös Test Harness ja loppukäyttäjätyönkulut tarvitsevat vain vähäisiä päivityksiä. 

Vaikka työ ei välttämättä vaadi paljon panostusta, voi olla järkevää siirtää se projektin mukana tiimille, joka vastaa useiden sovellusten ylläpidosta. Tätä ei usein edes kannata tehdä itse. Voi olla järkevämpää ulkoistaa sekä sovelluksen että testiautomaation ylläpito.

Lyhyesti: kenen tulisi omistaa testiautomaatio?

Kenen siis tulisi omistaa testitapaukset? Me Eficodella ajattelemme, että kaikkien projektin kehitykseen osallistuvien tulisi omistaa testit. Kaikkien osapuolten on sovittava selkeästi, miten työ jaetaan Test Harnessin ja loppukäyttäjätyönkulkujen välillä. 

Lopulta testit ovat osa tuotetta siinä missä lähdekoodikin.