Ohjelmiston testaaminen

Ohjelmiston testaamista

Ohjelmiston testaaminen tai ohjelmistotestaus on ohjelmistotekniikassa tapa tutkia ohjelman virheettömyyttä ja muita laatuominaisuuksia sitä yksinkertaisesti sellaisenaan käyttämällä tai erityisiä testaamistekniikoilla käyttäen. Testaamisen vastakohta on ohjelman oikeaksi todistaminen, joka tosin tarkastelee vain ohjelman virheettömyyttä.

Testaaminen tarjoaa asiakkaalle tietoa testattavan tuotteen tai palvelun laadusta. Ohjelmistotestaaminen tarjoaa myös objektiivisen ja erillisen näkökulman ohjelmistoon, jonka avulla asiakas voi ymmärtää ohjelmiston implementoinnin riskejä. Testaustekniikka sisältää ohjelmiston suorittamista löytääkseen siitä ohjelmointivirheitä, mutta tekniikka ei rajoitu ainoastaan siihen. Ohjelmistotestaamisella voidaan myös osoittaa, että (1) ohjelmisto/palvelu/tuote täyttää kaupalliset ja tekniset vaatimukset, (2) ohjelmisto toimii oletetusti ja (3) ohjelmisto voidaan implementoida halutuilla ominaisuuksilla.

Ohjelmiston testaaminen voidaan suorittaa missä tahansa kehitysvaiheessa, riippuen valitusta testaustavasta. Suurin osa testauksesta kuitenkin suoritetaan, kun kaikki ohjelmistovaatimukset ovat määritelty ja ohjelmointivaihe on suoritettu.

Ohjelmistotestaamisen aiheet

Tavoite

Testaamisen päätavoitteena on havaita ohjelmistossa ilmenevät häiriöt, jotta viat voidaan paljastaa ja korjata. Tavoite on hankalasti toteutettavissa: Testaaminen ei voi vahvistaa, että ohjelmisto toimii oikein kaikissa tilanteissa tai olosuhteissa, vaan se osoittaa pelkästään, että se toimii oikein tietynlaisessa ympäristössä. Ohjelmiston testaamisen tavoite käsittää usein koodin tutkimista sekä koodin läpiajoa erilaisissa ympäristöissä ja tilanteissa, siis tekeekö koodi, mitä sen pitäisi ja tarvitsee tehdä. Nykyisessä ohjelmistokehityksessä testaava organisaatio saattaa olla eri kuin ohjelmiston kehittäjä.

Viat ja häiriöt

Kaikki ohjelmistoviat eivät johdu koodausvirheistä. Yksi yleinen kalliiden vikojen aiheuttaja on vaatimuksien välinen kuilu. Näitä ovat esimerkiksi tuntemattomat vaatimukset, jotka johtavat virheisiin, koska niitä ei ole otettu huomioon.

Ohjelmistoviat ilmenevät seuraavasti. Ohjelmoija tekee ohjelmointivirheen, jonka seurauksena syntyy vika ohjelmakoodiin. Jos viallinen ohjelmakoodi ajetaan, joissain tilanteissa järjestelmä tuottaa vääriä tuloksia aiheuttaen häiriön. Kaikki viat eivät välttämättä johda häiriöihin ohjelmistossa. Esimerkiksi virheet suorittamattomassa koodissa eivät johda koskaan häiriöihin. Vika saattaa muuttua häiriöksi, kun ympäristö vaihtuu. Esimerkiksi, kun ohjelmaa ajetaan uudella sovellusalustalla, muutokset lähdekoodissa tai vuorovaikutuksessa toisenlaisen ohjelmiston kanssa. Yksi virhe saattaa johtaa useisiin häiriöihin laajalla alueella ohjelmistoa.

Yhteensopivuus

Usein esiintyvä ohjelmistovian aiheuttaja on yhteensopivuus toisen ohjelman kanssa, uusi käyttöjärjestelmä ja yhä useammin web-selaimen uusi versio. Usein taaksepäin yhteensopivuuden puute aiheutuu, kun ohjelmoijat ovat ajatelleet ohjelmoida ohjelmistonsa uusimmalle versiolle tai käyttöjärjestelmälle yhteensopivaksi. Tästä koituva ei-haluttu seuraus on että viimeisin työ ei ole yhteensopiva aiemman ohjelmiston/laitteiston tai toisen tärkeän käyttöympäristön kanssa. Tätä voitaisiin pitää "ennalta ehkäisevänä strategiana", joka sopii hyvin yhteen Dave Gelperin ja William C. Hetzelin testivaiheeseen.

Dynaaminen testaus

Dynaaminen testaus on koodin läpiajamista testitapauksilla. Se toteutetaan, kun ohjelmistoa käytetään ensimmäistä kertaa. Dynaamista testausta voidaan suorittaa, vaikka ohjelma ei ole valmis.

Syöte yhdistelmät ja esiehdot

Perustava ongelma ohjelmistotestaamisessa on, että kaikkien mahdollisten syötteiden ja esiehtojen testaaminen ei ole toteutettavissa, edes yksinkertaisten tuotteiden kohdalla. Tämä tarkoittaa, että lopullisessa ohjelmistotuotteessa voi olla hyvin suuriakin määriä vikoja, ja näitä harvoin esiintyviä vikoja voi olla hyvin vaikea havaita testauksessa ja virheenetsinnässä. Vielä merkittävämpää on ei-toiminnallisen laadun ulottuvuuksien testaaminen (Kuinka ohjelmisto on toteutettu verrattuna siihen, miten se olisi pitänyt toteuttaa). Tässä tarkasteltavia asioita ovat käytettävyys, skaalautuvuus, suorituskyky, yhteensopivuus ja luotettavuus, jotka voivat olla hyvin subjektiivisia. Siinä, missä joku kokee toiminnallisuuden kattavaksi, toiselle se voi olla liian monimutkainen ja siksi näiden ominaisuuksien testaaminen voi olla haastavaa. Helpottaakseen näitä ongelmia testaamisessa tulee ennakkoon määritellä haluttu taso, mitä ohjelmistolta vaaditaan.

Ohjelmistokehittäjätkään eivät voi testata kaikkea, mutta he voivat käyttää yhdistelmätestien suunnittelua luodakseen vähimmäismäärän tarvittavia testejä halutun vaatimustason saavuttamiseksi ja varmistamiseksi. Yhdistelmätestien luominen mahdollistaa suuremman testikattavuuden vähemällä testien määrällä. Etsivätpä testaajat sitten nopeutta tai syvyyttä testeihinsä, he voivat käyttää yhdistelmätestien suunnittelumenetelmiä rakentaakseen jäsenneltyä vaihtelevuutta testitapauksiinsa.

Taloudellinen näkökulma

NIST:n vuonna 2002 tekemän tutkimuksen mukaan ohjelmistovirheet aiheuttavat Yhdysvaltojen taloudelle 59,5 miljardin dollarin kustannukset vuosittain. Yli kolmannes näistä kustannuksista voitaisiin välttää, jos suoritettaisiin parempaa ohjelmistotestausta.

Ohjelmistotestauksen ulkoistaminen kustannussyistä on myös hyvin yleistä ja ulkoistaminen tapahtuu yleensä ulkomaille Kiinaan, Filippiineille tai Intian.

Yleisimpiä virheiden paikkoja

• Uusi koodi: Useimmiten bugeja löytyy uudesta koodista enemmän, kuin pidempään käytössä olleesta.
• Uusien ominaisuuksien lisääminen vanhaan koodiin: Uudet ominaisuudet tuovat mukanaan myös uusia bugeja.
• Vanhan koodin muokkaaminen: Joskus jopa vanhan koodin muokkaaminen saattaa tuoda mukanaan bugeja, jotka pahimmillaan haittaavat koko ohjelmiston toimintaa.
• Uuden teknologian käyttö: Uuden teknologian kehittyessä, esimerkiksi vaihdettaessa tietokantamoottoria tai ohjelmointikieltä saattaa ilmetä uusia ongelmia.
• Nopeat "pikkufiksaukset": Joskus ohjelmoijalle saattaa esimerkiksi tulla kiire saada jokin ominaisuus julkaistua ja tulee tehtyä nopeita korjauksia koodiin. Näihin korjauksiin tulee helposti virheitä, sillä niitä ei välttämättä keretä testaamaan riittävästi ja pahimmassa tapauksessa niistä puuttuu kokonaan dokumentaatio.
• Ulkopuolisen toimijan koodi: Ulkopuolisen toimijan tekemä ohjelmisto tai sen osa tulee tarkasti testata myös itse varmistaakseen sen toimivuus osana omaa toimintaa, jotta se varmasti täyttää yrityksen omat standardit.
• Uusi asiakas
• Uusi työntekijä: Uusien työntekijöiden koodit kannattaa testata tarkasti, sillä etenkin kokemattomuus tuottaa paljon bugeja.

Historia

Vuonna 1979 Glenford J. Myers esitteli virheenkorjauksen ja testauksen erottamisen. Hänen huomionsa kohdistui rikkoutumistestaukseen (eng. breakage testing) ("Onnistunut testitapaus on sellainen, joka havaitsee vielä löytämättömän virheen.”). Se osoitti ohjelmistosuunnitteluyhteisön halun erottaa perustavanlaatuiset kehitystoiminnot, kuten virheenkorjauksen vahvistuksesta.

Testaustavat

Laatikkomalli

Ohjelmiston testaaminen jaetaan perinteisesti kahteen luokkaan, black box -testaamiseen ja white box -testaamiseen. Nämä kaksi lähestymistapaa kuvaavat testitapauksien suunnittelemisen lähtökohtia.

Black box -testaus

Ohjelmisto kuvitellaan "mustana laatikkona" — implementoinnista ei ole tarkkaa tietoa. Mustalaatikkotestauksessa testaaja on tietoinen vain siitä, mitä ohjelmiston on tarkoitus tehdä, eikä niinkään miten ohjelma sen tekee. Black box -testaamistapoihin kuuluu: samanarvoisiin jaottelu, raja-arvoanalyysi, parien testaus, satunnaisella datalla testaaminen, mallipohjainen testaaminen, jäljitettävyysmatriisi, tutkiva testaaminen ja määrittelyyn perustuva testaus. Mustalaatikkotestauksessa on etuna se, että testaajalla ei ole pakko olla ohjelmointitaitoa. Ohjelmoijalla on taatusti ollut oma näkökulma siitä millaisia toiminnallisuuksia hän on korostanut, kun taas testaajalla on ollut omansa, mikä hyödyttää testaajaa löytämään ongelmia, joita koodin kirjoittaja ei olisi osannut arvatakaan. Koska testaajat eivät näe lähdekoodia, voi ilmetä tilanteita, joissa testaaja kirjoittaa liian monta testitapausta tiettyyn ominaisuuteen, johon olisi riittänyt vähempi määrä, tai häneltä jää jokin osa kokonaan testaamatta. Tämä testaustapaa voidaan soveltaa yksikkö-, integraatio-, systeemi-, ja hyväksymistestaamiseen. Yleensä mustalaatikkotestaus kattaa suurimman osan, ellei jopa kaiken, testaamisesta siirryttäessä korkeammille tasoille, mutta sitä voidaan myös hyödyntää tehokkaasti yksikkötestauksessa.

Hyödyt ja haitat: Black box -testaaminen ei ole sidottu koodiin, jolloin testaajan näkökulma on hyvin yksinkertainen: Koodin "täytyy" sisältää virheitä. Periaatteen "Kysy ja saat vastauksen" käyttäminen löytää virheitä sieltä, missä ohjelmoija ei niitä löydä. Toisaalta black box -testaaminen on kuin "kävelisi pimeässä ilman taskulamppua", koska testaaja ei tiedä, kuinka ohjelmisto on rakennettu. Tämän seurauksena tulee tilanteita, joissa (1) käyttäjä kirjoittaa monta testitapausta tarkastaakseen jotain, jonka voisi testata yhdellä tapauksella ja/tai (2) osa back-endistä jää testaamatta kokonaan.

Black box -testaamisen etu on sen "sitoutumaton mielipide" ja toisaalta sen haittana on "sokea etsiminen".

White box -testaus

White box -testaamista sanotaan testaamiseksi, jossa testaajalla on pääsy tietorakenteisiin ja algoritmeihin sekä koko koodiin. White box -testaamisesta käytetään suomenkielisessä kirjallisuudessa termiä lasilaatikkotestaus. Lasilaatikkotestauksessa käytetään ohjelmiston sisäistä näkökulmaa, eli toisinkuin mustalaatikkotestauksessa, testaaja tarvitsee ohjelmointitaitoja testitapausten suunnittelua varten. Testaaja valitsee syötteet sen perusteella, mitkä niistä käyvät läpi koodin kaikki mahdolliset polut ja määrittelee sitten odotetut tulokset. Vaikka lasilaatikkotestausta voidaan soveltaa yksikkö-, integraatio- ja järjestelmätesteissä, sitä tehdään yleensä vain yksikkötasolla, sillä koodimäärän laajetessa, testaajan käy vaikeammaksi hahmottaa kokonaisuutta. Sillä voi testata polkuja yksikössä, yksiköiden välillä integraation aikana sekä alijärjestelmien välillä järjestelmätason testauksessa. Lasilaatikkotestauksella voidaan paljastaa monia virheitä, mutta sillä ei välttämättä havaita määrittelyssä toteuttamatta jääneitä osia tai puuttuvia vaatimuksia.

Tasot

1. Yksikkötestaus. White-box-testaus tehdään yksikkötestauksen aikana sen varmistamiseksi, että koodi toimii tarkoitetulla tavalla, ennen kuin se integroidaan aiemmin testatun koodin kanssa. Yksikkötestauksen aikana suoritettavalla white-box-testausmenetelmällä voidaan mahdollisesti havaita monia virheitä jo varhaisessa vaiheessa, ja se auttaa korjaamaan virheitä, jotka ilmenevät myöhemmin sen jälkeen, kun koodi on integroitu muuhun sovellukseen, ja vähentää siten virheiden vaikutuksia myöhemmin kehitystyön aikana.
2. Integraatiotestaus. Tämän tason white-box-testauksessa testataan rajapintojen vuorovaikutusta keskenään. Yksikkötason testauksessa varmistettiin, että jokainen koodi testattiin ja ne toimivat asianmukaisesti eristetyssä ympäristössä, ja integroinnissa tarkastellaan käyttäytymisen oikeellisuutta avoimessa ympäristössä käyttämällä white-box-testausta ohjelmoijan tiedossa olevien rajapintojen vuorovaikutusten osalta.
3. Regressiotestaus. Regressiotestauksessa käytetään kierrätettyjä white-box-testitapauksia yksikkö- ja integrointitestauksen tasoilla.

Perusmenettelyt

White-box-testauksen perusmenettelyt edellyttävät, että testaaja tuntee perusteellisesti testattavan lähdekoodin. Ohjelmoijalla on oltava syvällinen ymmärrys sovelluksesta, jotta hän tietää, millaisia testitapauksia on luotava, jotta jokainen näkyvä polku käytetään testauksessa. Kun lähdekoodi on ymmärretty, sitä voidaan analysoida testitapausten luomiseksi. Seuraavassa esitetään kolme perusvaihetta, jotka white-box-testauksessa otetaan testitapausten luomiseksi:

1. Sisäänsyöttö käsittää erityyppiset vaatimukset, toiminnalliset määrittelyt, asiakirjojen yksityiskohtaisen suunnittelun, asianmukaisen lähdekoodin ja tietoturvamäärittelyt. Tämä on white-box-testauksen valmisteluvaihe, jossa asetetaan kaikki perustiedot.
2. Käsittelyyn kuuluu riskianalyysin suorittaminen koko testausprosessin ohjaamiseksi, asianmukainen testaussuunnitelma, testitapausten suorittaminen ja tulosten ilmoittaminen. Tämä on vaihe, jossa rakennetaan testitapauksia, jotta varmistetaan, että ne testaavat sovelluksen perusteellisesti ja annetut tulokset kirjataan vastaavasti.
3. Tuotos käsittää loppuraportin laatimisen, johon sisältyvät kaikki edellä mainitut valmistelut ja tulokset.
   

Grey Box -testaus

Grey-box -testaus (amerikkalainen oikeinkirjoitus: gray-box -testing) edellyttää sisäisten tietorakenteiden ja algoritmien tuntemista testien suunnittelua varten suoritettaessa näitä testejä musta laatikko tai käyttäjä -tasolla. Testaajalla on usein pääsy sekä lähdekoodiin, että suoritettavaan binääriin. "Grey-box" -testaus saattaa myös sisältää takaisinmallinnusta (dynaamisen koodianalyysin avulla) esimerkiksi raja-arvojen tai virheilmoitusten määrittämiseksi. Syötedatan manipulointi tai tulosteen formatointi eivät kuulu grey-box -testaukseen, sillä syöte ja tuloste ovat molemmat selvästi sen ”mustan laatikon” ulkopuolella, jota kutsumme testattavaksi järjestelmäksi. Tämä eroavaisuus on erityisesti tärkeä. kun tehdään integraatiotestausta kahden eri kehittäjän kirjoittaman koodimoduulin välillä, jolloin vain rajapinnat ovat esillä testiä varten.

Tietämällä perustana olevat konseptit siitä miten ohjelmisto toimii, testaaja tekee asiantuntevia testausratkaisuja testatessaan ohjelmistoa ulkopuolelta. Tyypillisesti, grey-box -testaajalle annetaan lupa luoda eristäytynyt testausympäristö erilaisilla toiminnoilla, kuten tietokannan kylväminen. Testaaja voi tarkkailla testattavan tuotteen tilaa tiettyjen toimintojen jälkeen kuten SQL-käskyjen suorittaminen tietokantaa vastaan ja suorittaa sitten kyselyitä varmistaakseen, että odotetut muutokset on otettu huomioon. Grey-box -testaus toteuttaa älykkäitä testiskenaarioita rajoitetun tiedon perusteella. Tämä koskee erityisesti tietotyyppien käsittelyä, poikkeusten käsittelyä ja niin edelleen.

Gray-box -testaus on hyödyllistä, koska se ottaa käyttöön suoraviivaisen black-box-testauksen tekniikan ja yhdistää sen koodikohdennettuihin järjestelmiin white-box-testauksessa. Gray-box -testaus perustuu vaatimustestitapausten luomiseen, koska se esittää kaikki ehdot ennen kuin ohjelma testataan väittämismenetelmällä. Vaatimusmäärittelykieltä käytetään helpottamaan vaatimusten ymmärtämistä ja niiden oikeellisuuden tarkistamista.

Fuzzing

Fuzzing tai fuzz testing on virheiden etsimisen menetelmä, jossa satunnaisilla syötteillä pyritään aiheuttamaan ohjelman kaatuminen, muistin vuotaminen tai tietoturvariskien tunnistaminen. Menetelmä sai alkunsa jo 50-luvulla kun ohjelmoijat testasivat reikäkorteilla toimivia tietokoneita syöttämällä niille sattumalla tuotettuja tai roskiksesta löytyneitä reikäkortteja ja seuraamalla aiheuttaako se ohjelmassa ongelmia. Mikäli jotain odottamatonta tapahtui oli bugi onnistuneesti tunnistettu. Menetelmä on periaatteeltaan mustan laatikon testaamista, mutta voidaan soveltaa myös kun lähdekoodit ovat saatavilla. Menetelmällä voi saada nopeasti yleiskuvan vikasietoisuudesta ja kriittisistä virheistä. Tehokas fuzzer on sellainen, joka tuottaa tarpeeksi valideja syötteitä, sillä jäsennin usein hylkää epävalidit syötteet heti. Syötteiden tulee kuitenkin olla sellaisia, että ne paljastavat virheitä mahdollisissa nurkkatapauksissa. Menetelmä on peräisin vuodelta 1988 Wisconsinin yliopistosta. Fuzzing-tekniikat voidaan asettaa erilaisiin kategorioihin, kuten tuotanto- ja mutaatiopohjainen, onko fuzzer tyhmä vai älykäs ja onko se white-, grey- vai black-box testaamista riippuen onko lähdekoodi saatavilla. Mutaatiopohjainen fuzzing toimii muokkaamalla tai mutatoimalla olemassa olevia valideja syötteitä, kuten esimerkiksi syöttämällä ohjelmalle validi PNG tiedosto, jota aletaan mutatoimaan semivalideiksi syötteiksi. Tuotantopohjainen fuzzing taas tuottaa alkuperäisiä syötteitä, jotka voivat olla fiksuja eli käyttäjän syöttömallin mukaisia tai tyhmiä eli täysin sattumanvaraisia. Tämä toimii esimerkiksi flippaamalla sattumanvaraisia bittejä keskenään, vaihtamalla tavujen arvoja tai poistamalla tai siirtämällä datablokkeja. Näitä tekniikoita voidaan käyttää sekä yhdessä että erikseen.

Integraatiotestaus

Integraatiotestaus on kaikentyyppistä testaamista, jossa pyritään todentamaan rajapintoja komponenttien ja ohjelmistosuunnittelun välillä. Ohjelmistokomponentit voivat olla integroitu iteratiivisesti tai kaikki yhdellä kertaa.

Integraatiotestauksen lähestymistavat

• Big-bang: Big-bang mallissa kaikki kehitetyt komponentit yhdistetään ja testataan yhdessä yhtenä kokonaisuutena. Kyseinen lähestymistapa voi toimia pienille ohjelmistoille, joissa yhdistettävien komponenttien määrä ei ole suuri. Tämä tapa voi säästää integraatiotestausprosessiin kuluvaa aikaa ja siten nopeuttaa ohjelmiston saattamista tuotantoon. Komponenttien samanaikainen yhdistäminen voi kuitenkin johtaa mm. siihen, että riskialtteimpien komponenttien testaamista ei priorisoida tarpeeksi. Tämän lisäksi jos yhdistettävien komponenttien määrä on suuri, voi yksittäisten virhelähteiden jäljittäminen olla haastavaa. Myös itse testaamisen voi helposti myöhästyä, sillä kaikkien komponenttien tulee olla valmiina ennen testaamisen aloittamista.
• Top-down: Top-down-mallissa komponenttien yhdistäminen ja testaaminen aloitetaan korkeimman tason komponenteista, joista edetään vähitellen kohti matalamman tason komponentteja. Tämä malli mahdollistaa aikaisen prototyypin valmistamisen, mutta testausprosessin loppupuolelle jäävien tärkeiden matalan tason komponenttien testaamiselle voi jäädä liian vähän aikaa.
• Bottom-up: Bottom-up-mallissa komponenttien yhdistäminen ja testaaminen aloitetaan matalimman tason komponenteista, joista edetään vähitellen kohti korkeamman tason komponentteja. Tässä mallissa yhteensopivuusongelmien löytyminen matalan-tason komponenteista helpottuu, mutta korkean tason komponenttien testaaminen voi jäädä vähäiseksi. Tämän lisäksi aikaisen prototyypin valmistaminen ei ole mahdollista.
• Sandwich: Sandwich-mallissa sekä korkean että matalan tason komponenttien yhdistäminen ja testaaminen aloitetaan samanaikaisesti. Kyseinen malli on yhdistelmä top-down- ja bottom-up-malleista.

Passiivinen testaus

Passiivinen testaus tarkoittaa järjestelmän toiminnan tarkistamista ilman vuorovaikutusta ohjelmistotuotteen kanssa. Toisin kuin aktiivisessa testauksessa, testaajat eivät vaadi mitään testitietoja, vaan katsovat järjestelmän lokeja ja jälkiä. He etsivät malleja ja erityistä käyttäytymistä tehdäkseen päätöksiä. Tämä liittyy offline-ajonaikaiseen vahvistukseen ja lokianalyysiin.

Tutkiva testaus

Tutkiva testaus (eng. Exploratory approach) on ohjelmistotestauksen tapa, joka kuvataan samanaikaiseksi oppimiseksi, testin suunnitteluksi ja suorittamiseksi. Cem Kaner, joka loi termin vuonna 1984, määrittelee tutkivan testauksen "ohjelmistotestauksen tyyliksi, joka korostaa yksittäisen testaajan henkilökohtaista vapautta ja vastuuta jatkuvasti optimoida työnsä laatua käsittelemällä testeihin liittyvää oppimista. Testin suunnittelu, testin suorittaminen ja testitulosten tulkinta ovat toisiaan tukevia toimintoja, jotka kulkevat rinnakkain koko projektin ajan.”

Jatkuva testaus

Jatkuva testaus (eng. Continuous testing) on prosessi, jossa suoritetaan automaattisia testejä osana ohjelmiston toimitusprosessia, jotta saadaan välitöntä palautetta ohjelmistojulkaisuehdokkaaseen liittyvistä liiketoimintariskeistä. Jatkuva testaus sisältää sekä toiminnallisten että ei-toiminnallisten vaatimusten validoinnin. Testauksen laajuus ulottuu alhaalta ylöspäin suuntautuvien vaatimusten tai käyttäjien tarinoiden validoinnista yleisiin liiketoimintatavoitteisiin liittyvien järjestelmävaatimusten arviointiin.

Toiminnallinen ja ei-toiminnallinen testaus

Toiminnallinen ja ei-toiminnallinen testaus (engl. functional and non-functional testing) ovat yksi ohjelmistotestauksen perustyökaluja. Toiminnallisessa testauksessa testataan, että kyseisen ohjelman kaikki ominaisuudet ja toiminnot toimivat siten, kuin ne on vaatimusmäärittelyissä määritelty. On siis helpompi ajatella, että toiminnallinen testaus on yläkäsite, ja siihen kuuluukin mm. yksikkötestausta, API-testausta, integraatiotestausta, järjestelmätestausta sekä hyväksymistestausta. Toiminnallisessa testauksessa dokumentaation merkitys korostuu. Testejä suorittaessa esiintyy harvoin epäselvyyksiä asiakkaan ja toimittajan välillä siitä, että onko testiä tehty vai ei, sillä toiminnallisessa testauksessa testataan ohjelman/ohjelmiston ns. ”fyysisiä/olemassa olevia” ominaisuuksia, joista tehdään dokumentaatiota. Esimerkiksi tekstinkirjoituseditorin funktionaalisissa testeissä voitaisiin suorittaa yksikkötestejä tekstin fontin ja koon muuttamiselle. Järjestelmätestausta suorittaessa voitaisiin testata sitä, että pystyköö tiedostoja tallentamaan pilveen tai tulostamaan verkon kautta tulostimella.

Vastaavasti ei-toiminnallisessa testauksessa testataan ohjelman / ohjelmiston turvallisuutta, luotettavuutta, käytettävyyttä, viiveaikaa, suorituskykyä sekä skaalautuvuutta. Kyseisessä testauksessa keskitytään siihen, että millä tavoin ohjelmisto toimii ja miten se selviää erilaisissa ympäristöissä ja tilanteissa. Ei-toiminnallinen testaus on toiminnallisen testauksen tavoin ns. yläkäsite, jonka piiriin kuuluu mm dokumentaatiotestausta, suorituskykytestausta, luotettavuustestausta, käytettävyystestausta, skaalautuvuustestejä sekä penetraatiotestejä. Ei toiminnallisten testien suorittamisessa esiintyy ajoittain epäselvyyksiä asiakkaan ja toimittajan välillä siitä, että onko jokin testi tehty tarpeeksi hyvin tai kattavasti. Dokumentaation merkitys on suuri ja usein sen verukkeella pystytään perustelemaan riitatilanteissa, onko jokin testi tehty riittävällä kattavuudella vai ei. Esimerkki ei-funktionaalisesta testistä voisi olla sähköpostipalvelu, johon suoritetaan turvallisuustestejä. Turvallisuustesteissä voitaisiin testata sitä, että pystyykö toisen tilille kirjautumaan kepulikonstein tai estääkö sähköpostipalvelu selvät huijaus- ja virusviestit.

Regressiotestaus

Regressiotestaus on kaikentyyppistä testaamista, jossa pyritään paljastamaan ohjelmistoregressioita. Regressio ilmenee, kun ohjelman toimiva osa lakkautetaan toimimasta tarkoituksellisesti. Tyypillisesti regressio tapahtuu tahattomasti ohjelmistoa muutettaessa, kun uudet osat törmäävät yhteen vanhojen kanssa. Tyypillisiä regressiotestauksen tapoja ovat ajaa vanhoja testejä läpi ja katsoa, ilmenevätkö jo korjatut virheet uudelleen.

Regressiotestaus on myös usein suurin askel kaupallisessa ohjelmistokehityksessä, sille se vaatii aiempien ohjelmistoversioiden monien yksityiskohtien tarkastusta. Uutta ohjelmistoa voidaan kehittää samanaikaisesti käyttäen joitakin vanhoja testitapauksia uusien suunnitteluosien testaamiseen varmistaaksemme, että aiemmat toiminnallisuudet säilyvät.

Testauksen intensiteetti vaihtelee julkaisu prosessin vaiheen ja lisättyjen ominaisuuksien riskien myötä. Testit voivat olla joko kattavia, erityisesti myöhään lisättyjen muutosten tai riskialttiiden ominaisuuksien osalta tai ne voivat olla hyvin pintapuolisia, sisältäen postitiivisa testejä jokaiselle ominaisuudelle, jos muutokset tehdään varhaisessa vaiheessa tai niitä pidetään lähes riskittöminä.

Käytettävyystestaus

Käytettävyystestaus (engl. usability testing) on testausta, joka keskittyy arvioimaan ja mittaamaan käyttäjien kykyä käyttää ohjelmistoa tehokkaasti ja sujuvasti. Testausmenetelmällä pyritään varmistamaan, että käyttäjäkokemus (UX) on hyvällä tasolla ja että käyttäjät kykenevät suorittamaan haluamansa tehtävät ilman vaikeuksia. Käytettävyystestaus on olennainen osa käyttäjäkeskeisestä suunnittelua, sillä se auttaa löytämään ohjelmistosta käyttäjille mahdollisesti aiheutuvia ongelmia. Käytettävyystestaus ei ole automatisoitavissa oleva testausmenetelmä vaan siihen tarvitaan todellisia ihmiskäyttäjiä, joita valvovat joko kehitystiimi tai ammattitaitoiset suunnittelijat, ja jonka pohjalta tietoa kerätään ja analysoidaan. Käytettävyystestaus tarjoaa monia etuja, jotka voivat tehdä ohjelmiston kehittämisestä sujuvampaa ja tehokkaampaa.

Käytettävyystestaukseen kuuluu useita periaatteita ja käytäntöjä:

• Kohdeyleisö. Testauksessa on tärkeä valita, kuka ohjelmistoa tulee käyttämään. Tämä auttaa määrittelemään tavoitteet, jotta voidaan varmistaa, että se vastaa todellisten käyttäjien tarpeita.
• Testauskohde. Testauksessa on hyvä määrittää, mitkä osat ohjelmistosta tullaan testaamaan, ja mitkä tehtävät käyttäjille annetaan.
• Testin tarkoitus. Testauksen toteuttamisen kannalta on tärkeä määrittää testin tarkoitus. Tämä antaa testaukselle tavoiteltavan lopputuloksen.
• Testiympäristö. Testausta varten luodaan testiympäristö, jossa testit suoritetaan. Tämä voi olla joko fyysinen tai virtuaalinen ympäristö.
• Datan keräys ja analysointi. Testauksen aikana kerätään dataa testaajien suorituksesta ja havaituista ongelmista. Tätä tietoa analysoidaan ja tulkitaan korjausten ja parannusehdotusten löytämiseksi.
• Raportointi. Testauksen tulokset raportoidaan kehitystiimille. Raportti sisältää havainnot, suositukset ja korjaustoimenpiteet, joiden avulla tuotetta voidaan parantaa

Käytettävyystestaus on siis keskeinen osa ohjelmiston kehitysprosessia ja sen avulla voidaan varmistaa, että käyttäjien tarpeet ja odotukset täyttyvät. Tämä parantaa käyttäjäkokemusta, vähentää virheitä ja edistää ohjelmiston toimivuutta.

Hyväksyttämistestaus

Hyväksyttämistestausta ovat:

1. Aloitustestaus. Sitä käytetään hyväksyttämistestauksena ohjelmiston uudelle versiolle ennen integraatio- ja regressiotestausta.
2. Asiakkaalla hyväksyttäminen. Toteutetaan asiakkaan omassa työympäristössä asiakkaan laitteistolla (UAT).

Hyväksymistestaus eli User acceptance testing (UAT) on yleensä testausprosessin viimeinen vaihe, ja se on edellytys ohjelman julkaisulle. Siinä asiakas on aina mukana, ja nimenomaan hän päättää onko ohjelma valmis käytettäväksi ja vastaako se heidän vaatimuksiaan. Hyväksymistestaamisessa asiakas itse testaa ohjelmaa, käyttää tuotetta sekä lukee dokumentaation läpi. Siksi olisi hyödyllistä, että ohjelman tilanneessa organisaatiossa olisi joku, kenellä on ymmärrystä ohjelmistotestaamisesta. Hyväksymistestaus voi vaihdella huomattavasti riippuen projektin luonteesta sekä loppuasiakkaiden tarpeista. Esimerkiksi sidosryhmien suuri määrä tai ohjelman toiminnan kriittisyys voivat tehdä hyväksymistestauksesta monimutkaisemman.

Hyväksymistestaamisessa ohjelman on tarkoitus olla valmis niin, ettei sitä enää muokata. Löydetyt kriittiset bugit tai muut virheet tietenkin korjataan, mutta ohjelmaan ei ole enää tarkoituksena lisätä esimerkiksi uusia ominaisuuksia. Riippuen mallista, jolla projektin on toteutettu, asiakkaalla voi olla hyvin erilaisia rooleja. Perinteisissä malleissa, kuten vesiputousmallissa, asiakas testaa ohjelmaa vasta hyväksymistestausvaiheessa. Ketterissä menetelmissä asiakas on kuitenkin paljon aktiivisemmin mukana projektissa, ja testaa ohjelmaa jo projektin aikana ennen kuin projekti on kokonaan valmis. Siksi ketterissä menetelmissä, kuten V-mallissa, on lähes oletuksena, että asiakas tulee hyväksymään ohjelman hyväksymistestauksessa. Kun asiakas lopulta on hyväksynyt tuotteen, se julkaistaan asiakkaan, ja kaikkien muiden ohjelman mahdollisten käyttäjien, käyttöön.

Toimintaan liittymätön testaus

• Ohjelmiston suorituskykyä testaamalla selvitetään, voiko ohjelmisto käsitellä suurta määrää tietoa tai käyttäjiä. Tätä kutsutaan usein ohjelmiston skaalautuvuudeksi.
• Vakaustestaus testaa, toimiiko ohjelmisto normaalisti pitkiä aikoja. Sitä kutsutaan myös kestävyys- tai kuormitustestaamiseksi.
• Käytettävyystestausta tarvitaan tarkastamaan, onko käyttöliittymä helppokäyttöinen ja helposti omaksuttavissa.
• Turvallisuustestaus on olennainen ohjelmistolle, joka prosessoi luottamuksellista tietoa. Testaamisella estetään mahdollisia tietoturva-aukkoja.
• Kansainvälistämis- ja lokalisointitestausta tarvitaan ohjelmiston osiin. Pseudolokalisointi-metodia voidaan käyttää tässä tapauksessa.

Destruktiivinen testaus

Destruktiivinen testaus on ohjelmiston testaamisen menetelmä, jossa pyritään tarkoituksella aiheuttamaan vikoja tai toiminnallisia häiriöitä järjestelmään. Tavoitteena on selvittää, miten ohjelmisto reagoi äärimmäisiin tai epätyypillisiin tilanteisiin sekä arvioida sen suorituskykyä ja kestävyyttä. Tämäntyyppinen testaus auttaa kehittäjiä ja testaajia tunnistamaan mahdolliset heikkoudet, jotta ne voidaan korjata ennen ohjelmiston julkaisua.

Destruktiivisessa testauksessa voidaan käyttää erilaisia menetelmiä ja tekniikoita. Esimerkiksi ohjelmiston suorituskykyä voidaan testata kuormitustestien avulla, jossa ohjelmistoa altistetaan suurelle määrälle käyttäjiä tai tiedonkäsittelyyn. Lisäksi stressitestaus voi simuloida äärimmäisiä kuormitustilanteita, kuten suurta määrää samanaikaista käyttäjää tai suurta tietoliikennemäärää. Tavoitteena on selvittää, minkä kohdan järjestelmä pettää tai mihin resurssirajaan se pystyy vastaamaan.

Destruktiivisen testauksen avulla voidaan myös arvioida järjestelmän kestävyyttä äkillisille häiriötilanteille, kuten virheille tai vioille. Yleinen lähestymistapa on simuloituun ympäristöön vikoja tai väärinkäyttötarkoituksiin, jolloin voidaan tutkia, miten järjestelmä reagoi ja palautuu niistä. Tällainen testaus voi auttaa tunnistamaan haavoittuvuuksia ja kehittämään parempia turvallisuusratkaisuja.

Destruktiivinen testaus varmistaa, että ohjelmisto toimii kunnolla, jopa silloin kun se saa virheellisiä tai odottamattomia syötteitä. Tämä vahvistaa syötteiden tarkistuksen ja virheiden hallinnan toimivuutta. Ohjelmistoon kohdistuvien virheiden syöttäminen, esimerkiksi fuzz-testaus, on yksi esimerkki kyseisestä epäonnistumistestauksesta. Kaupallisia ei-toiminnallisen testauksen työkaluja, jotka liittyvät ohjelmistovikojen syöttämiseen, löytyy ohjelmistovirheiden lisäyksen nettisivuilta; lisäksi on olemassa monia ilmaisia ja avoimen lähdekoodin työkaluja, jotka suorittavat destruktiivista testausta.

Virheen syöttäminen

Ohjelmistoa voidaan testata syöttämällä virhe (engl. fault injection), jolloin voidaan testata vikasietoisuutta harvoin ilmenevissä tilanteissa. Tietyissä standardeissa kuten IEC 61508 vaaditaan tämän tyyppistä testaamista vikatilanteiden käsittelyn testaamiseksi. Perinteisiä kohteita ovat olleet laitteistokomponentit kuten suorittimet ja muistit, joissa tilaa voidaan seurata ja ohjata tietyllä tavalla. Vikoja voidaan mallintaa myös syöttämällä vikoja suoraan ohjelmaan tai lähdekoodiin.

Visuaalinen testaus

Visuaalisessa testauksessa kehittäjille näytetään, mitä ohjelmistovirheen sattuessa tarkalleen tapahtui. Data esitellään siinä muodossa, että kehittäjän on siitä helppo löytää ongelman korjaamiseen tarvitsemansa tieto.

Visuaalisen testauksen pääideana on se, että on selkeämpää näyttää mitä on tapahtunut, sen sijaan, että vain kuvailtaisiin ongelmaa. Tämä vähentää huomattavasti riskiä väärinymmärryksille. Täten visuaalinen testaus edellyttää sitä, että koko testausprosessi tallennetaan videomuodossa, josta käy ilmi kaikki testaussysteemissä tapahtuva. Video täydennetään testaajan reaaliaikaisella, testauksen aikana tapahtuvalla, kommentaariolla, johon sisältyy web-kamera kuva sekä äänitallenne.

Visuaalisella testauksella testauksella on useita etuja. Se parantaa kommunikaatiota huomattavasti, kun testaajat voivat näyttää ongelman ja siihen johtaneet tapahtumat testaajille suoraan, sen sijaan, että vain kuvailisivat sitä. Tämä myös usein tekee tarpeettomaksi toistaa virhe uudelleen kehittäjien toimesta, kun he voivat tarkastella sitä videomateriaalilta. Testaajat saavat käyttöönsä heti kaikki tarvitsemansa tiedot virheestä ja voivat keskittyä paikantamaan virheen syytä ja sitä kuinka sen voi korjata.

Ad hoc -testaus

Ad hoc -testaus ja tutkiva testaus ovat tärkeitä metodeja ohjelman eheyttä testattaessa, koska niiden toteuttaminen ei vaadi niin paljoa valmistautumista, joten bugeja voidaan löytää nopeasti. Ad hoc -testauksessa, missä testaus tapahtuu improvisoidusti, testaajan kyky perustaa testaus dokumentoituihin menetelmiin ja sitten luoda näistä testeistä muunnelmia voi auttaa tekemään vikojen etsinnästä entistä tarkempaa. Yksi ad hoc -testauksen rajoitteista kuitenkin on, että ilman tarkkaa dokumentointia tehdyistä toimista, testejä on vaikea toistaa.

Ad hoc -testauksen huomattava etu on sen kyky antaa nopeita tuloksia ja auttaa kehittäjiä korjaamaan erilaisia vikoja nopeasti. Tämä tekee ad hoc-menetelmästä arvokkaan työkalun nopeissa ja ketterissä kehitysympäristöissä, joissa ohjelmistoon tulee muutoksia ja päivityksiä usein.

Kuitenkin ad hoc -testauksen yksi haasteista on se, että ilman järjestelmällistä ja asianmukaista dokumentointia sekä tarkkaa seurantaa on vaikea arvioida tekstien kattavuutta tai toistaa niitä. Tämän vuoksi, vaikka testaus tapahtuukin nopeasti ja joustavasti, on tärkeää dokumentoida bugit riittävän hyvin, jotta ne pystytään korjaamaan ja testaus voi jatkua kattavana ja toimivana jatkossakin.

Paritestaus

Paritestauksella tarkoitetaan ohjelmistotestausta, jossa ohjelmistoa testataan kahden ihmisen toimesta. Testaus toteutetaan samalla laitteella operoiden, mikä mahdollistaa toisen testaajan testata ohjelmistoa ja toisen henkilön arvioida tai analysoida testausta. Testauksen voi toteuttaa usealla tavalla. Esimerkiksi siten, että henkilöt ovat molemmat ohjelmistotestaajia ja vuorottelevat testaajan sekä testauksen arvioijan rooleissa.

Paritestauksen hyötyjä:

Yksilöhyödyt osallistuville henkilöille:

Kahdestaan työskentely parantaa molempien osallistuvien osapuolien ymmärrystä testaamisesta sekä testattavasta projektista. Esimerkiksi, jos toinen paritestaukseen osallistuu senioritason sekä junioritason testaaja, luo testausprosessi junioritason testaajalle kouluttamistilanteen, jossa junioritason testaajan rooli voi olla testaaja ja kouluttavan senioritason testaajan rooli on testauksen arvioija.

Projektikohtaiset hyödyt:

Kahden henkilön osallistuminen prosessiin tuo varmuutta, tehokkuutta sekä laatua. Paritestaus voi auttaa bugien etsimisessä sekä niiden korjaamisessa. Jaettu tieto työparin välillä mahdollistaa myös testauksessa edistymisen, vaikka toinen tiimistä ei olisi paikalla. Parityöskentely mahdollistaa myös kattavamman perehtymisen testattavaan projektiin testausprojektin alussa. Molemmat osapuolet voivat itsenäisesti tutustua projektiin ja sen jälkeen yhdistää tietonsa. Tämä tekee valmistautumisesta tehokkaampaa. Lisäksi työparin testausprojektissa syntyvä jaettu ymmärrys projektista parantaa testauksen laatua.

Staattinen testaus

Staattinen testaus tarkoittaa ohjelmiston testausta sitä tai sen osia ajamatta. Testauksen aikana ohjelmistoa, koodia ja dokumentaatiota tarkastellaan suoraan lukemalla, analysoimalla ja silmäilemällä, eikä ohjelmiston toiminnan perusteella. Näin tämä eroaa dynaamisesta testauksessa jossa koodin ajaminen on välttämätöntä tuloksien saamiseksi. Staattinen testaus voidaan jakaa kahteen ryhmään: ohjelman katselmointi ja staattinen analyysi.

Ohjelman katselmointi sisältää lähdekoodin tarkastamisen lukemalla, lähdekoodin vertaamisen dokumentaatioon ja dokumentaation tarkastamisen. Katselmointi tehdään usein ryhmässä. Pelkän koodin tarkastamisessa kyse on usein siitä, että kehittäjät tarkastavat toistensa koodia ja antavat siitä palautetta. Virheiden lisäksi tällä tavalla voidaan löytää koodista mm. tyylivirheitä, "kuollutta koodia" ja huonoa optimointia.

Vertaamisessa tarkastetaan puutteet ja ristiriitaisuudet dokumentaation ja koodin välillä. Näin varmistetaan että koodi vastaa dokumentaation vaatimuksiin. Jos taas tarkastellaan pelkkää dokumentaatiota, halutaan varmistaa että dokumentaatio on laadukas ja kattava, eli asiaan perehtymätönkin saa yksityiskohtaisen ja selkeän kuvan ohjelmasta pelkästään dokumentaation lukemalla.

Staattisessa analysoinnissa taas käytetään analysointityökaluja, jotka pyrkivät löytämään koodista virheitä. Useat nykyaikaiset koodikielet ja -editorit tukevatkin staattista analyysia etenkin syntaksivirheiden osalta, mutta myös tyylivirheiden, kirjoitusvirheiden ja joidenkin bugien löytäminen on mahdollista staattisella analyysilla.

Kokonaisuudessaan staattinen testaus on hyvä tapa löytää kriittisiä virheitä, laatuvirheitä, puutteita ja ristiriitoja varhaisessa vaiheessa. Tällä tavalla voidaan vähentää dynaamisen testauksen tarvetta, joka vaatii enemmän resursseja ja aikaa kuin staattinen testaus.

Esteettömyystestaus

Esteettömyystestausta suoritetaan, jotta saadaan varmistettua ohjelmiston saavutettavuus myös vammaisille henkilöille. Yleisiä saavutettavuuden testauksia ovat esimerkiksi:

• fontin ja taustavärin välisen kontrastin on sopivuuden arviointi.
• Fontin koon arviointi.
• Kuva- ja äänisisältöjen mahdollinen korvaaminen tekstisisällöllä.
• Ohjelmiston koeajo myös näppäimistön näppäimillä pelkän hiirellä käytön sijaan.

Turvallisuustestaus

Tietoturvatestaus on välttämätöntä luottamuksellisia tietoja sisältäville ohjelmistoille järjestelmään tunkeutuvien hakkereiden estämiseksi.

Kansainvälinen standardointijärjestö (ISO) määrittelee tämän "testaukseksi, joka suoritetaan sen arvioimiseksi, missä määrin testikohde ja siihen liittyvät tiedot on suojattu siten, että asiattomat henkilöt tai järjestelmät eivät voi käyttää, lukea tai muokata niitä, ja valtuutetuilta henkilöiltä tai järjestelmiltä ei evätä pääsyä niihin."

A/B testaus

A/B-testaus on menetelmä, jossa testataan ohjelmiston kahta eri versioita keskenään. Testin tavoitteena on kerätä dataa siitä, onko ohjelmistoon ehdotettu muutos tehokkaampi kuin nykyinen lähestymistapa. Asiakkaat reititetään joko ominaisuuden nykyiseen versioon tai muokattuun versioon, ja tietoja kerätään sen määrittämiseksi, kumpi versio on parempi saavuttamaan haluttu tulos. A/B-testausta voi voi suorittaa oikeastaan mille tahansa ohjelmiston ominaisuudelle, kunhan testauksen tulokset ovat mitattavissa.

Testiprosessi

Perinteinen vesiputosmalli

Yleinen käytäntö vesiputouskehityksessä on, että testauksen suorittaa itsenäinen testaus ryhmä. Tämä voi tapahtua:

-         sen jälkeen, kun jokin ohjelman toiminnallisuus on kehitetty, mutta ennen sen lähettämistä asiakkaalle. Tämä johtaa usein siihen, että testausvaihetta käytetään projekti puskurina viivästymisien kompensoimiseksi, samalla uhraten testaukselle omistettua aikaa.

-         samaan aikaan kehitysprojektin alkaessa, jatkuvana prosessina projektin valmistumiseen asti.

Vesiputousmallissa yksikkötestaus suoritetaan monesti silti ohjelmistokehitystiimin toimesta, vaikka kaikki siitä pidemmälle viety testaus suoritettaisiinkin erillisen testaustiimin toimesta.

Ketterä- tai XP-kehitysmalli

Vastakohtana perinteisen vesiputousmallin mukaiseen testaukseen voidaan pitää extreme programming (XP) ja ketterässä kehityksessä (agile development) käytettyä testivetoisen kehityksen mallia. Kyseisessä mallissa yksikkötestit kirjoitetaan aivan ensimmäisenä ohjelmistokehittäjien toimesta. Näiden testien oletetaan epäonnistuvan aluksi, jonka jälkeen jokaista epäonnistunutta testiä varten kirjoitetaan juuri sen verran koodia, että kyseiset testit saadaan menemään läpi. Tämä tarkoittaa sitä, että testisarjoja (test suite) päivitetään jatkuvasti uusien virhetilanteiden ilmentyessä, ja ne integroidaan kehitysvaiheessa tehtyjen regressiotestien kanssa, jos niitä vain on olemassa.

Lopullinen tavoite tämän kaltaisessa testiprosessissa on jatkuvan integraation tukeminen (menetelmä jossa kehittäjät yhdistävät heidän itse tekemänsä lähdekoodi muokkaukset varsinaiseen ohjelmistoprojektiin) ja virheiden määrän vähentäminen. Tämä menetelmä lisää varsinaisen ohjelmistokehitystiimin tekemää testaustyötä ennen varsinaisen testaustiimin suorittamaa testausta.

Testaamista voidaan suorittaa seuraavilla tasoilla:

• Yksikkötestaus testaa pieniä ohjelmistokomponentteja tai -moduulia. Jokainen yksikkö testataan, jotta voidaan varmistaa, että yksikön yksityiskohtainen suunnittelu on toteutettu oikein. Objekti-orientoituneessa ympäristössä testaamista tehdään usein luokkatasolla ja minimaaliset testit sisältävät rakentajien ja purkajien testaamisen.
• Integraatiotestaaminen paljastaa viat rajapinnoissa ja moduulien vuorovaikutuksessa.
• Järjestelmätestaus testaa kokonaan integroitua järjestelmää vahvistaakseen, että se vastaa vaatimuksia.
• Järjestelmän integraatiotestaus vahvistaa, että järjestelmä on integroitu ulkopuolisten tai kolmannen osapuolen järjestelmien kanssa niin, että ne vastaavat järjestelmävaatimuksia

Ennen kuin ohjelmiston viimeinen versio julkaistaan, suoritetaan usein lisäksi alpha- ja betatestaus:

• Alphatestaus on simuloitu tai oikea toiminnallinen testaus potentiaalisen käyttäjän tai asiakkaan tekemänä. Myös itsenäistä testiryhmää voidaan käyttää. Alphatestaus suoritetaan ennen betatestejä.^lähde?
• Betatestaus. Ohjelmiston betaversiot julkaistaan rajatulle yleisölle, ohjelmistokehitysryhmän ulkopuolelle. Ohjelmisto julkaistaan ryhmille henkilöitä, jotta voidaan varmistua, että tuote sisältää vain vähän vikoja tai bugeja. Joskus tuote julkaistaan avoimesti kaikille palautteen saamiseksi tulevien käyttäjämäärien maksimoimiseksi.

• Lopuksi tehdään hyväksyttämistestaus, jonka voi tehdä loppukäyttäjä tai asiakas. ^lähde?

Alpha-, Beta- ja Gammatestaus

Ohjelmistotestauksessa suoritetaan kolme vaihetta alfa, beeta ja gamma. Ne suoritetaan järjestyksessä (α → β → γ) ja pyrkivät varmistamaan laadukkaan ohjelmiston julkaisun.

Alpha-testaus

Alpha-testaus suoritetaan yrityksen sisäisen kehitys- tai laadunvarmistustiimin toimesta. Sen pääasiallinen tarkoitus on löytää ohjelmistovikoja. Alfa-testauksessa ohjelmiston toimintaa tarkastellaan todellisissa käyttöolosuhteissa jäljittelemällä loppukäyttäjien toimintaa.

Alfa-vaiheeseen sisältyy seuraavat testityypit:

• Järkevyyden testaus(sanity test)
• Integraatiotstaus
• Järjestelmätestaus
• Käytettävyystestaus
• Käyttöliittymätestaus (UI)
• Hyväksymistestaus
• Regressiotestaus
• Toiminnallinen testaus

Beta-testaus

Beta-testaus on ennen julkaisua tapahtuva testaus. Beta-testauksen päätarkoitus on varmistaa ohjelmiston yhteensopivuus erilaisten ohjelmisto- ja laitekonfiguraatioiden kanssa. Lisäksi käyttäjiltä saadaan palautetta ohjelmiston käytettävyydestä ja toiminnallisuudesta. Beta-testauksen aikana loppukäyttäjät havaitsevat ja raportoivat löytämänsä virheet. Kaikki testausaktiviteetit suoritetaan ohjelmiston kehittäneen organisaation ulkopuolella.

Beta-testauksessa on kaksi tyyppiä:

• Avoin beta-versio, joka on saatavilla suurelle joukolle käyttäjiä
• Suljettu beta-versio, joka on saatavilla vain valitulle ja rajatulle käyttäjäkunnalle

Gamma-testaus

Gamma-testaus on ohjelmiston julkaisua edeltävän testausprosessin viimeinen vaihe. Sen tarkoituksena on varmistaa, että tuote on valmis julkaistavaksi markkinoille, ja kaikki sille määritetyt vaatimukset toteutuvat. Gamma-testaus keskittyy ohjelmiston turvallisuuteen ja toiminnallisuuteen, mutta siihen ei sisälly mitään organisaation sisäisiä laadunvarmistustoimintoja. Gamma-testauksen aikana ohjelmistoon ei tehdä muutoksia, ellei havaittu virhe ole korkean prioriteetin ja/tai vakavuuden virhe. Gamma-testauksesta saatu palaute otetaan huomioon tulevien ohjelmistoversioiden päivityksissä. Kuitenkin rajoitetun kehityssyklin vuoksi gamma-testaus jätetään yleensä väliin.

Regressiotestaus

Regressiotestaus on muutetun järjestelmän tai komponentin uudelleentestausta. Tarkoitus on saada varmuus siitä, että ohjelmistoon tehdyt muutokset eivät ole aiheuttaneet vahingossa virheitä ohjelmistolle.[31]. Mikäli virheitä löytyy, voidaan sanoa, että ohjelma on regressoitunut eli taantunut. Regressiotestaus tarkoittaa siis yksinkertaisesti ohjelmistoon tehdyn korjauksen tai muutoksen toimivuuden tarkastamista. [32]. Lisäksi regressiotestauksella halutaan saada selville, että järjestelmä edelleen täyttää ne vaatimukset, jotka sille on vaatimusmäärittelyssä asetettu. [31]

Regressiotestauksen tarkoitus on todentaa, että ohjelmistomuutosten jälkeenkin ohjelmisto toimii edelleen niiltä osin, kuin se on toiminut tähänkin asti. Ohjelmiston käyttäytyminen ei saisi muuttua muutoin kuin uusien ominaisuuksien osalta. Ohjelmistoon tehdyt muutokset eivät siis saa rikkoa olemassa olevia toimivia ominaisuuksia. [31]

Regressiotestaus pitäisi suorittaa aina sen jäkeen, kun ohjelmakoodiin on tehty uusia ominaisuuksia, parannuksia tai vanhoja ongelmia on korjattu. Se on hyvin aikaa vievää työtä testitapausten suuren määrän vuoksi. Tästä johtuen se on myös kallista. Regressiotestaus onkin hyvä kohde testiautomaatiolle, koska regressiotestauksessa joudutaan toistamaan samoja asioita hyvin moneen kertaan. [33]

Testauksen dokumentointi

Testauksen dokumentointi tarkoittaa testausprosessin ja siitä saatujen tulosten ja havaintojen dokumentoimista. Testauksen dokumentointi on tärkeä osa ohjelmistotestausta ja -kehitystä. Sen avulla pyritään selkeyttämään havaittujen virheiden, puutteiden ja parannusehdotusten jäljittämistä sekä helpottamaan tulevaisuudessa tehtävää ohjelmistotestausta. Selkeä dokumentaatio toimii viestintävälineenä sekä testaustiimin että eri sidosryhmien välillä ja auttaa helpommin ymmärtämään testauksen tulokset ja tarvittavat toimenpiteet. Dokumentointi on myös tärkeä osa laadunvarmistusta, sillä sen avulla pystytään osoittamaan, että kaikki testauksen vaiheet on suoritettu asianmukaisesti. Dokumenttien ja niiden sisältämien testien organisoinnissa käytetään tunnisteina ID:itä. Ainutlaatuisen ID:n avulla voidaan yksiselitteisesti viitata haluttuun dokumenttiin tai testiin. ID:n käyttäminen tekee dokumentista selkeämmin hallittavan.

Ohjelmistotestauksen dokumentointi voi sisältää näitä vaiheita ja elementtejä:

• Testausstrategia ja -tavoitteet: Määritellään yleiset lähestymistavat ja tavoitteet testaukselle. Muodostetaan yleiskuva testausprosessista.
• Testaussuunnitelma: Kuvataan käytössä olevat resurssit, aikataulu ja testauksen päämäärä yksityiskohtaisesti. Määritetään, miten ohjelmistoa testataan ja minkä takia.
• Testausympäristön kuvaus ja testityökalut: Sisältää tiedot testausta varten käytettävistä ohjelmistoista, laitteistoista ja muista testausympäristöön liittyvistä tekijöistä.
• Testitapaukset: Testitapaukset ovat kirjallisia kuvauksia erilaisista tilanteista, joita testataan. Ne sisältävät tarkat vaiheittaiset ohjeet, tarvittavat tiedot testin valmisteluun, annetut syötteet, odotetut lopputulokset ja muut tarvittavat tiedot testin onnistuneeseen suorittamiseen.
• Testiraportit: Testitapauksen yhteydessä olevassa testiraportissa kerrotaan testin tulos, löydetyt virheet ja testin kattavuus.
• Virheraportti: Kuvataan tarkemmin testiraportissa ilmennyt virhe, sen kuvaus, vakavuusaste ja muut oleelliset tiedot.
• Riskiraportti: Kerrotaan ohjelmistosta löytyneistä riskeistä ja niiden vaikutuksesta. Arvioidaan ohjelmistoa kokonaisuutena ja sen valmiutta käyttöön.

Testaustyökalut

Ohjelmistojen testauksessa käytetään apuna useita erilaisia työkaluja. Näistä työkaluista yleensä suuri osa ovat samoja, joita käytetään myös varsinaisessa ohjelmiston tuotannossa. Kuitenkin myös on työkaluja, jotka ovat erikseen suunniteltu juuri ohjelmiston testaamista varten. Tällaisia ovat esimerkiksi muistivuotoja etsivät työkalut tai täysin yksikkötestaukseen keskittyvät työkalut, kuten Valgrind ja JUnit.

Tärkeimmät työkalut testaajille ovat kommunikaatiovälineet ja integroidut tuotantoympäristöt (IDE), sillä nämä mahdollistavat muun muassa testauksen sujuvuuden ja kyvyn kommunikoida testauksen etenemiseen liittyen. Testaukseen liittyvät työkalut ja niiden tarkoitus on tärkeää dokumentoida testaukseen liittyvään dokumentointiin, sillä näin voidaan varmentaa testauksen jäljitettävyyttä.

Dokumentoinnin ja raportoinnin tueksi on myös kehitetty työkaluja, joiden avulla virheitä pystytään raportoimaan tehokkaasti ja selkeästi, jolloin niiden korjausprosessi on myös tehokkaampaa. Tällaiset työkalut tarjoavat esimerkiksi valmiit pohjat virheiden merkitsemiseen ja priorisointiin sekä tilan, jossa kaikki testaamiseen ja virheiden raportointiin liittyvä ohjelmistotestaajan ja ohjelmistokehittäjän kommunikaatio voidaan hoitaa sujuvasti. Edellä mainittu kommunikaatio tulee myös näissä automaattisesti dokumentoiduksi, jolloin ohjelmiston tuotanto- ja testausprosessi on mahdollisimman vaivatonta.

Myös testaukseen liittyvät työkalut ovat jatkuvasti kehityksen ja testauksen alla, sillä ohjelmistojen tuotanto kiihtyy ja kehittyy jatkuvasti, jolloin niin testauksen, kuin siihen liittyvien työkalujenkin on kehityttävä mukana.

Esimerkki testauksen kulusta

Vaikka testaamisesta on useita variaatioita eri organisaatioissa, on olemassa kuitenkin tyypillinen testisykli.:

• Vaatimusanalyysi: Testaaminen tulisi aloittaa vaatimuksien keräysvaiheessa ohjelmistokehityksen kehitysvaiheista. Suunnitteluvaiheessa testaajat työskentelevät kehittäjien kanssa selvittääkseen, mitkä asiat ovat testattavissa ja millä parametreilla ne toimivat.
• Testaamisen suunnittelu: Koska useita toimenpiteitä tarvitaan testien läpiviemiseen, myös testaussuunnitelma on tehtävä.
• Testien kehittäminen: Testimenetelmät, testiskenaariot, testitapaukset, testidata , testiskriptit tarvitaan ohjelmiston testaamiseen.
• Testien ajo: Testaajat suorittavat testit ohjelmistolle ja raportoivat mahdolliset virheet kehitysryhmälle.
• Testien raportointi: Kun testaaminen on suoritettu, testaajat tuottavat kaaviot ja tekevät loppuraportin heidän testisuorituksestaan ja ilmoittavat, voidaanko ohjelmisto julkaista.
• Testituloksien analysointi: eli virheanalyysi; sen tekee tehdään kehitysryhmä usein yhdessä asiakkaan kanssa, jotta saadaan selville, miten virheet käsitellään, korjataan, hylätään tai lykätään myöhempään ajankohtaan.
• Vikojen uudelleen testaus: Kun vika on käsitelty kehitysryhmässä, testaajat toistavat testin.
• Regressiotestaus: Yleisesti mukana on myös alitestausta suorittava testausohjelma integroitua uutta, muokattua tai korjattua ohjelmistoa varten. Testaaminen suoritetaan, jotta uusimmat komponentit eivät aiheuta vikoja muualla ohjelmistossa ja ohjelmisto toimii edelleen kokonaisuudessaan oikein.
• Testaamisen lopettaminen: Kun testaaminen on saatu loppuun, suoritetut toiminnot, kuten ulos tulevan datan kaappaus, tulokset, lokit ja kaikki dokumentit liittyen projektiin arkistoidaan myöhempiä projekteja varten.

Ohjelmistotestauksen onnistuneisuuden mittaaminen

Ohjelmistoa testattaessa mitataan esimerkiksi ohjelman oikeellisuutta, oikeudenmukaisuutta, käytettävyyttä, luotettavuutta, turvallisuutta, tehokkuutta ja muokattavuutta. Kuitenkin on tärkeää mitata myös ohjelmistotestauksen onnistuneisuutta. Jos ohjelmistotestauksen onnistuneisuutta ei mitata, on hankala tietää onko testaus ollut riittävää tai hyödyllistä taloudellisesta ja käytännön näkökulmasta. Yleisin tapa mitata sitä on keräämällä dataa. Datasta voidaan nähdä esimerkiksi kuinka suuri osa koodista on testattu, kuinka pitkän aikaa testien ajaminen on vienyt ja kuinka paljon virheitä koodista on testauksen avulla onnistuttu löytämään.

Automatisoitu testaaminen

Ohjelmistotestauksessa, testauksen automatisointi tarkoittaa ohjelmistopohjaista testausta, joka toimii erillään varsinaisesta testattavasta ohjelmistosta. Tällaisen ohjelmiston toiminta perustuu suoritettavien testien hallintaan ja todellisen lopputuloksen vertaukseen odotetun lopputuloksen kanssa. Testausautomaatio voi automatisoida osan toistuvista mutta välttämättömistä tehtävistä jo olemassa olevasta testausprosessista, tai suorittaa lisätestausta joka olisi hankala suorittaa manuaalisesti. Testausautomaatio on keskeisesti huomioitava seikka jatkuvan toimituksen ja jatkuvan testauksen näkökulmasta.

Testauksen automatisointi on oleellinen asia nykypäivän ohjelmistokehitystä, sekä laadunvarmistusta. Sen lisäksi, että testauksen automatisointi vähentää ihmisen tekemän työn määrää, tuo automatisoitu testaaminen myös kustannussäästöjä, jolloin käytössä olevia resursseja voidaan jakaa tehokkaammin. Testauksen automatisointi nopeuttaa myös ohjelmiston testausprosessia merkittävästi, jolloin ohjelmistojen toimitus on nopeampaa. Parhaiten automatisoitu testaaminen sopeutuu toistuviin, yksinkertaisiin testitapauksiin, kuten yksikkötestaukseen, sillä yksikkötestejä suoritetaan usein monia kertoja päivässä kehityksen aikana.

Testauksen automatisointi ei kuitenkaan sovi kaikkiin tilanteisiin. Esimerkiksi käyttöliittymän käytettävyystestaus ja muut käyttäjäkokemukseen liittyvät testaukset ovat sellaisia tapauksia, johon tarvitaan ihminen suorittamaan testit. Lisäksi pienemmissä ohjelmistoprojektteissa automaatio ei välttämättä ole oikea ratkaisu, sillä automaation rakentaminen vie aikaa ja resursseja. Testauksen automaatio tuo kustannussäästöjä vasta pidemmällä aikatähtäimellä, jolloin pienemmissä projekteissa voi olla järkevämpää keskittyä manuaaliseen testaukseen.

Testauksen automatisointi vaatii huolellista suunnittelua ja ylläpitoa. Kuitenkin oikein toteutettuna testauksen automatisointi voi parantaa merkittävästi ohjelmiston laatua, sekä nopeuttaa toimitusaikoja.

Yleisiä lähestymistapoja

Testausautomaatioon liittyen on olemassa monia lähestymistapoja, alle on listattu näistä yleisimmät ja laajimmin käytössä olevat:

• Graafisen käyttöliittymän testaus (Graphical user interface testing). Testauskehys, joka generoi käyttöliittymätapahtumia, kuten näppäinten painalluksia ja hiiren klikkauksia, ja arvioi tuloksia käyttöliittymässä, validoidakseen että havaittu ohjelman käyttäytyminen on oikeanlaista.
• API vetoinen testaus (API driven testing). Testauskehys, joka käyttää ohjelmistokäyttöliittymää sovellukseen validoidakseen sovelluksen käyttäytymisen testatessa. Tyypillisesti API vetoinen testaus ohittaa sovelluksen käyttäjäkäyttöliittymän täysin. Sen avulla voidaan myös testata julkisia liitäntöjä luokille, moduuleita tai kirjastoja testataan useilla syöteargumenteilla sen varmistamiseksi, että palautetut tulokset ovat oikein.

Mallipohjainen testaus

Yksi tapa luoda testitapauksia automaattisesti on mallipohjainen testaus (Model-based Testing) käyttämällä järjestelmän mallia testitapausten muodostamisessa. Joissain tapauksissa, mallipohjainen testaus lähestymistapa mahdollistaa ei-teknisten käyttäjien luoda automatisoituja liiketoiminta testitapauksia puhtaalla englanninkielellä, siten että minkäänlaista ohjelmointia ei tarvita näiden kokoamiseksi useammalle käyttöliittymälle, selaimelle tai älylaitteelle.

Testaamisen lopettaminen

Lähtökohtaisesti testausta ja ohjelmiston kehittämistä ei pitäisi lopettaa koskaan, koska ohjelmisto on pidettävä toimintakykyisenä. Ohjelmistojen on mukauduttava erilaisiin muutoksiin. Ohjelmistosta ei koskaan saada täydellistä ja kaikkia mahdollisia vikoja ei voida ikinä löytää. Ohjelmiston tulee kuitenkin täyttää tietyt sen vaatimuksiin asetetut kriteerit ennen kuin se voidaan julkaista. Yleisesti ohjelmisto julkaistaan, kun testit osoittavat näiden kriteerien täyttyvän. Testaus voidaan lopettaa myös monesta muusta syystä. Esimerkiksi projekti voidaan lakkauttaa, jos sille ei ole enää käyttöä tai sille ei enää löydy rahoitusta.

Siihen, milloin ohjelmiston testaus on valmis, vaikuttaa olennaisesti kolme tekijää: Aika, budjetti ja haluttu laatu. Jos aikaa on rajallisesti, ehditään tekemään vain tietty määrä testejä, mikä vaikuttaa negatiivisesti ohjelmiston laatuun. Ohjelmistosta voi tällöin jäädä löytämättä oleellisia vikoja. Tämä ongelma voidaan ratkaista kasvattamalla budjettia, jolloin voidaan esimerkiksi palkata lisää testaajia, jotta testejä tulee tehtyä tarpeeksi. Vastaavasti, kun budjettia leikataan, ei saada tehtyä yhtä paljon testejä. Tällöin voidaan joustaa testausajasta venyttämällä sitä, jolloin saadaan tehtyä tarvittavat testit. Mikäli tässä tilanteessa testausaikaa ei voida venyttää, ohjelmiston laatu on heikompi. Kaikkia kolmea tekijää on siis usein mahdotonta optimoida. Vain ⅔ -osaa ohjelmistojen tuotantoprosesseista saadaan suoritettua ajallaan. Yleensä siis joustetaan ajassa, jotta saadaan haluttu ohjelmisto halutulla budjetilla. Testausta suunniteltaessa on aina tärkeää huomioida, ettei se välttämättä suju suunnitelmien mukaan.

Testaamisen kiistanalaisuus

Ohjelmistotestausta koskee joitakin merkittäviä kiistoja, joita käsitellään alla:

Agile vs. perinteinen

Tulisiko testaajien oppia työskentelemään epävarmuuden ja jatkuvat muutoksen olosuhteissa vai pitäisikö heidän pyrkiä prosessin "kypsyyteen"? Ketterä testausliike on kasvattanut suosiotaan kaupallisissa piireissä vuodesta 2006 lähtien, kun taas hallituksen ja armeijan ohjelmistotoimittajat käyttävät ketterän menetelmän lisäksi myös perinteisiä testimalleja, kuten vesiputous-mallia.

Manuaalinen vs. automatisoitu testaus

Jotkut kirjoittajat uskovat, että testiautomaatio on kallista suhteessa sen arvoon, että sitä pitäisi käyttää säästeliäästi. Testiautomaatiota voidaan siten pitää tapana löytää ja toteuttaa vaatimukset. Pääsääntöisesti mitä suurempi järjestelmä ja mitä suurempi monimutkaisuus, sitä suurempi ROI on testiautomaatiossa. Myös työkaluihin ja osaamiseen tehdyt investoinnit voidaan jaksottaa useisiin projekteihin, joissa organisaation sisäinen tiedonjako on oikealla tasolla.

Onko ISO 29119 -ohjelmistotestausstandardin olemassaolo perusteltua?

Kontekstivetoisen ohjelmistotestauskoulun riveistä on muodostunut merkittävää vastustusta ISO 29119 -standardista. Ammattimaiset testausyhdistykset, kuten International Society for Software Testing, ovat yrittäneet saada standardin vedetyksi pois käytöstä.

Joidenkin tieteenharjoittajat mielestä testauskenttä ei ole valmis sertifiointiin

Mikään nyt tarjolla oleva sertifiointi ei itse asiassa vaadi hakijaa osoittamaan kykyään testata ohjelmistoja. Mikään sertifiointi ei perustu yleisesti hyväksyttyyn tietoon. Sertifiointi itsessään ei voi mitata yksilön tuottavuutta, taitoa tai käytännön tietoa, eikä voi taata heidän pätevyyttään tai ammattimaisuuttaan testaajana.

Aiheesta muualla

• Kuvia tai muita tiedostoja aiheesta Ohjelmiston testaaminen Wikimedia Commonsissa