Kuten ohjelmistokehitystä, myös testausta voidaan tehdä perinteisellä tavalla tai ketterillä menetelmillä. Nämä kaksi eri lähestymistapaa eroavat toisistaan monella eri tavalla kuten toimintatavoissa, testaustasojen laajuudessa ja ajattelusuunnissaan. Perinteinen testauksen lähestymistapa on usein vesiputousmallin tai V-mallin mukainen. Ketteristä menetelmistä tunnetuimpia ovat Scrum, Kanban ja Lean.
Gofore julkaisi taannoin Ketterää laatua & turvaa -oppaan, jossa keskityttiin testauksen ketterään laatumaisemaan eli Goforen DevSecOps-malliin. Tässä mallissa yhdistetään testaus, ketteryys ja tietoturvallisuus. Jotta DevSecOps-mallin tarkoitus aukeaa vielä enemmän, keskitytään tässä blogissa nostamaan viisi eroa mitä perinteisessä ja ketterässä testauksessa on.
1. Suunnittelu
Perinteisessä mallissa testisuunnitelman luominen aloitetaan hyvissä ajoin ennen ohjelmiston kehitystä. Testisuunnitelmaa luodaan usein pitkään ja siitä voi tulla hyvin raskas ja erittäin tarkasti kuvattu teos. Testauksen edetessä testisuunnitelmaa usein seurataan tarkasti koko prosessin ajan.
Ketterässä testauksessa testisuunnitelma luodaan, mutta tämä tehdään joustavammin ja kevyemmällä tasolla. Usein testisuunnitelma ei ole niin yksityiskohtainen ja testauksessa pääpaino on nopeassa toiminnassa. Testisuunnitelmaa päivitetään tarpeen mukaan jatkuvasti testausprosessin edetessä.
2. Dokumentaatio
Perinteisessä mallissa dokumentaatio on testisuunnitelman tavoin yksityiskohtaisempaa ja testitapaukset ovat usein hyvin tarkasti kuvattu. Ne perustuvat dokumentoituihin määrittelyihin ja nämä luodaan ennen testauksen aloitusta.
Ketterässä testauksessa dokumentaatio on kevyempää ja painopiste on ohjelmiston testauksessa eikä niinkään dokumentaation luomisessa. Testitapauksien luomisessa käytetään usein hyväksi käyttäjätarinoita. Nämä määrittelevät selkeästi, miten käyttäjät tulevat ohjelmistoa käyttämään, ja täten testaus saa näistä luotua hyödyllisiä testitapauksia ketterästi. Testitapaukset luodaan, kun ohjelmistosta on jotain osia valmiina testattavaksi tai kun ohjelmistoversion muutokset ovat tiedossa, ja niitä päivitetään jatkuvasti tarpeen mukaan.
Tutustu maksuttomaan Ketterää laatua ja turvaa -oppaaseemme!
3. Testauksen ajoittaminen ja muutoksen hallinta
Perinteisessä mallissa ohjelmistokehitys on loppuvaiheessa tai valmis ennen kuin testaus aloitetaan. Tämä vie ajallisesti pitempään, kun ohjelmistokehitys odottaa testauksen tuloksia, ja tarvittavien korjauksien sekä muutosten saanti ohjelmistoon on hitaampaa.
Ketterässä testauksessa testaus suoritetaan sprinttien tai iteraatioiden aikana, jolloin ohjelmistokehitys saa nopeasti testauksen tulokset ja bugit tietoonsa. Ketterän testauksen ansiosta myös aikaisen vaiheen bugit saadaan nopeammin kiinni, kun kehitystyötä ei ole ehditty viemään pitkälle.
4. Testaustasojen laajuus
Perinteisessä mallissa ohjelmistokehitys tuo yleensä eri testaustasoille joko ison julkaisun tai kokonaisen ohjelman, jolloin testaustasojen suorittamiseen kulutettu aika ja työmäärä ovat isoja. Tämä vaatii yleensä etukäteen suuren määrän valmistautumista ja suunnittelua, jotta ohjelmisto pystytään testaamaan tarvittavalla laajuudella.
Ketterässä testauksessa valitut testaustasot ovat mukana sprintissä tai iteraatiossa. Tällöin saman sprintin aikana suoritetaan kehitetylle ohjelmistolle yksikkötestaus, integraatiotestaus ja hyväksymistestaus. Näin saadaan nopeasti uusia kehityksiä ja muokkauksia tuotettua ohjelmistolle.
5. Asiakkaan osallistuminen
Perinteisessä mallissa asiakkaan kokemus ja palaute ohjelmistosta tulee yleensä vasta hyväksymistestauksessa, joka on ohjelmistokehityksen lopussa. Jos tässä vaiheessa huomataan, ettei ohjelmisto vastaa asiakkaan toivomuksia, se voi aiheuttaa ongelmia ja lisäkustannuksia. Tämän vuoksi tarkat määritykset auttavat viemään ohjelmistokehitystä oikeaan suuntaan.
Ketterässä testauksessa asiakkaat osallistuvat aktiivisemmin testaukseen. Heidän antamansa välitön palaute saadaan sprinttien aikana ja siihen voidaan puuttua nopeasti. Tämä tietysti osallistuttaa asiakasta ohjelmiston luontiin enemmän, mutta se voi myös auttaa asiakasta ymmärtämään omia tarpeitaan paremmin.
Testauksen lähestymistavan valinta riippuu usein organisaation toimintatavoista ja ohjelmistokehityksen metodista. Perinteisen mallin ja ketterän testauksen tapoja voidaan myös yhdistää ja usein käytetään erilaisia hybridimalleja, jotka sopivat ohjelmistokehityksen tarpeisiin ja tiimin taitoihin parhaiten.
”Mitä on testaus?” on osa blogisarjaa, jossa sukelletaan testauksen maailmaan ja opitaan, miksi ohjelmistotestaus on tärkeä osa ohjelmistokehitystä, millaista on testaajan työ ja mitä kaikkea testaukseen liittyy. Mitä on testaus? Perinteinen ja ketterä testaus on blogisarjan kolmas osa.
