Tutustu vaihto vasemmalle -testaukseen
Sovelluksen elinkaaren hallinnassa testaaminen on tärkeää koodin laadun maksimoimiseksi ja ohjelmiston käyttöönottoon ja päivittämiseen liittyvän toiminnallisen riskin minimoimiseksi. Tässä kontekstissa termi siirtyvien välittää ajatuksen testaustoimintojen siirtämisestä mahdollisimman varhain kehitysvaiheessa. Malliskenaariossamme organisaation tulee harkita tämän lähestymistavan sisällyttämistä DevOps-strategiaansa nykyisten suojaus- ja vakausongelmien minimoimiseksi. Tarkastele tässä yksikössä erityyppisiä testejä, jotka voidaan toteuttaa tällä tavalla, ja tarkastele sitten niiden toteutusmenetelmiä.
Mitkä testit tulisi olla osa vaihtovasemmistotestausta?
Ohjelmistokehitys sisältää laajan valikoiman testityyppejä, mutta meitä erityisesti kiinnostavat muun muassa seuraavat:
Yksikkötestit: Nämä testit keskittyvät sovelluskoodin pienimpiin testattaviin osiin, kuten yksittäisiin funktioihin tai menetelmiin. Tavoitteena on määrittää, voivatko kukin koodiyksikkö suorittaa aiotun toimintonsa erikseen muista koodikannasta ja ulkoisista riippuvuuksista. Tällaisten testien on oltava täysin automatisoituja, nopeita (valmiit 30 sekunnin kuluessa) ja ne antavat täyden koodin kattavuuden (mikä tarkoittaa periaatteessa sitä, että kaikkien yksikkötestien tulee yhdessä testata koko koodauskanta). Yksikkötestaus sopii vasemmalle siirtymiseen. Suosittelemme, että sovellat sitä kaikkeen koodiin mahdollisimman aikaisessa kehityssyklissä, mieluiten ohjelmointivaiheen alussa.
Savutestit: Näiden testien tarkoituksena on arvioida sovelluksen ydintoimintoja testiympäristössä. Vaikka ne testaavat todellista sovellusta (sen yksittäisten, erillisten osien sijaan, kuten yksikkötesteissä), niiden tarkoituksena on määrittää, onko sovelluksen koonti tai käyttöönotto riittävän vakaa, jotta se takaa perusteellisemman testauksen. Ne eivät kuitenkaan varmista sovellusten yhteentoimivuutta. Kuten yksikkötesteissä, niiden tulee olla täysin automatisoituja ja suhteellisen nopeita (käyttäjän toimia voidaan simuloida käyttämällä selaimen automaatiotyökaluja ja käyttöliittymän automaation kehyksiä). Termi savutestin on tarkoitettu välittämään savun ajatuksesta, joka osoittaa suuren asian (tulipalon), joka olisi käsiteltävä mahdollisimman pian. Savutestaus tulee panna myös täytäntöön kehitysjakson varhaisessa vaiheessa, mieluiten heti, kun sen ydintoimintoja tarjoava ohjelmistoversio on saatavilla. Tämä koskee sekä sovellusten koonti- että käyttöönottovaiheita.
integrointitestien: Nämä testit vahvistavat eri sovelluskomponenttien välistä vuorovaikutusta. Toisin kuin yksikkötesteissä, niiden suorittaminen voi kestää huomattavasti. Näiden testien pidennettyä kestoa käytetään yleensä argumenttina niiden suorittamiselle ohjelmistokehityksen elinkaaren varhaisessa vaiheessa. Integrointitestejä kannattaa yleensä harkita tilanteissa, joissa yksikkö- tai savutestit eivät sovi. Suositus on kuitenkin ajoittaa ne suoritettavaksi säännöllisin väliajoin. Tämä lähestymistapa aiheuttaa kohtuullisen kompromissin integrointiongelmien mahdollisen viiveen ja niiden suorittamiseen tarvittavan ylimääräisen odotusajan välillä.
Hyväksyntätestien: Nämä testit määrittävät, täyttääkö ohjelmistotuote liiketoimintavaatimukset ja on valmis toimitettavaksi kuluttajilleen. Hyväksyntätestaus ei sovellu vasemman siirtymän strategialle, mutta jotkin sen elementit voidaan ehkä sisällyttää ohjelmistokehityksen elinkaaren varhaisessa vaiheessa. Esimerkiksi hyväksymisehdot ja käyttäjätarinat, jotka ovat hyväksyntätestauksen olennaisia osia, olisi otettava käyttöön kehitysprosessin varhaisessa vaiheessa. Tämä helpottaa yhteistyötä kehitystiimien, tuotteiden omistajien ja projektin sidosryhmien välillä. Lisäksi ohjelmistojen kuluttajien ja projektin sidosryhmien tulee osallistua aikaisempaan testausvaiheeseen palautteen jakamiseksi. Tämä saattaa tarkoittaa esimerkiksi alfa- tai beetatestausta, käytettävyystestausta tai varhaisjulkaisuja ennen virallista hyväksyntätestausta.